Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

3 legged Oauth Mechanism for multiple access tokens generated using a single refresh token.

Hi, 

I have a scenario for 3legged OAuth security that I have put in place in my Apigee Edge. 

Step 1:

Auth code is generated , with validity of 60 seconds, and the response comes along with a endUserId VALUE WHICH WE TAKE AS IDENTIFIER IN THE REQUEST PARAMS.

Step 2:-

With obtained auth code and Identifier , make a request to access token. The acces token response will contain the complete details like scopes, enduserId attribute, accessToken, refreshToken  with a validity of 24 hours for access token and 90 days for refresh token. 

Step 3: using the refresh token obtained , i can request for new access token within 90 days, every time i make a request , a new access token comes in response and refresh token remains same, a counter is maintained  with a value of no of hits to the refresh token api. 

Observation:-

every time I request for a new access token using the refresh access token, say about for example - I repeated the 3rd step 2 times (after step 1 and 2 is done), If i use the latest access token, i can make my service call and verify access token is passed successfully.

But if i use, penultimate access token or the first token, even though they are not expired (not more thna 24 hours), I get an error message as INVALID ACCESS TOKEN .  I want to know why is this behaviour, is it genuine or did i miss anything.

Because , for normal 2 legged oauth 2 , When i request for multiple access tokens within 24 hours all of them, are valid. But that not happening for 3 legged oauth. 

Solved Solved
1 2 535
1 ACCEPTED SOLUTION

Yes, thank you for your detailed and clear description of what you are trying, the results you are seeing. 

What you describe is the expected behavior with 3-legged OAuth tokens. 

If you need to have "parallel" tokens, then you need to go through steps 1 & 2 multiple times, obtaining distinct authorization codes.  Then each distinct access token, or one of its "children" (generated via step 3) will be valid. 

 

View solution in original post

2 REPLIES 2