Can we associate custom attributes to the expired/invalidated token?

[Neeraja]

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

[dchiesa1]

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.

[Neeraja]

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