Automatic key management and sliding tokens conflict?

[ADringer]

Hi all,

I'm investigating and issue where users are failing to reauthenticate, and I believe the related error is:

JWT token validation error: IDX10503: Signature validation failed. Token does not have a kid. Keys tried: '[PII of type 'System.Text.StringBuilder' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'. Number of keys in TokenValidationParameters: '2'.

I'm wondering if there is a conflict between sliding refresh token and the keys that are stored to decrypt. The reason I'm thinking this is that the keys table only shows the latest 2:

Key management is all set to the default values (nothing overridden).

Token settings are the following:

AccessTokenLifetime: 3600
AbsoluteRefreshTokenLifetime: 0
SlidingRefreshTokenLifetime: 1296000
RefreshTokenUsage: 1
RefreshTokenExpiration: 0
AccessTokenType: 0

Could the refresh token last longer than the trigger to delete retired keys and so next time it's refresh the key doesn't exist?

Thanks

Alex

[wcabus]

Hi @ADringer, there may be multiple issues hiding here.

First and foremost, data stored in the persisted grant table, like refresh tokens, are protected using ASP.NET Core's Data Protection functionality. The keys used for Data Protection are not the same as the signing keys table you're showing: these signing keys are only used to issue signed tokens and to validate incoming tokens.

The sliding refresh token lifetime and signing key retention are not in conflict. When a refresh token is used, IdentityServer issues a new access token signed with the current signing key: it doesn't matter if the key that signed the previous access token was retired.

However, issues at the Data Protection layer (e.g. old keys no longer being readable, changed or different application discriminator values) will cause existing persisted grant data like the refresh token to no longer be valid. Expired Data Protection keys are usually also kept around to unprotect old data, to prevent issues like this (no longer being able to unprotect old refresh tokens that were protected with the expired data protection key). Check whether you implemented a mechanism to delete retired Data Protection keys, this may cause issues with old persisted grant data, among other things. Microsoft also recommends to not delete Data Protection keys.

---

The second issue you're highlighting, is the one with the logged message IDX10503: Signature validation failed. Token does not have a kid. Keys tried: '[PII of type 'System.Text.StringBuilder' is hidden...]'. This error comes from the Microsoft.IdentityModel.Tokens.Jwt library.

This error message may be a red herring, but can indicate additional issues:

• Either an incoming token was validated which had no kid set: this token may have been issued by another service, self-issued by an application or perhaps your IdentityServer has overridden the token creation service. Either way: the default IdentityServer behaviour always issues signed tokens including a kid value.
• The logged message was wrong because different versions of the various IdentityModel NuGet packages/libraries may be in use. In the project that logged this message, check the versions using dotnet list package --include-transitive | sls "Microsoft.IdentityModel|System.IdentityModel" in a PowerShell terminal.