2

I have an Relying Party that has obtained an Access Token and Refresh Token (as well as an ID Token) from an OpenID Provider (not an offline token).
In all cases I have seen, the Refresh Token is invalidated when the user logs out from the OpenID Provider.

When I have an OAuth Client that obtains an Access Token and Refresh Token, this Client should be able to access the ressource even when the user is not present - and Authorization Servers do not invalidate the Refresh Token once the user logs out from the Authorization Server.

However, I have not found a word in any of the standards that says something about invalidating Refresh Token obtained through OIDC when the user logs out from the OpenID Provider.
Is there any source hinting to that?

1 Answer 1

4

From OIDC back-channel logout draft 06:

2.7. Back-Channel Logout Actions

Refresh tokens issued without the offline_access property to a session being logged out SHOULD be revoked. Refresh tokens issued with the offline_access property normally SHOULD NOT be revoked. NOTE: An open issue for the specification is whether to define an additional optional parameter in the logout token, probably as a value in the event-specific parameters JSON object, that explicitly signals that offline_access refresh tokens are also to be revoked.

...and a reminder about the difference between back-channel and front-channel logout. Back-channel is:

a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.

The revocation of the refresh token is not mentioned in any other session management/logout drafts: front-channel logout draft 04, session management draft 30 or RP-initiated logout draft 01. Given that these are drafts and not approved RFCs, the implementations can choose to comply or not comply with the language.

From a real-world perspective, we agree with the wording in back-channel logout draft. It makes sense for refresh token to be revoked unless it was explicitly acquired for offline use. Hopefully the same perspective and language are incorporated in future front-channel and RP-initiated drafts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .