CODEWITHSUNDEEP
mobileoauth-2.0openid-connect
usernotfound
usernotfound

Reputation: 1

Handle session between mobile app and BFF

What is the best way to handle user session between mobile app (react native) and BFF (.NET) ?

Naive approach

When a user wants to sign up

When the user wants to sign in

When the user wants to log out

So, here "JWT in local storage" act like a session in app. If "token in local storage" then user can access app content. If "no token in local storage" then app display login form.

What about the JWT expiration ? The app need to check its validity and ask for a new token just before it expires ?

OAuth2/OpenID approach

Using a Keycloak server.

The login (and registration?) form is part of the auth server. So the user has to be redirected outside the application (or to an integrated webpage), which I don't think is a smooth route for the user. In fact, on almost all the applications I use, I'm never redirected to log in. So I guess it's not the most common solution for mobile applications.

Let's face it. Once the openid flow has been completed, the backend obtains id token and access token (and refresh token) for the user. Again (as in the first case), the backend must return the access token to the app. The app then provides the token in subsequent requests. But the app must always store the token in local storage. So it's always "the token in local storage" that acts as a session.

On paper, the distinction between authorization, authentication and session is clear. In practice, I can't find a good solution in the case of a mobile app.

Upvotes: 0

Views: 550

Answers (1)

Gary Archer
Gary Archer

Reputation: 29291

In the OAuth / OpenID case the BFF is the authorization server and tokens should be stored in memory by default. If tokens are stored between app restarts, then storage private to the app should be used, eg Android shared preferences or the iOS keychain.

Gmail is an example of a widely used app that uses integrated system browsers and where usability is considered good. You are right that any apps still implement authentication in home grown ways, but this adds more complexity in the longer term, eg apps cannot easily get the right type of access tokens to call APIs after login, or support multi-factor authentication, or support different primary factors for different users.

Perhaps the reason is that an OAuth based implementation involves tricky infrastructure and library choices. This can discourage people when designing their solution. Yet the core code for OAuth messages is not difficult. My blog posts show how working solutions look, along with code examples you can run. You would need to translate code to React Native though:

Upvotes: 0

Related Questions