0

I have an instance of Thinktecture's Identity Server v3 in Azure hosted as WebApp. In general, it works as expected but I have some issues trying to use refresh token through the token identity/connect/token endpoint with the refresh_token grant type. I have a client which uses Authorization Code flow and this is the settings related to the refresh token options regarding this client:

// refresh token options
AccessTokenType = AccessTokenType.Jwt,
AccessTokenLifetime = 3600,
RefreshTokenUsage = TokenUsage.OneTimeOnly, // Every time generates new refresh token. Not only access token.
RefreshTokenExpiration = TokenExpiration.Sliding,
SlidingRefreshTokenLifetime = 1296000

for people who have worked with this it is clear that I use JWT tokens and my access token is valid for 1 hour and after that, without the need to login again on Identity Server I can use the refresh token and obtain new access and refresh tokens. My refresh token must be valid for 15 days(1296000 sec.). What actually happens is that it doesn't work as expected. For some reason, when I decide to make a call to my REST API(relying party of the Identity Server) one hour and a half after the previous one I get invalid_grant response.

I decided to test it a little bit and made my access token to expire in 2 minutes and my refresh token in 10. Well, then I tried to make a call 1, 2, 3.. minutes after the access token was expired and it was working as expected. I don't really want to do this kind of testing with 1 hour access token so that is why I decided to ask here if someone has been trough that before.

user2128702
  • 2,059
  • 2
  • 29
  • 74

1 Answers1

0

Your access token lifetime is 1 hour and the refresh token lifetime is 15 days.

The token you use when you make a call to the API is the access token. It seems normal to me that you get an error if you make the call 90 minutes after the last time you refreshed the access token. In this case, before making a call the API, you should check if the access token is still valid, and if it's not then refresh it.

As for your testing, down the stack the JwtSecurityTokenHandler class is responsible to validate the token. By default the validation parameters allow a mismatch of 5 minutes to cater for variations of time between systems. Modifying TokenValidationParameters.DefaultClockSkew to a smaller value should help in your case.

Mickaël Derriey
  • 12,796
  • 1
  • 53
  • 57
  • I know on the client when my access token is expired. That is why I use my refresh token to receive new access token and use it. I make a call to the refresh token endpoint but for some reason this approach stops working at some time. – user2128702 Dec 15 '16 at 16:59
  • What stops working? Hitting the token endpoint on IdSrv with your current refresh token to get both a new access token and a new refresh token? Or hitting your API with your access token? – Mickaël Derriey Dec 15 '16 at 17:24
  • Yes, the call to the token endpoint returns invalid_grant error. It doesn't recognize my refresh token anymore. – user2128702 Dec 16 '16 at 09:25
  • Do the logs say anything useful? When you git the token endpoint with your refresh token, do you replace it with the new one IdSrv sends with the access token? – Mickaël Derriey Dec 16 '16 at 12:00
  • Yes, I replace both refresh token and access token when making a call to the IdSrv. Regarding the logs, nothing very useful there. – user2128702 Dec 19 '16 at 12:55
  • Having a look [at the code](https://github.com/IdentityServer/IdentityServer3/blob/93bc6bc9b536146b9e3fa0bed21d77283d07f788/source/Core/Services/Default/DefaultRefreshTokenService.cs#L137), it looks like the lifetime of a refresh token will never exceed the Client's `AbsoluteRefreshTokenLifetime`. Could it be that you hit that scenario? – Mickaël Derriey Dec 19 '16 at 21:29
  • But, as you can see in my post, I am not using AbsoluteRefreshTokenLifetime property. – user2128702 Dec 21 '16 at 10:16