Two proxies, sharing oauth token, attributes missing ?

Not applicable

I have two proxies, sharing oauth tokens. A third proxy, generates token. Proxy-1 after verifying token, adds some token attributes using SetOAuthV2Info. Proxy-2 after verifying token - tries to access one of the attributes - but it is sometimes missing ( 2/8 times) I have explicitly tried using GetOAuthV2Info policy, but some attributes are still missing (2/8 times). I add 7 attributes, 4 are always availalbe, 3 are missing (2/8 times). On-Prem installation, 2 message processors, Can this inconsistency be explained ? Is there a workaround, forceful refresh on the token attributes ?

Solved Solved
1 4 157
1 ACCEPTED SOLUTION

It's possible that the Token cache is causing the behavior you are observing.

Try this test: after adding attributes, wait 3 minutes, and only THEN try the next request.

Do you see all the attributes?

Today there is no way to "force refresh" of token attributes.

If you need to dynamically map tokens to different attributes, I suggest you use an explicit database or datastore in which you can control the caching. For example, use the Apigee Edge Cache. You might set the TTL on the attributes list to have an expiry just after the token expiry.

Or, use BaaS. In that case you will need to clean up token entries in the BaaS after the tokens expire.

Helpful?

View solution in original post

4 REPLIES 4

It's possible that the Token cache is causing the behavior you are observing.

Try this test: after adding attributes, wait 3 minutes, and only THEN try the next request.

Do you see all the attributes?

Today there is no way to "force refresh" of token attributes.

If you need to dynamically map tokens to different attributes, I suggest you use an explicit database or datastore in which you can control the caching. For example, use the Apigee Edge Cache. You might set the TTL on the attributes list to have an expiry just after the token expiry.

Or, use BaaS. In that case you will need to clean up token entries in the BaaS after the tokens expire.

Helpful?

Thanks for the response; Our requests are almost back-to-back.. (we cant wait few minutes). We tried adding a javascript policy, that runs in a loop until attributes are available, but that did not work out. I will be discussing your caching suggestion as a possible solution for the team...

Glad to help. The cache option will probably work. Cache reads are not cached!

We had some initial success, using a cache for storing token attributes - but now we have started seeing cache lookup fails (randomly) - some succeed and some fail - for the exact same cacheKey - hardly seconds apart. We had set the TimeOutInSec to 1800 (30 mins).

Is it the case, that different message processors, are reading the different requests and the cache is not quite in sync ? We cannot delay our - back-to-back requests...