Backend OAuth token expiry management

Am exploring Apigee Edge to be used in the context of following layers:

client browser / app -> my serverless functions -> Apigee proxy -> several external backend services

The backend services are REST with "classic" OAuth 2 access token which after expiry must be renewed with a refresh token. Obviously each backend has their own set of OAuth credentials (client id, secret, access token, refresh token).

Now I'd like to let Apigee manage that token renewal process, ideally it can store the refresh token and can have a simple renewal logic programmed in when querying the backend REST: "if-access-token-expired-then-fetch-a-new-one-with-this-refresh-token-and-continue-with-request" .

How to do this?

Am I looking at the problem from the right angle or there is more suitable solution in the Apigee world given the layers above?

 

 

Solved Solved
0 1 1,025
1 ACCEPTED SOLUTION

You need to implement this logic as part of shared-flow (I would do that).

In this scenario I see Apigee =>>>> backend, right? Who managed the OAUTH2? Backend? If this is system-to-system call, why wont you use client_credential grant_type and you dont need any refresh tokens, just generate new one or write logic that will check the timestamp of the generated token and issue new one. 

 

If this is not the case, I would suggest:

The logic goes: 

- generate access_token based on XYZ logic, and store it to cache with multiple keys: [token|expiration date]

- next time you will get the cache value, check if time now > token expiration, if yes - regenerate token and restore it to cache, if not - grab the token and pass it to backend. 

View solution in original post

1 REPLY 1

You need to implement this logic as part of shared-flow (I would do that).

In this scenario I see Apigee =>>>> backend, right? Who managed the OAUTH2? Backend? If this is system-to-system call, why wont you use client_credential grant_type and you dont need any refresh tokens, just generate new one or write logic that will check the timestamp of the generated token and issue new one. 

 

If this is not the case, I would suggest:

The logic goes: 

- generate access_token based on XYZ logic, and store it to cache with multiple keys: [token|expiration date]

- next time you will get the cache value, check if time now > token expiration, if yes - regenerate token and restore it to cache, if not - grab the token and pass it to backend.