Is there any relationship between SSO session management and the management/timing out of refresh tokens? Especially when working with public clients (like SPA’s) which are using the implicit grant, it seems that silent authentication (based on an existing SSO session) serves the same purpose as a refresh token, basically to obtain an access token.
If the SSO cookie/session has timed out (maximum 7 days), then silent authentication will fail, and the user has to login again in order to obtain a new access token. This seems not to be different from using a refresh token to get a new access token. If the refresh token has already timed out (similar to SSO timeout) or has been revoked (similar to single logout), then the call will result in an error, and the user has to login again.
So my question is whether centrally timing out SSO (or explicitly logging out from SSO) should also result in ALL refresh tokens to be revoked.
Also, in case of certain client types (i.e. the ones which can’t ensure proper secure storage) which can’t handle refresh tokens, the backend SSO session mgmt. capability can be used to achieve the same user experience via silent authentication, i.e. despite using a public client, the user doesn’t have to enter credentials again.
So even SSO and refresh tokens are different, there seems to be some overlap.
Or to ask differently, why does auth0 choose to keep SSO sessions valid for maximum 7 days while refresh tokens are typically valid for much longer timeframes?
Is this due to some risk related differences or rather for scalability reasons as auth0 would have to provide server resources to keep all these sessions alive while refresh tokens are mostly handled client side? Revocation of refresh tokens also requires server side storage.
Is there any relationship between SSO session management and the management/timing out of refresh tokens? (…)
If the SSO cookie/session has timed out (maximum 7 days), then silent authentication will fail, and the user has to login again in order to obtain a new access token. This seems not to be different from using a refresh token to get a new access token. (…)
So my question is whether centrally timing out SSO (or explicitly logging out from SSO) should also result in ALL refresh tokens to be revoked.
In general, refresh tokens as specified within OAuth2 will either have really long-lived lifetime (sometimes years) or they don’t expire at all and can only be revoked. Due to this characteristics they are mostly suitable for client application that can ensure proper secure storage. With SPA’s (browser-based applications) storing these type of tokens would be very high risk (you would be one XSS away from leaking long-lived credentials) so they are not used for this type of client applications.
Additionally, the premise for refresh tokens is that when you grant them to a suitable client application you’re granting the ability for that application to act as you even when you’re not present (usually refresh tokens are requested by asking for the offline_access scope which hints at this ability). They can also be requested through means that never even trigger the creation of the traditional browser SSO session, because the client application may be a mobile application that is exchanging a username/password for a refresh token directly with the authorization server and without any intervention of browsers.
In conclusion, due to these reasons (and possibly other that I might have forgot) the termination of a SSO browser session (logging out) should not and usually does not affect the issued refresh tokens. Refresh tokens would be managed independently and revoked based on other conditions.
This is the general situation, nothing stops someone from implementing a system where triggering a logout (SSO session termination) also triggers the revocation of all the refresh tokens that have been issued in association with that user. However, I don’t think this is common.
Also, in case of certain client types (i.e. the ones which can’t ensure proper secure storage) which can’t handle refresh tokens, the backend SSO session mgmt. capability can be used to achieve the same user experience via silent authentication, (…)
So even SSO and refresh tokens are different, there seems to be some overlap.
Or to ask differently, why does auth0 choose to keep SSO sessions valid for maximum 7 days while refresh tokens are typically valid for much longer timeframes?
Is this due to some risk related differences or rather for scalability reasons as auth0 would have to provide server resources to keep all these sessions alive while refresh tokens are mostly handled client side? Revocation of refresh tokens also requires server side storage.
In general, browser session will have an associated timeout, not just an absolute one, but also an idle one. In terms of the duration I don’t honestly know why the default of seven days was chosen, in general it will be decided to balance risk versus user experience. Also have in mind that value is configurable on your advanced account settings.
In relation to why impose a timeout on session and not on refresh tokens one explanation is that refresh tokens can be made to represent an authorization grant smaller than a full permissions to do whatever the user does. For example, an application can request a refresh token associated to having read permissions to the user account for the purposes of monitoring. This ability to associate a refresh token to a smaller subset of all the permissions a user has makes them more viable for longer or non-expiring lifetimes.
1 Like