4

As far as I know ASOS supports refresh tokens out of the box. To get refresh token I need to add offline_access scope to my token request. But where are they stored? How can I change expiration date of the token or delete it? How can I determine for which user refresh token is created?

Stalso
  • 1,468
  • 2
  • 12
  • 21

1 Answers1

5

But where are they stored?

By default, they are stored nowhere: they are self-contained. As long as the encryption keys used to protect the refresh tokens are still in the ASP.NET Data Protection key ring, they can be decrypted by ASOS and used to issue new access tokens.

How can I change expiration date of the token?

The default expiration date can be set globally from the options, using the RefreshTokenLifetime property. If you don't provide your own lifetime, they are valid for 14 days.

Note that sliding expiration is also enabled by default, which means you get a new refresh token (valid for 14 days) each time you make a new grant_type=refresh_token request. You can disable sliding expiration by setting UseSlidingExpiration to false.

... or delete it?

Since refresh tokens are self-contained, you can't delete them. You could of course consider using custom tokens (like unique strings corresponding to an entry in a database) by overriding the SerializeRefreshToken and DeserializeRefreshToken events, but the recommended approach is to simply treat them as invalid when receiving a refresh token request.

For that, you can override the HandleTokenRequest event and call context.Reject() if you consider that a refresh_token was revoked and cannot be used to issue new tokens.

How can I determine for which user refresh token is created?

Refresh tokens contain all the claims you add when creating the original authentication ticket, so if you add a sub claim corresponding to the user identifier, you can use it to retrieve the user profile from the database.

Kévin Chalet
  • 39,509
  • 7
  • 121
  • 131
  • Thanks. but we have one missunderstanding about token expiration. How can I chage expiration date of one concrete, already generated token? Or I should invalidate it using `GrantRefreshTokenGrant ` method& I wil be very pleased if you show me the way, how can I ban user. What is `manager.SupportsUserSecurityStamp ` ? How can I use it? In fact I need to give users tokens and immediately invalidate tokens (immediately ban users). – Stalso Mar 02 '16 at 14:21
  • You can't change the expiration date of a refresh token that was already issued (it's hardcoded inside the token), but as you figured it out, you can use `GrantRefreshTokenGrant` to add your own logic to determine whether a refresh token is still valid. You can call `context.Rejected()` to reject a refresh token request if the user is banned. – Kévin Chalet Mar 02 '16 at 14:25
  • As far as I understand, I need to add field `Banned` in my user model and check it in `GrantRefreshTokenGrant ` and then reject token? If I use such approach, I won't be able to ban user immediately or add new claims. Is it any way to check access tokens for every request? Maybe I should do it in `AuthorizationEndpoint `? – Stalso Mar 02 '16 at 14:37
  • Yes, that's the idea (and the recommended approach). If you need to support such a feature with access tokens (and not refresh tokens), you'll need to do that at the JWT bearer middleware level (`app.UseJwtBearerAuthentication()`), since it's the place where access tokens are validated by the stack. – Kévin Chalet Mar 02 '16 at 14:39
  • Sorry, but I cannot figure out, how to do it in `app.UseJwtBearerAuthentication()`. Can you give me advice, where to do it? – Stalso Mar 02 '16 at 14:43
  • Ideally, this should asked in a different question, but here's a hint: you can use the `ValidatedToken` event to add your own validation routine: https://github.com/aspnet/Security/blob/1.0.0-rc1/src/Microsoft.AspNet.Authentication.JwtBearer/Events/IJwtBearerEvents.cs#L34. Alternatively, you could also add your "ban check" directly at the authorization level, in a custom authorization policy. – Kévin Chalet Mar 02 '16 at 15:13
  • Thanks. It was very usefull – Stalso Mar 02 '16 at 15:22
  • You said refresh token is self-contained. I am hosting the project via IIS and using JWT bearer along with ASOS. I wonder why refresh token is not valid after restarting IIS if it is self contained? I need a self-contained at the moment so it should be valid till even after rebooting the server. Should I ask this as a different question? – Mohammad Nikravan Nov 27 '17 at 09:19
  • The reference to OpenIdict doesn't exist (404) now. Could you update the link so we can see this? It's vital that we can revoke refresh tokens for obvious reasons. – James Hancock Jun 25 '18 at 18:03
  • @JamesHancock I removed that part as the corresponding code no longer exists in OpenIddict. Give https://github.com/openiddict/openiddict-samples/blob/d37e3fd1caf7b0ef595658a6b19ae1ab540d6146/samples/RefreshFlow/AuthorizationServer/Controllers/AuthorizationController.cs#L75-L116 a look if you want a concrete example showing how to use Identity's API to validate the security stamp. – Kévin Chalet Jun 25 '18 at 20:13