OAuth revoke all issued token on user logout


Is there any way to revoke all the issued token on user logout? 

The app can revoke the Refresh Token, but not the Access Token. We're looking for some way to revoke all the tokens when the user logout from the IDP.


  • In OAuth, there is no way to revoke an Access Token. This is why they should be short-lived. 

  • The RFC7009 about OAuth 2.0 Token Revocation says:

    "This document proposes an additional endpoint for OAuth authorization
    servers, which allows clients to notify the authorization server that
    a previously obtained refresh or access token is no longer needed.
    This allows the authorization server to clean up security
    credentials. A revocation request will invalidate the actual token
    and, if applicable, other tokens based on the same authorization


    "Implementations MUST support the revocation of refresh tokens and
    SHOULD support the revocation of access tokens (see Implementation

    So it seems that the RFC does allow the revocation of Access Tokens and not only Refresh Tokens.


  • Check this:


    There it is written: "Revocation endpoint is used for revoking refresh tokens and its corresponding access token."

    But please note that this must be triggered from OAuth application (you need to pass client id, secret and refresh token you'd like to revoke), which is also in line with what you mentioned in RFC:

    "... allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed ..."

  • Revoking an Access Token at the IDP has NO EFFECT at the resource server. The resource server does not make a call to the IDP each time the token is used. There is no mechanism to notify the resource server.  So the client could stop using it and call the IDP to ask that it be revoked....then what?


  • Here is the key "In the former case, some (currently non-standardized)" . If you'r doing things according to the actual OAuth standard then there is no revoking an Access Token.


    OAuth 2.0 allows deployment flexibility with respect to the style of
       access tokens.  The access tokens may be self-contained so that a
       resource server needs no further interaction with an authorization
       server issuing these tokens to perform an authorization decision of
       the client requesting access to a protected resource.  A system
       design may, however, instead use access tokens that are handles
       referring to authorization data stored at the authorization server.
       This consequently requires a resource server to issue a request to
       the respective authorization server to retrieve the content of the
       access token every time a client presents an access token.
       While these are not the only options, they illustrate the
       implications for revocation.  In the latter case, the authorization
       server is able to revoke an access token previously issued to a
       client when the resource server relays a received access token.  In
       the former case, some (currently non-standardized) backend
       interaction between the authorization server and the resource server
       may be used when immediate access token revocation is desired.
       Another design alternative is to issue short-lived access tokens,
       which can be refreshed at any time using the corresponding refresh
       tokens.  This allows the authorization server to impose a limit on
       the time revoked when access tokens are in use.
       Which approach of token revocation is chosen will depend on the
       overall system design and on the application service provider's risk
       analysis.  The cost of revocation in terms of required state and
       communication overhead is ultimately the result of the desired
       security properties.


  • Then that token cannot be verified using token introspect endpoint (or token info endpoint, which is deprecated).

  • The main issue here is that the application is using the Implicit Grant, that doesn't support the issuance of refresh tokens. 

    So if we logout from the IDP on a browser tab, this doesn't revoke the tokens used for the same application open in other browser tabs.

    Do you think the new OIDC Front-Channel Logout Support feature of NAM 5.0 is going to help on this?


  • Client logout has nothing to do with the IDP. The client should handle that by destroying the token. 

  • We had similar problem with some OAuth applications.

    Instead of revoking tokens we went other way and assumed that if user would click logout in application, application itself would clean everything needed (from tokens to session cookies).

    So we made a list of application logout URLs (using fiddler, network tab, whatever you prefer) and call all those URLs in hidden iframe as part of logoutSuccess_latest.jsp

    For example, if application logout URL would be https://app.something.com/logout, then we would add something like that to logouSuccess_latest.jsp:

    <iframe id="remoteContent" src="https://app.something.com/logout" WIDTH=0 HEIGHT=0 frameborder=0></iframe>


    Please note that some of applications might not allow themselves to be called in iframe...

  • But at the documentation I read:

    This feature supports the following two forms of logout request:

    - Identity Provider initiated logout request: Allows a user to log out from all client applications when the user logs out from Identity Server.

    - Relying Party (client application) initiated logout request: When a user initiates logout from one client application, the user can authorize to log out from Identify Server and other logged-in applications.

    So, as I understand it, seems to be just what we're looking for. Or maybe I get it wrong.