BFF Sessions and Timeouts

[joshkohring]

Following the tutorial from https://www.baeldung.com/spring-cloud-gateway-bff-oauth2, I'm not sure how to handle sessions and expirations.

The tutorial mentions https://www.baeldung.com/spring-cloud-gateway-bff-oauth2#bd-spas:

A UserService fetches current user data from the resource server through the BFF. It also holds some logic for scheduling a refresh of this data just before the access token on the BFF expires.

and

Schedule a refresh() call just before the access token expires (keep the session alive).

If the session does timeout on the BFF, requests will then result in a 401 as expected. The SPA can then navigate back to login to initiate a new one. However, this results in orphaned offline sessions in Keycloak as the offlineSessionIdleTimeout is set to 30 days and BFFs Spring defaults to 30 minutes.

Does the offlineSessionIdleTimeout need to be lowered to match the BFF session (e.g. 30 minutes)? Or, does the BFF need to let keycloak know the session has expired? Or are these orphaned sessions ok since the refresh token is never exposed?

[ch4mpy]

Maybe there's a misconception here: What do you mean by "orphaned" above? Keycloak's session is more of a "parent" than a "child" of the BFF one.

The user session on Keycloak should be set to match the SSO needs (Single Sign-On): it determines how long the user can be authenticated without providing credentials, regardless of the client. The BFF for your SPA is one client, but other clients could use the same realm, being delivered tokens for the same user without him needing to input credentials, as long as he uses the same browser session within Keycloak's session lifetime.

If you consider the SSO session too long, lower it in Keycloak, keeping in mind that SSO is a great user experience, which is the reason for the success of OpenID Providers. Users usually don't like to log in repeatedly, even in tabs that are kept open without activity for a while. For instance, think of how long you can use Google's apps (Gmail, YouTube, Drive, etc.) without authenticating again.

Closing the user session on Keycloak when the BFF session expires would break SSO and should end other clients' sessions. This is something that should be avoided.

It is not possible to revive a user session with the refresh token flow after the BFF session has expired. This is because all tokens are stored in a session, which is destroyed when it expires (its content being deleted). As a side note, it implies that the refresh token's lifespan should be at least as long as the client's session (the BFF in your case), or this client would fail to refresh tokens if a user sends a request after the refresh token has expired but before the session does, resulting with an active session without tokens :/.

The aim of the "keep-alive" I wrote in the tutorial is to prevent the BFF session from expiring as long as the app is present in a tab. This is not something we'd want in a banking application, but it would be useful in many other apps, like a forum or a web shop. I prefer such a keepalive over a retry after a 401 (with auto-login if Keycloak's session is still alive) because it offers a slightly better user experience (saves the latency of round trips between the front & back ends and between the back end & Keycloak). But the two are not exclusive: such an interceptor with a single retry on 401 would be useful in other situations (like when opening the app in a new browser session and an active Keycloak remember-me cookie).

If this can be of help, I posted some info about how I configure BFF & OP sessions in this Auth0 thread (the brand of the provider is not important on this subject). Only the 2nd half of my post is relevant to the subjects you're interested in.