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 368
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

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. 

 

Thank you....just wanted to update you the same. with different authorization codes it works fine.