Hey folks, I’m in the process of setting up Kratos for use with a React Native mobile app. I’d like to implement a flow that generates short-lived access tokens and long-lived refresh tokens. I’ve also been asked to keep the login UI in React Native, not in a browser/webview. The app is a first-party client, and it’s notably the only app or website where these identities will be used (we’re not providing single sign-on to other apps or websites). I can’t seem to figure out a way to do this. My two approaches so far have been: A) Use Kratos with the login flow for clients without browsers, which returns a session token for use. This is a long-lived value, and there’s no equivalent “refresh” functionality. B) Use Hydra connected to Kratos, and use an OAuth2 flow (per this blog post) to grant an access and refresh token. However, this seems to require a browser/webview in the flow, as Hydra doesn’t implement the Password Credentials grant type. Is there a way to have a native UI for login, but still use access and refresh tokens instead of a session token?

Not to be trite, but since you are not providing SSO or similar access to other parties, would a session token not be enough? We have a blogpost on how to add auth to React Native with Kratos: https://www.ory.sh/login-react-native-authentication-example-api/ It also goes a bit into why a refresh/access token is not recommended in this case. You can revoke the session token to log users out. If you are using OAuth2.0 for login/registration on native apps, you probably have to involve a browser if it should be secure.

gotcha, thanks @magnificent-energy-493. My main goal with using access/refresh tokens is to mitigate the risk of token leakage. I’m working in a microservices environment, and access and session tokens are sent to every resource server. Since there are more servers/parties involved, the risk of leakage of those credentials is high. So I’d like those to be short-lived, and keep the long-lived token confined to the auth service. I think the revocation behavior should be fine either way. I’m more concerned with mitigating damage when we DON’T know that a token has been compromised. I’ve been asked to keep the UI native if at all possible, but it sounds like we might need to go with a browser-based flow to actually get this behavior.