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.