AbsoluteRefreshTokenLifetime is not always honored causing unexpected behavior

[NiklasArbin]

We had a setup with sliding refresh token expiry such as: ´´´ new Client { ClientName = "The Client", ClientId = "client-api", Enabled = true, AccessTokenType = AccessTokenType.Jwt, AccessTokenLifetime = 3600 * 24, // 24 hours RefreshTokenUsage = TokenUsage.ReUse, RefreshTokenExpiration = TokenExpiration.Sliding, SlidingRefreshTokenLifetime = 3600 * 24 * 365, // About 1 year Flow = Flows.ResourceOwner, ClientSecrets = new List<Secret> { new Secret("secret".Sha256()) }, AllowedScopes = new List { "api", Constants.StandardScopes.OfflineAccess } } ´´´

• When first logging in the refresh token is set to 1 year.
• After 24h when refreshing the access token, the refresh token expiry is set to 30 days (AbsoluteRefreshTokenLifetime we later discovered).
• Refreshing the access token using the refresh token does not increase the lifetime of the refresh token which has caused refresh token expiration for our users.

This is obviously caused by the conflicting values that we setup by not setting the AbsoluteRefreshTokenLifetime, but IdentityServer should handle this more consistent.

Potential fixes: *Throw exception for misconfiguration or at least the sliding expiration should be honored with the default 30 days. *Also that AbsoluteRefreshTokenLifetime is not honored during the first login will cause users to have valid tokens past the AbsoluteRefreshTokenLifetime.

Setting the AbsoluteRefreshTokenLifetime to a value matching the SlidingRefreshTokenLifetime fixed our issues.

Using: IdentityModel version="1.3.1" IdentityServer3 version="2.3.0" IdentityServer3.AspNetIdentity version="2.0.0" IdentityServer3.EntityFramework version="2.3.0"

[leastprivilege]

So you are saying we should do some validation to make sure the settings make sense?

[leastprivilege]

e.g. the could be an extension method for Client like

ConfigureRefreshTokens(....)

That takes all the relevant settings, does validation and sets the properties.

Otherwise we can only throw an exception at runtime since we don't control the sourcing of config settings.

[NiklasArbin]

That would make it easier, but it might be hard since as you say the sourcing for the config is hard to control except in runtime. Maybe making the refreshtoken settings into a class instead of using pure integer properties on the Client would make more sense.

That the sliding expiration stops working all together when the values are misconfigured still seems wierd. If the AbsoluteRefreshTokenLifetime is 30 days and the SlidingRefreshTokenLifetime is 1 year then at least the sliding expiration should slide with 30 days. Currently it does not slide at all.

That the sliding expiration is set to 1 year on first login also seems like a bug since it should be 30 days.This is what threw me off in the beginning causing me to miss setting the AbsoluteRefreshTokenLifetime in the first place.

Otherwise this is an awesome product that works like a charm for us.