More clarity around mobile app integration with BFF

[lukepopp]

Thank you for great work with spring-oddons. I just had once question from:

https://stackoverflow.com/questions/78488490/react-native-oauth2-backend-for-frontend-with-spring-cloud-gateway-bff/79091223#79091223

In step 5, you write "If deep linking is correctly configured (Android App link or iOS Smart Link), the response from the authorization server with the authorization code should land in the app"

Am I right to assume then that the deep link path matches client (BFF) redirect uri on the authorization server (for example android manifest might have host = quiz.c4-soft.com path=/bff/login/oauth2/code/)? I also assume because the http client is used, the deep links don't trigger when the uri matches the deep link path. I'm relatively new to mobile app dev but plan to implement this with flutter.

Thanks.

[ch4mpy]

@lukepopp, you should read the Stackoverflow answer more carefully.

Am I right to assume then that the deep link path matches client (BFF) redirect uri on the authorization server

Yes. Keep in mind that this URI containing the authorization code is provided as Location header in the response returned to the user-agent used during the login process on the authorization server.

because the http client is used

For several reasons (displaying forms, enabling SSO with other apps, ...), the user-agent used during login on the authorization server should be the mobile device's system browser, not the app's internal HTTP client, nor the one used by web views. But, as explained in the answer, what you want to be authorized for upcoming REST requests is the app's internal HTTP client session on the BFF, not the system's browser one (for obvious security reasons, sessions are not shared between user agents). So, you need a deep link to intercept the redirection happening in the system browser to forward the code with the app's internal HTTP client (and its session): the BFF attaches tokens to the session of the agent that forwards the authorization code.

plan to implement this with flutter

I already did it, so this is possible. Note that it requires handling cookies manually (a minimum of session and, if the BFF is shared with browser apps, CSRF).

[lukepopp]

Thanks for the reply.

app's internal HTTP client session

My only concerns is the user having to enter their credentials each time the app restarts. My assumption is that the internal HTTP client session will be lost per app restart but hopefully the system browser user agent will hang onto to session cookies from the authz server (for example keycloak) (if max age is set accordingly) between restarts so the issuing of a new session cookie/authz code is seamless because the authz session is alive.

[ch4mpy]

user having to enter their credentials each time the app restarts

They won't. Credentials are prompted only when the authorization server is configured to ask for them for a given user with a given agent. In most cases, if this user agent (the system browser) presents a cookie for a valid session on the authorization server (a session cookie or a remember-me cookie), the authorization code flow completes silently.

If you want to save the overhead of an authorization code flow when restarting the app, you'll have to find a different storage than memory for the BFF cookies. But:

• It's not that easy to find something as safe as the app memory
• Memory is kept while the app is in the background. So, an app restart on a mobile device is not that frequent.