By: Dominique Petitpierre user 03 Apr 2018 at 3:13 p.m. CDT

2 Responses
Dominique Petitpierre gravatar
Hello, how can one revoke a token without a session? Using ```oxauth-rp``` I can see that providing an id token, access token or refresh token to the ```end_session``` endpoint will invalidate the current access token and refresh token. But it seems that the ```end_session``` endpoint [1] cannot work without a ```session_id``` or ```session_state``` cookie. But with a long lived token (e.g. a refresh token with a one year lifetime), browser session cookies will not be available. - In that case, how does one revoke such a long lived token? - In particular, is there a way to use the ```end_session``` endpoint like the ```revoke``` endpoint described in RFC 7009 [2]? (cf. also implementations [3] and [4]) References: [1] [OpenID Connect End Session API](https://gluu.org/docs/ce/3.1.2/api-guide/openid-connect-api/#openid-connect-end-session-api) [2] [RFC 7009: OAuth 2.0 Token Revocation](https://tools.ietf.org/html/rfc7009) [3] [Revoke a Refresh Token](https://auth0.com/docs/tokens/refresh-token/current#revoke-a-refresh-token) [4] [Token revocation](https://connect2id.com/blog/token-revocation)

By Michael Schwartz Account Admin 04 Apr 2018 at 1:01 p.m. CDT

Michael Schwartz gravatar
1. Don't issue the refresh_token grant if you don't want the client to have this capability. 2. Refresh tokens are not the same as a browser session cookie. You can't use a refresh token to establish a session. You can only use it to obtain an access token, which will let you call userinfo.

By Dominique Petitpierre user 04 Apr 2018 at 2:53 p.m. CDT

Dominique Petitpierre gravatar
Hello, thanks for your post! It leads me to further questions: > 1. Don't issue the refresh_token grant if you don't want the client to have this capability. a) Since a refresh token can be used to obtain another refresh token, does your comment mean that it is impossible to prevent "infinite" renewal of tokens? (i.e. in that situation a "logout" or invalidation of a compromised refresh token is impossible if the token was obtained without a browser (e.g. ```grant_type=password```)). b) Does your comment mean that gluu will not implement RFC 7009 (OAuth 2.0 Token Revocation)? c) Can a client be configured so that a refresh token can only be used to obtain an access token without another refresh token? Since the validity of the refresh token can be set in the client configuration, that would put a customizable capping to the duration while access tokens can be obtained (instead of the global default). I tried this: After removing the grant type ```refresh_token``` from the client configuration, a request for an ```id_token``` with ```grant_type=password``` still provides an answer that contains a refresh token. But that refresh token cannot be used to obtain an access token. You will say that it is to be expected, but what is then the purpose of providing that refresh token when it cannot be used? > 2. Refresh tokens are not the same as a browser session cookie. You can't use a refresh token to establish a session. You can only use it to obtain an access token, which will let you call userinfo. d) Using the ```end_session``` endpoint does revoke the refresh token, so gluu maintains a relationship between the ```session_id``` parameter and the refresh token. Does the refresh token expire when the ```session_id``` expires? (global default: ```sessionIdLifetime```=86400 seconds) e) Is there a tool that provides a "dashboard" or "current state" view accessible by the administrator or the user to list a user's current sessions and tokens with the possibility of ending or revoking them? Thanks in advance for your precisions!