Apigee Management api to revoke access token by end user Id is not working consistently
When I try to revoke all the access token issued to a user using the management API (https://docs.apigee.com/management/apis/post/organizations/%7Borg_name%7D/oauth2/revoke), I have found that its behaviour is pretty flaky.
I understand that we get 202 in response which means that the request to revoke access token has been accepted, and it takes some time to process. Many times all the access tokens are revoked within few seconds and sometimes none is revoked.
Thanks
Hello @aagrawal, this looks to be a product functionality concern. Have you considered opening a Support ticket? We can get more details to understand the situations where access tokens are not getting revoked.
+1 on @Alex Koo' comments. Is this behavior consistent ? Did you make the GET call to see if the tokens exist ? We will need more info to investigate. I would also recommend you to open a support ticket
Thanks @Alex Koo and @Sai Saran Vaidyanathan for your quick response. The behaviour is pretty inconsistent. Sometimes it revokes immediately and sometimes it takes forever, sometimes it revokes the access token, but not the associated refresh token. That I have confirmed by making the GET calls on the access tokens.
I have already raised a support ticket, but thought that community will also be a great platform to address my issue.
We face some similar issue, we've two platforms:
1. On-premises(used for Dev & Testing ENVs):
a) It works fine here, consistently revokes the tokens are recooked within few seconds of an enduserId.
And
b) GET call works fine here.
2. Private cloud(used for higher ENVs):
a)It works fine inconsistently and revocation takes longer than On-premises case(much longer, >15mins)
b)Sometimes it doesn't work at all and we get below error:
{ "code": "datastore.ErrorWhileAccessingDataStore", "message": "Error while accessing datastore;Please retry later", "contexts": [] }
However GET call for the same userId works.
Note: One important difference is that the issue where we see(2nd platform) is used for performance tests where we've millions of access_tokens created for an userId(which have long expiry like 6months)- could this be reason for 2.b?
