The access token is still working even after successful execution of Oauth policy(operation "InvalidateToken"). The access token that goes under the OAuth policy is still authorizing the API calls, infact it should get revoked.
To optimize performance, the Apigee gateway keeps a cache of tokens. When a request arrives at the gateway with a token that ha snot yet been seen, the gateway looks up the token in the persistent token store. The result of that lookup contains the tokens validity, its expiry, and a bunch of other data about the token. All of that data is stored in an in-memory cache in the gateway.
In general every Apigee installation uses multiple distributed gateways to handle inbound requests. When you send in a request that executes "InvalidateToken", that particular gateway node will perform a write update to the persistent token store, and will invalidate the token in its own cache, if it is present there. But all the other gateway nodes that have previously "seen" that token, will keep that token and its data in the in-memory cache. If you send a subsequent request in which is handled by one of the other gateways, you should expect the other gateways to honor the token as valid, up until the cache expiry, which is 180 seconds.
If you send repeated calls with the same token, you should expect to see it be accepted sometimes, and rejected at other times, until that 180 seconds elapses.
One more scenario I came across where in I tried 5 iterations of generating access token, 4 out of 5 access token were generated with the help of a refresh token call. So what I observed is 4 out 5 random access token successfully got revoked but one didnt.
I am not clear what you;re describing here. I'd be glad to look into it, talk it over with you, but you'll need to explain it more clearly for me.
LinkedIn
Twitter
