How can an Access Token be revoked? When should the different mechanisms that do this be used?

Not applicable
 
Solved Solved
3 2 2,930
1 ACCEPTED SOLUTION

Not applicable

There are multiple ways an Access Token can be revoked, or made unusable going forward. Depending on your specific use case, there are a couple of options.

When processing run-time API traffic, and having the need to handle a logout operation for example or some similar event and desiring to revoke the respective Access Token at that time, the Best-Practice way to revoke the token is to use the OAuthV2 policy with the "InvalidateToken" operation as described in detail here:

http://apigee.com/docs/api-services/content/validating-and-invalidating-access-tokens

The policy you would need to apply would look something like this:

<OAuthV2 name="InvalidateToken">
  <Operation>InvalidateToken</Operation>
  <Tokens>
    <Token type="accesstoken" cascade="false">flow.variable</Token>
  </Tokens>
</OAuthV2>

However, the need may arise where you may have to revoke Access Tokens for the purposes of System Administration (i.e. maintenance, security reasons, troubleshooting, etc.). There is a feature that, once configured for your Organization, allows you to revoke Access Tokens based on User ID, App ID, or both, by making a call to the Management API. This feature is described in detail here:

http://apigee.com/docs/api-reference/content/enable-retrieval-and-revocation-oauth-20-access-tokens-...

One way you might use this function to see and understand exactly how it works would be:

  1. Identify a user for which you want to revoke all of their Access Tokens, getting their User ID.
  2. List out all the tokens for that user (using the User ID).
  3. Make the revocation Management API using the User ID (specific call detailed here: http://apigee.com/docs/management/apis/post/organizations/%7Borg_name%7D/oauth2/revoke)
  4. Attempt to list out the tokens for that user again. The result should return an empty list.

A caveat for revocation using this Management API call is that when revoking an Access Token for it, not only is the respective Access Token revoked, but also respective associated tokens are revoked as well (i.e. Refresh Token). This is referred to as "cascading" the revocation (please see the "cascade" flag in the policy above).

Again, please note that in order to use this feature, it must first be enabled within your Organization.

While similar there is another different function that allows for revoking Access Tokens using Refresh Tokens, described here:

http://apigee.com/docs/management/apis/post/organizations/%7Borg_name%7D/deployments/refreshtokens/%...

With these two very different approaches to revoking Access Tokens, they key distinction here is that the first mechanism is intended and optimized to service Run-Time API Traffic, while the second is for the purposes of manual ad-hoc Administrative Action.

Please note, when using these Revocation Features to use caution, especially with those that allow for Mass-Revocation of tokens (i.e. Management API calls).

View solution in original post

2 REPLIES 2

Not applicable

There are multiple ways an Access Token can be revoked, or made unusable going forward. Depending on your specific use case, there are a couple of options.

When processing run-time API traffic, and having the need to handle a logout operation for example or some similar event and desiring to revoke the respective Access Token at that time, the Best-Practice way to revoke the token is to use the OAuthV2 policy with the "InvalidateToken" operation as described in detail here:

http://apigee.com/docs/api-services/content/validating-and-invalidating-access-tokens

The policy you would need to apply would look something like this:

<OAuthV2 name="InvalidateToken">
  <Operation>InvalidateToken</Operation>
  <Tokens>
    <Token type="accesstoken" cascade="false">flow.variable</Token>
  </Tokens>
</OAuthV2>

However, the need may arise where you may have to revoke Access Tokens for the purposes of System Administration (i.e. maintenance, security reasons, troubleshooting, etc.). There is a feature that, once configured for your Organization, allows you to revoke Access Tokens based on User ID, App ID, or both, by making a call to the Management API. This feature is described in detail here:

http://apigee.com/docs/api-reference/content/enable-retrieval-and-revocation-oauth-20-access-tokens-...

One way you might use this function to see and understand exactly how it works would be:

  1. Identify a user for which you want to revoke all of their Access Tokens, getting their User ID.
  2. List out all the tokens for that user (using the User ID).
  3. Make the revocation Management API using the User ID (specific call detailed here: http://apigee.com/docs/management/apis/post/organizations/%7Borg_name%7D/oauth2/revoke)
  4. Attempt to list out the tokens for that user again. The result should return an empty list.

A caveat for revocation using this Management API call is that when revoking an Access Token for it, not only is the respective Access Token revoked, but also respective associated tokens are revoked as well (i.e. Refresh Token). This is referred to as "cascading" the revocation (please see the "cascade" flag in the policy above).

Again, please note that in order to use this feature, it must first be enabled within your Organization.

While similar there is another different function that allows for revoking Access Tokens using Refresh Tokens, described here:

http://apigee.com/docs/management/apis/post/organizations/%7Borg_name%7D/deployments/refreshtokens/%...

With these two very different approaches to revoking Access Tokens, they key distinction here is that the first mechanism is intended and optimized to service Run-Time API Traffic, while the second is for the purposes of manual ad-hoc Administrative Action.

Please note, when using these Revocation Features to use caution, especially with those that allow for Mass-Revocation of tokens (i.e. Management API calls).

There is a great gap in apigee implementation. 
Provided search APIs only produce list of active access tokens. While any organization would be least interested in short lived access tokens but long lived refresh tokens. 
I found absolutely no way I can invalidate refresh token for a particular user (not to be confused with developer app) if the user has no active access token (but ofcourse refresh token is live)

I understand this is a deal breaker in otherwise good api management platform.