Overview
The Refresh tokens associated with a session are still usable with the “refresh token” grant flow after the back-channel logout has invalidated the associated session.
This article explains why this is happening and why the “session-expiry” back-channel initiator does not seem to respect the application layer session for expiry, such as extending session length through the refresh_token grant flow as above.
Applies To
- Refresh Tokens
Solution
The refresh token does not get invalidated on back-channel logout due to the implementation of the OpenID Connect standard, as quoted below:
- “Refresh tokens issued with the offline_access property normally SHOULD NOT be revoked.” (Reference at this link )
This also means that the follow-on behavior is up to the customer’s application. For example:
- The application could be configured to drop all session-associated access tokens and then revoke the refresh tokens for the user session using the Management API. Please see the Refresh token properties.
- The application could continue to honor tokens created from the refresh tokens. This should be combined with limiting the refresh token lifetime or setting Inactivity Expiration. Care should be considered on this implementation and desired outcomes to ensure users cannot sidestep intended session constraints
The “session-expiry” initiator works on the SSO session cookie at the ‘Auth0 Session Layer’ (Reference here). This session cookie has a session_id (sid) that is linked to all child tokens created, including the refresh_tokens and subsequent access_tokens.