Token Details not being retrieved reliably across multiple request

Google Cloud Apigee
1 
Hi, we have an API proxy where token details are being retrieved. However, when sending the same request of the same payload multiple times, this error would occur.

"keymanagement.service.invalid_access_token"

10840-screenshot-429.png
10840-screenshot-429.png1071Ă—407 48.3 KB

this is even though, this is a valid token since in the succeeding request, it would be a success as seen below.

10842-screenshot-430.png
10842-screenshot-430.png1199Ă—417 49.1 KB

Why is this happening though?, its just that I was expecting this to be perfectly working and not randomly throw random invalid token error even if the actual token is valid. The code for this, policy that errors out is below.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GetOAuthV2Info async="false" continueOnError="false" enabled="true" name="OAG-GetAccessTokenDetails">
    <AccessToken ref="ExtractedAccessToken"/>
    <IgnoreAccessTokenStatus>true</IgnoreAccessTokenStatus>
</GetOAuthV2Info>

Is there a code snippet that I need to add above for it to reliably get the details of a token?. TIA

2

I don’t have any good ideas for you on this, I’d suggest maybe you could contact Apigee support to help diagnose the problem.

3

Okay, will do. thanks.

4

Hi, apparently this issue is an issue encountered by another team in our organization. And they pointed us to this old thread.

https://community.apigee.com/questions/66906/issue-with-invalidatingrevoking-external-access-to.html?childToView=66953#comment-66953

Upon testing, it is indeed becoming 100% stable after 180seconds / 3 minutes. So this apparently is like a limitation?. or is there any way for us to have the policy check across multiple MPs in apigee so that it could really get the latest state of the token?.

5

I had this happen to me today!

This exact problem!

I was testing something else, but your description of the problem exactly matched what I saw.

I could make a request for a token, and for some of the requests, Apigee treated the token as valid. For others, Apigee treated it as invalid. It seemed indiscriminate. Random.

Here’s the story.

It is related to the cached token properties.

First I created an app, with authorization for a particular API Product. That product did not include the proxy I would subsequently invoke.

I obtained a token, using the app credentials. I then invoked the proxy with that token and received “invalid access token”. this was appropriate because the API Product did not include the proxy in question.

Then I modified the API product. I added my proxy to the product.

Then I used THE SAME TOKEN to invoke the proxy again. This time it succeeded, the token was treated as valid.

Invoking the same call subsequently… I got sporadic success and failure.

The reason for this: though Apigee itself is a “serverless” system, in fact there are servers that run in the cloud. And those servers are distributed, far apart, in separate networks, to allow resiliency in the face of failure. (This is how we deliver four 9’s of availability). The caches on these servers are independent.

The cache on the first server had “old” metadata for the product. The cache on the second server had the updated metadata for the API Product. When my request got handled by the first server, I got “invalid access token”. When it was the second server, the token was treated as valid.

The cache TTL is 180 seconds. Wait a bit, and let the cache expire, and then invoke again, and the token is considered to be valid by both servers.

I suppose the phenomenon you were seeing was due to a similar cause.

1 Like
6

Hi thanks for the reply, we discussed what you said with platform owners and they told us this intermittent responses for the first 3 minutes caused by caching in different servers is something they could tolerate. Thanks.

7

Great, glad to hear it.

Keep in mind that this happens only if you modify the API product or app, after the first time you use the token.

8

in our cause, its not. The product & app has long been created with modifications made months ago. But the intermittent responses still occurs. Though upon testing by our QA, the responses of the API became 100% predictable/stable after 3 minutes which is exactly what you had said will happen if we wait it out.

9

I can suggest using populate and lookup cache, and use the expiry same as the token expiry. So, that during particular token validity it will give you the consistant response.

1 Like
10

I haven’t tried this yet, but is this a proven workaround?, its just that the response of the cache could be affected by caches in different MPs too much like the tokens, isn’t it?. Though I won’t have the chance to try this alright as our project ended already, but would definitely recommend this to as an enhancement if this is indeed a workaround to the intermittent responses caused by the cache. This was asked on the old thread too before and no one answered back.

11

we have implemented this in our organization to avoid latency.

1 Like