Revoke access token for an user id : impact analysis of management server's performance

My requirement is to expose an api will invalidate all the access token associated with a user id. This requires management api call. As management api runs on management servers I am wondering if i need to set up any quota on this. I am also hesitant to expose such api as if allow the api consumer to call this api too many times, there will some impact on the management servers. Can you please put your thoughts on this?

Solved Solved
0 5 256
1 ACCEPTED SOLUTION

The API Runtime for Apigee Edge is designed to auto-scale and it will support 1000's or 10's of thousands of requests per second, or more. This means you can build your own custom API proxies and the Apigee Edge runtime will enforce the rules you specify.

The Apigee Edge Management API is not designed to support 1000's or 10's of thousands of requests per second. It is designed to be highly available, but not at that scale of concurrent requests.

It is generally a bad idea to create an API Proxy in the Apigee Edge runtime that depends on an Apigee Edge Management API. However, in some exceptional cases, it may be warranted. Yours may be one of them.

  • understand that an API Proxy that calls an Apigee Edge Management API involves an additional security impact.
  • Understand that you must obtain and manage credentials for the Management API in the API Proxy.
  • Understand that you will need to take special care about rate limiting and abusive behavior. For example you may wish to rate-limit it to 2/month for each user.

You didn't say how often you expect this API to be called, but if it is expect that your apps will call it relatively rarely, then perhaps it's ok to have this dependency.

View solution in original post

5 REPLIES 5

The API Runtime for Apigee Edge is designed to auto-scale and it will support 1000's or 10's of thousands of requests per second, or more. This means you can build your own custom API proxies and the Apigee Edge runtime will enforce the rules you specify.

The Apigee Edge Management API is not designed to support 1000's or 10's of thousands of requests per second. It is designed to be highly available, but not at that scale of concurrent requests.

It is generally a bad idea to create an API Proxy in the Apigee Edge runtime that depends on an Apigee Edge Management API. However, in some exceptional cases, it may be warranted. Yours may be one of them.

  • understand that an API Proxy that calls an Apigee Edge Management API involves an additional security impact.
  • Understand that you must obtain and manage credentials for the Management API in the API Proxy.
  • Understand that you will need to take special care about rate limiting and abusive behavior. For example you may wish to rate-limit it to 2/month for each user.

You didn't say how often you expect this API to be called, but if it is expect that your apps will call it relatively rarely, then perhaps it's ok to have this dependency.

Hi @Dino,

In my requirement, there will be an option for the user to logout from all devices. This should invalidate the user's all active token. The number of user of this mobile app is 4000. As of now, we don't have concurrent requests count. I am wondering if there another solution to this problem? Also wondering if anyone else encounters such requirement.

I have seen this requirement before with other customers and there is another possible solution that requires a bit of extra effort.

  • Create a user data store where you can set a flag when a user logs in. This should be accessible via API. You could use something like Firebase Realtime Database
  • When a user logs out, revoke their current token and issue a call to the user data store to change the flag indicating the user has logged out. Note that you can use the OAuthV2 policy to revoke access tokens without calling the management API.
  • When generating an access token from a refresh token check against the user data store to see if the user has logged out. If so do not generate an access token.

Please realize that this is a less than ideal solution. It relies on the fact that you are using refresh token flow and works best with fairly short lived access tokens. Technically if a user had a valid access token on another device they could still use that device until the access token expired. That said, this solution could handle many concurrent calls.

Given your user count and assuming most users don't actively log out on a regular basis you might choose to use the management API call. If that is the route you choose, please heed the advice Dino provided in his answer and follow these instructions for enabling the functionality to revoke by end user ID.

Hi @gregkuelgen

You are asking the app to maintain the access token at device database and revoke as per user action.

My requirement is little different. A user can log into the app from multiple devices and if the user clicks "logout from all device" we should revoke all the access token issued for the user from all the devices.

any thoughts on this other than retrieving all access token for a user id and revoking those by using management api?

I think I understand your requirement. I am not sure how exactly you would retrieve the access token for the user without having setup your Organization and OAuth proxy to use an "end user id". That said, if you follow the instructions to do that here you can then use the following management API call to revoke all the tokens for the user.