I want to revoke all previously issued OAuth access tokens associated with a specific API key before generating a new one.
As of now, I see that Apigee provides an option to revoke tokens using the App ID, but that revokes access tokens for all keys linked to that app. This does not work for my use case, as I only want to revoke tokens tied to one specific key.
Is there any way to revoke access tokens for a single API key (consumer key) without affecting other keys under the same app?
Note: I do not store access tokens on my side, so cannot revoke a token by passing its token value.
Is there any specific reason why your OAuth tokens are not being stored within the Apigee policy constructs? The way I see current state is as follows:
We have policies to Revoke OAuth tokens by access/refresh token, or by developer/end user application (which meets most use cases)
We do not have any management APIs to link an API key to a set of 1-N access tokens, meaning you could not build anything custom on this front
If you are able to explain your use case a bit more we may be able to devise a plan forward accordingly, thanks!
We are using Apigee OAuth (Client Credentials flow), and in our use case:
Users can generate multiple API keys under the same App.
Each key can have its own access token.
We do not store access tokens in our database.
What we want to achieve:
If a user requests a new access token using Key1 (before the previous token has expired), we want the old token for Key1 to be revoked automatically — but tokens issued for Key2, Key3, etc. should remain active.
This is not supported by the product. As mentioned, there’s revocation available at the app level. With that said, why do you have multiple keys per app and concurrent use of them? Additionally, another potential alternative to full revocation is use to use shorter expiry times to minimize overlap of tokens
We have a use case where multiple users share the same App, but each user is assigned a different API key. In this setup, we do not want to revoke the entire App or other keys — we only want to revoke previously issued tokens when a new token is generated for the same key.
We have identified a potential approach using the EndUserId attribute during token generation which is populated with the client key. When a new OAuth token is created for a specific key, we can use the Revoke policy with EndUserId to revoke the earlier tokens associated with that same key before issuing the new token.
This helps ensure that only the previous tokens for that specific key/user are invalidated, while tokens for other keys remain active.
The payload should be empty for this POST request.
Please note, the effect is to revoke the key as well as any tokens that have been obtained for the key. There is a cache managed in the Apigee runtime with TTL of up to 180s, so the “revoke” action may not take effect immediately. For example, an access token might have a lifetime of , let’s say, 4 hours. The cache TTL is 3 minutes. If you Revoke right now, then, … for up to 3 additional minutes a token previously obtained for that particular consumer key (aka APIkey) will be treated as valid. After the cache gets refreshed such access tokens will be treated as invalid (revoked) by the runtime, even though the access token itself has not expired.
You can also “approve” a revoked key, which reverses that action. This is also gated by the runtime cache .
The administrative approach I just described… will not work for your purposes, as it applies to all tokens obtained for a key, and there is no way to limit the revocation to “all tokens except the latest token”.
BTW You can also/alternatively perform an administrative revoke of:
the APP. This would cause all keys, and all tokens, regardless of the credential used to obtain them, to be treated as revoked.