How to reuse of OAuth 2.0 Access Token generated by client IDP.

I need to call my partner API which is OAuth enabled. Before calling the actual service,
I need to call the token generation service and with that access_token, I have to call the original service. My question is how to reuse the access_token, which is having 1 day of expiry in time. and how to check the validity of the token and where can I save the token? If the token is valid, I don't want to call the token service, if not I have to call the token service. Please suggest.

1 4 2,404
4 REPLIES 4

What I understand is that when you say "I have to call the original service", you mean to imply that you will configure Apigee Edge to call the original service. In other words Apigee Edge will act as the client to the IDP and to the original service.

If so, then Yes, this is a common pattern. Here is what I recommend:

  • use the Apigee Edge cache to store the token
  • The cache is a key-value store. As the key, use an identifier that is unique to that token. If you will get a different token for each user, then you must include the userid into the cache key. if you will share tokens across users, but employ the same token for each *client*, then use the client_id as part of the cache key
  • set the time-to-live on the cache entry to be the same as the OAuth token lifetime. To compute this, you may need to resort to JavaScript to parse the OAuth token response from the IDP.

The flow will be something like this:

  • request arrives in Apigee Edge
  • AssignMessage - to create compound cache key (this may be something as simple as referring to client_id)
  • LookupCache - with the cache key
  • If not found, then
    • ServiceCallout - or AssignMessage and ServiceCallout - create and send the request to the external IDP to acquire a new token
    • If Failed, RaiseFault.
    • JavaScript - receive and parse the response, including the expiry.
    • PopulateCache - insert the token into the Edge Cache
  • call the original service with the token

@Dino - Thanks for your reply. Currently my api is working with every time calling the external IDP to get the token using Service callout. I am clear to use the populate cache to store the access key and Lookup cache to retrieve/assign the cache value to a variable. But I am not sure about the Route Rule, If the cache key is not available to call the service Callout otherwise call the Endpoint proxy service? Please Suggest.

I think you want to use the ServiceCallout as a normal policy. There is no special RouteRule required. The target is always the same, so you should be able to use one RouteRule with no Condition. The only thing that varies is the set of policies that runs BEFORE the target gets invoked. In the case where the token is in cache, then ... the flow will not invoke ServiceCallout. In the opposite case, then the flow will invoke ServiceCallout (and the other policies I mentioned above).

Mohana - you can put a <Condition> that evaluates the cachehit variable after the LookupCache poilcy is called or simply check for the value of the variable you are using to retrieve the cached token. If the cachehit = false, then implement the steps above to make the ServiceCallout JS, PopulateCache,... else if true called the target backend service with the token found in the cache.