Requirement: In OAuthV2 policy with operation as RefreshAccessToken (/refresh call), by providing valid refresh token(RT1) we will generate new AccessToken/RefreshToken(AT2/RT2) pair. But due to technical issues/partner side network issues, if partners did not receive the newly generated AT2/RT2 pair(note: Apigee successfully generated & sent AT2/RT2 as a response), they should be able to use the older refresh token to generate another AT/RT pair. That is, in technical issue scenarios, we should be able to fallback to the previous refresh token.
But whenever we generate new AT2/RT2 by providing valid RT1 in the /refresh call, immediately old RT1(came as part of request) gets invalidated.
So I am trying to implement a logic as below:
Whenever we generate new AT2/RT2 pair, before sending the response: AT2/RT2 , I would like to associate this AT2/RT2 pair to RT1. So that if partner don't receive this AT2/RT2 pair, they will retry /refresh call with RT1 (that is the one they have in hand) and apigee finds the given refresh token is invalidated..So I am adding a logic here to check whether any custom attributes associated to that token, if yes - will extract that custom attributes & with the help of RT2- will generate new AT3/RT3 and send AT3/RT3 to the partner. If custom attributes are not associated, then we will throw error message to the partner as: Invalid refresh token.
Question: While implementing the above, I am able to extract custom attributes associated to RT1 (though RT1 is invalidated) but not able to associate new custom attributes AT2/RT2 to RT1. Can't we associate custom attributes to the invalidated token RT1?
@dino , @anilsagar - please advise.
Also let me know what is the best solution approach here.
Please find sequence diagram below to understand quickly:
Thanks in advance,
Neeraja
whenever we generate new AT2/RT2 by providing valid RT1 in the /refresh call, immediately old RT1(came as part of request) gets invalidated.
This is by design. Maybe you understood this.
I am trying to implement a logic as below:... Whenever we generate new AT2/RT2 pair, before sending the response: AT2/RT2 , I would like to associate this AT2/RT2 pair to RT1.
I understand what you're describing. And I think it is doomed to fail because the RT1 is invalidated at the time AT2/RT2 is created. There is no value in attaching an attribute to it, after the fact.
I think there is a better way. Have you seen ReuseRefreshToken ?
This could be a simple solution to the challenge you're facing.
Hi @dchiesa1, thanks for your swift reply.
I have already analyzed ReuseRefreshToken functionality earlier but not considered for the below reasons:
Note: with /token call AT1/RT1 got generated.
Please find below the /refresh call behavior when reuserefreshtoken is set to true/false:
reuserefreshtoken=false | calling /refresh 1st time by passing RT1 | calling /refresh 2nd time by passing RT2 | calling /refresh 3rd time by passing RT3 |
AT2 | AT3 | AT4 | |
RT2 | RT3 | RT4 | |
RT expiry | 30days | 30days | 30days |
reuserefreshtoken=true | calling /refresh 1st time by passing RT1 | calling /refresh 2nd time by passing RT1 | calling /refresh 3rd time by passing RT1 |
AT2 | AT3 | AT4 | |
RT1 | RT1 | RT1 | |
RT expiry | 30days | 28days(left over expiry) | 15days (left over expiry) |
In the first case when reuserefreshtoken=false, we are able to generate RT2/RT3/RT4 with fresh expiry time as 30days every time & I can keep on generating new pairs(as long as I have valid RT and I refresh before its expiry) with 30days expiry every time and hence partner doesn't need to go for user consent again & again.
But when reuserefreshtoken=true, the existing refresh token is reused(always RT1) until it expires(30days only). As I can't generate RT1 expiry 30 days each time, this will break the existing flow, i.e. Partner has to again and again go for user consent (via 3 legged OAuth flow) after each 30days.
Here I have 3 thoughts, which resolves the given problem statement.
1. If Apigee allows to add custom attributes (AT2/RT2) to the invalidated refresh token(RT1) OR
2. If Apigee waits for an ACK from the partner (ex: whether AT/RT pair received or not etc.) before invalidating the refresh token RT1 (as per the design Apigee invalidates the old RT1 immediately when new AT2/RT2 gets generated) OR
3. If we can create RT1 with fresh expiry of 30days each time (each /refresh call) when reuserefreshtoken=true.
Kindly advice on the feasibility perspective to solve the given problem. Suggest if any other best alternate approach that we have here.
Thanks,
Neeraja