IdentityServer4 Access Token Lifetime

Question

I am using IdentityServer4, and its configuration is in the database. There is a silent renewal on the client (oidc). I have set the following lifetime settings for the client:

AbsoluteRefreshTokenLifetime =  60 * 30,//30 mins
AccessTokenLifetime = 60 * 5,//5 mins
SlidingRefreshTokenLifetime = 60 * 15 // 15 mins

What should happen? How long should be the lifetime of the token? When should the user be asked to login again? There is no clear documentation about the token lifetime when its refreshed, and when it is expired.

Answer 1

Per my understanding the AbsoluteRefreshTokenLifetime and SlidingRefreshTokenLifetime do not apply to Implicit flow which is what oidc clients should be set to:

http://docs.identityserver.io/en/release/topics/refresh_tokens.html

Since access tokens have finite lifetimes, refresh tokens allow requesting new access tokens without user interaction.

Refresh tokens are supported for the following flows: authorization code, hybrid and resource owner password credential flow. The clients needs to be explicitly authorized to request refresh tokens by setting AllowOfflineAccess to true

I've got a similar situation occurring where for testing I have cookie set to 15 min expiration with sliding expiration and per the issue thread below sounds like this has to be handled manually if using silent renew:

https://github.com/IdentityModel/oidc-client-js/issues/402

I'm new to javascript clients so I'm still trying to figure out how you determine if a user is present or not. I was hoping the cookie would take care of this for me but looks like it keeps getting extended per that thread I sent.

Update

After testing and a ton of googling here is what I was able to get to work/understand with regards to Access Token lifetime and silent renew.

First I'm assuming you are using oidc-client or redux-oidc. I'm using redux-oidc which is just a wrapper for oidc-client.

Since you have the access token lifetime (AccessTokenLifetime) set to 5 mins and have silent renew = true. This will get renewed every 2.5 mins or depending on what you have the userManager.accessTokenExpiringNotificationTime set to. At that time it will renew the access token depending on what you have your cookie expiration timeout set to. The cookie is where the magic happens. If the cookie expires you will no longer be able to renew the access token. the cookie is setup as follows:

• Identity Server start.cs (this will set the sliding expiration of the cookie):

  var builder = services.AddIdentityServer(options =>
  {
     options.Authentication.CookieSlidingExpiration = true;
  })
  

• Identity Server AccountController.cs, login method (If you have remember me functionality you can change the IsPersistent value, tsConfigValue = 15):

  var props = new AuthenticationProperties
  {
     IsPersistent = false,
     ExpiresUtc = DateTimeOffset.UtcNow.Add(TimeSpan.FromMinutes(tsConfigValue))
  };
  

This ended up solving my issue with access token lifetime and silent renew. Hope it helps.

Answer 2

Access tokens can come in two flavours - self-contained or reference.

A JWT token would be a self-contained access token - it’s a protected data structure with claims and an expiration. Once an API has learned about the key material, it can validate self-contained tokens without needing to communicate with the issuer. This makes JWTs hard to revoke. They will stay valid until they expire.

From http://docs.identityserver.io/en/latest/topics/reference_tokens.html#reference-tokens

Refresh tokens allow gaining long lived access to APIs.

You typically want to keep the lifetime of access tokens as short as possible, but at the same time don’t want to bother the user over and over again with doing a front-channel roundtrips to IdentityServer for requesting new ones.

Refresh tokens allow requesting new access tokens without user interaction. Every time the client refreshes a token it needs to make an (authenticated) back-channel call to IdentityServer. This allows checking if the refresh token is still valid, or has been revoked in the meantime.

From http://docs.identityserver.io/en/latest/topics/grant_types.html#refresh-tokens

So the Access Token is self-contained, meaning that it can't be modified. Once issued, the token remains valid until it expires. That is why you would want to use short-lived tokens.

In order to automate the process of access token renewal you can use the refresh token. This is a powerful token, since it can be used to request an access token without user interaction. The refresh token should be long lived (at least longer than the access token).

Once the refresh token expires, the user has to login again. Without sliding expiration the refresh token will expire in an absolute time, having the user to login again.

With sliding expiration you can set a shorter refresh token lifetime. Because each time an access token is requested, a new refresh token is issued. Extending the lifetime and invalidating the used refresh token.

The user can access the resource without having to login again as long as the refresh token is valid. In your case it expires if the user is inactive for more than 30 minutes.

The access token isn't refreshed automatically. You'll need to add code in the client to request a new access token. If the refresh token is not available or expired, you can send the user to the login page.