Need to break access token rotation after an year

[Aravind]

Hi @Team

I have a requirement as below,

We are using Authorization code grant type for the consent grant and for generating the auth code.

And we a have a token endpoint to generate an access token and refresh token using auth code.

We set 15 minutes as expiry for the access token and 30 days for the refresh token.

Data receipt will rotate the access token using the refresh token till consent was revoked by the user as a never ending rotation.

As per the guidelines we received, we need to rotate this cycle only for 1 year(365 days). Data receipt tries to generate a new access token using refresh token after the 365 days must throw an error.

Please help to achieve this requirement.

[dchiesa1 · Accepted solution]

The basic approach is pretty easy:  Before calling OAuthV2/RefreshAccessToken, check the date of consent.  If it is >365 days, then , revoke the refreshtoken and accesstoken (OauthV2/RevokeOAuthV2), and redirect the user to the login-and-consent experience.  You probably need JavaScript to do the 365 day check. 

Where is the state of consent stored?  You referred to "the consent grant and for generating the auth code." 

I guess there are two possibilities:

1. somewhere external to Apigee, you have explicitly stored the fact of the consent.  You would do this if the consent is granular, has multiple different scopes, has the possibility for revocation, etc.
2. the consent is "stored" only by the fact that the authorization code grant succeeded. In other words, your token dispenser checked the login-and-consent state before issuing the first token.

In the first case, you would need to store the date of consent grant, along with the fact of consent. And then, within your API proxy, before calling OAuthV2/RefreshAccessToken, you would need to call out to that external store (ServiceCallout?) to retrieve the date of the consent. Then do the checks as described above. 

In the second case, you can use a custom attribute on the token to store the consent date. If you store the consent date on the original access token, Apigee will automatically propagate that custom attribute to each new generation of refreshtoken+accesstoken. So there is no need to call "out" to an external store to retrieve the date of consent - just examine the custom attribute. And do the checks with the JS taking care of the arithmetic.

I guess your "date check logic" would need to handle the edge case, that would occur for all existing tokens, for which there is no consent date stored.  In that case you will probably need to require a new consent, at the first refresh.  Depending on how many users and tokens  are affected, you may want to roll this policy change out in phases, to avoid a flood of  new consents, and maybe to mitigate the impact of unforeseen problems with the change.  Maybe 2% of users in the first week, 5% of users in the 2nd week, 12% in the 3rd, etc.  You could use a random selector to determine which users to include in each phase. If you have only a few users (~ 1000 or less?), and you're confident that there will be no unforeseen problems, then you could enforce the new policy on all of them, in the first week.