Invalidate access/refresh token after x hours

I would like to invalidate a token using the InvalidateToken OAuthV2 operation after x number of hours. Is this possible and if so how?

1 6 729
6 REPLIES 6

I think maybe I am not completely understanding your question.

Can you elaborate on what you want to do?

InvalidateToken will invalidate a token.

If you want to invoke that policy after X hours, then... insert that policy into an API proxy flow, and invoke that API request, after X hours have elapsed. The policy will run, the token will be invalidated. Done.

But ... surely there is something more to your question.

Maybe what you want to do is generate a token with an automatic expiry after X hours? That is also possible, it is a simple configuration option in the GenerateAccessToken policy. Check the documentation.

<OAuthV2 name="GenerateAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>28800000</ExpiresIn>  <!-- here, 28800000 = 8 hours -->
  <GenerateResponse />
  <SupportedGrantTypes>
   <GrantType>authorization_code</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <Code>request.queryparam.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
</OAuthV2>

if this isn't it, please elaborate on your question.

@Dino regarding "insert that policy into an API proxy flow, and invoke that API request, after X hours have elapsed"... how do you invoke a policy after x hours have elapsed?

> how do you invoke a policy after x hours have elapsed

you don't ever invoke a policy directly. Sorry if I was unclear. Policies run when they are part of a flow that gets invoked. Flows get invoked when you send an inbound API request.

So I think you are asking "how can I invoke an API at some point in the future?"

I think the answer to that is "with cron" or "with schtasks.exe", and is OS dependent.

And That is independent of "how to invalidate a token."

Sorry if I'm being dense here. I think I am still not understanding things clearly.

But I would summarize my advice this way:

  • If you want the token to automatically become invalid, X hours after token creation, then just set the lifetime at the time you create the token. You do this with a configuration option in the GenerateAccessToken policy. See the docs.
  • if you don't know, at the time of token creation, when you will want the token to become invalid, but you know that at some point in the future, you will want to expire the token in X more hours, then you need a task scheduler, like cron or schtasks.exe. And you set the task to run a curl command that tickles an API that includes the appropriate invalidatetoken policy. or the cron job runs a curl command with to an Admin API that does the equivalent.

@Dino The problem is that I want to allow a user to Refresh an AccessToken, but need for the RefreshAccessToken and any subsequent RefreshAccessToken that are generate to expire exactly 24 hours after the AccessToken was first created. With the RefreshAccessToken operation, you can set the <RefreshTokenExpiresIn> param, but rather than setting this to a specific value which essential enables a sliding expiration, I need to calculate this value based on when the original access token was issued at so that I can expire it after exactly 24 hours. One thought is to store an attribute on the accesstoken for when it was originally issued at and then use that attribute to calculate when the refresh token expires. However, trying to see if there is a better way to accomplish this... Thoughts?

Ah, I see! Thanks for the additional information.

I think the way I would do it, is exactly the way you have described doing it.

OR... is it possible to re-use the original refresh_token ?

What I mean is:

Upon generation of the original access_token, set the access_token ExpiresIn to be ... 30 minutes. And set the RefreshTokenExpiresIn to be 24 hrs.

Upon subsequent generation of new access tokens (using the original refresh token), omit the refresh token from the response. The new access token will have a life of ... say, 30 minutes, and the caller does not receive a new refresh token .

The caller can re-use the original refresh token for getting new access tokens. After 24 hrs, the original refresh token expires.

I think this will work. You need only to omit the refresh token from all but the first token response.

Not applicable
@Anthony Coelho

@Dino

What if I try to refresh the token at 23:50 or 23:59 ? there will be a +/- of few minutes unless we do a math on refresh token generated and used using the GetOauthV2 policy and set the expires_in and refresh_expires_in accordingly to get strict 24 hours (Maybe close).