IdentityServer4 Access Token Lifetime
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
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.