@nelson.matias thanks for your answer.
None of Google, Facebook, LinkedIn, and many others use public clients (in a browser’s debugging tools, we can find session cookies but no Bearer access token). So, configuring single-page and mobile applications as public clients isn’t something we have to do. And according to an increasing number of recommendations, we shouldn’t do this, even with PKCE. One of the serious sources explaining why is this Spring Security team post (almost 4 years old, but still accurate). Browse to “Final Recommendation” if not feeling like reading the all post.
I wrote an article for Baeldung. You can link to it or copy from it. It contains a Spring profile to switch from Keycloak to Auth0: add the audience parameter to the authorization request (as required by Auth0) and use different claims for username and roles.
According to the OpenID spec: “The use of Refresh Tokens is not exclusive to the offline_access use case”.
Provided that a user has an active session on the authorization server, a client should be able to refresh tokens even without the offline_access scope. In that situation, the authorization code flow should run silently too (without prompting the user for credentials) but would use more resources and introduce more latency (get a new authorization code and then exchange it for tokens in another request).
So, refresh token flow is preferable even for “online access”.
I have been using exclusively the OAuth2 BFF pattern for more than two years now. This is how I currently set things:
- Duration of the session on the authorization server <= duration of refresh tokens. As seen above, if the session is longer, new tokens can be issued silently using the authorization code flow or a remember-me cookie, but that’s less efficient than the refresh token flow.
- In SSO environments, the duration of refresh tokens may depend on the client (some “sensitive” clients use shorter-lived refresh tokens).
- As, in the OAuth2 BFF pattern, tokens are stored in the client’s session, this session should last at least as long as the refresh tokens for them to be useful.
At the end of the day, the easiest option is to use the same duration for refresh tokens, the session on the authorization server, and the session on the client. In the case where I have no other choice than to have different durations for clients of the same SSO, I set the authorization server’s session to the shortest of these durations, and, for each client, the same value for the refresh token and BFF session.