0
votes

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.

1

1 Answers

0
votes

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.