Access token migration from IdentityServer4 to Duende v7

[norr-carr]

Which version of Duende IdentityServer are you using? 7.0.4

Which version of .NET are you using? .NET 8

Describe the bug We are migrating from IdentityServer4 (3.1) straight to Duende Identity Server v7. I'm hoping that we can preserve the existing access tokens. We are the only consumer of our own Identity Server, using OpenIDC to authenticate to our Identity Server. Our consumer saves the access tokens and we use an intermediate cookie scheme for staying logged in to the consumer.

Previously, we had IdentityServer4 (IS4). We were using the "AddDeveloperSigningCredential" method in IS4 which creates a JSON file called tempkey.rsa in the root directory of the server. It contains a Rsa256 key which I assume is used to sign the access tokens.

Currently we are setting up Identity Server v7 (IS7). It's default behavior is to use automatic key management. I am testing the migration scenario locally. The problem is that if a user is logged in to the old IS4 server, then I switch our provider to the new IS7 server, when that user logs out I get an exception when going to /connect/endsession:

IDX10503: Signature validation failed. Token does not have a kid. Keys tried: '[PII of type 'System.Text.StringBuilder' is hidden. ... Number of keys in TokenValidationParameters: '1'. Number of keys in Configuration: '0'.

I assume this is because the logged in user has access tokens generated by the tempkey.rsa file, and the new IS7 is trying to validate those access tokens with a new auto-generated key.

I'd really like to be able to successfully log out those users who have an old access token. I looked at https://docs.duendesoftware.com/identityserver/v7/fundamentals/keys/static_key_management/#adding-keys and I see that it's possible to add our old key manually, but there's no information there about how to load the key from that old file. I also tried using the IS7 "AddDeveloperSigningCredential" but unfortunately it creates and looks for a file with a different name: "tempkey.jwk". I'd really like to be using automatic key management in the future and I've read https://docs.duendesoftware.com/identityserver/v7/fundamentals/keys/migration/ but the part I'm missing is how to read in the old tempkey.rsa. Could you help me understand how to do that in IS7?

[norr-carr]

We were able to partially solve this by converting the tempkey.rsa file to a tempkey.jwk file. We wrote a script that first deserialized the RSA file and constructed a Microsoft.IdentityModel.Tokens.RsaSecurityKey. Then we used the JsonWebKeyConverter.ConvertFromRSASecurityKey() method (same namespace) to convert it to a JsonWebKey. Then we serialized it back into the tempkey.jwk file. I'd still be interested in hearing if there's a better way for us to store our keys in a Starter Edition environment.

[RolandGuijt]

While the solution you created solves the problem, I have an heads-up: How long is the lifetime of your access tokens? From your story I get the feeling they might live for a long time which might be the problem to begin with. We don't recommend long lifetimes for access tokens but instead use a limited lifetime of e.g. 1-2 hours and use the refresh token mechanism to refresh it. In that way the access token will always be constructed using the current key material.

[RolandGuijt]

Also please be aware that:

• "AddDeveloperSigningCredential" is intended to be used at development time only, it is not for production use.
• There is no good way to rotate and it's hard to migrate the key material used by it, but please see the comment below.
• It stores the keys in plain text on the file system by default which makes it very susceptible to attacks. As opposed to automatic key management where the keys are encrypted at REST.
• The endsession endpoint uses the identity token, not the access token to sign out. The OpenID Connect spec for that is [here].(https://openid.net/specs/openid-connect-session-1_0-17.html#RPLogout)

Having said all that: if you absolutely must migrate the keys that were generated by AddDeveloperSigningCredential you could try extracting the key material from the file and wrap it into a certificate. That certificate should then be stored safely. E.g. in the Windows certificate store. But be aware that if that key material was used in production it could already be compromised.

[norr-carr]

Thanks Roland. It sounds like I need to do more research on the OpenIDC spec, I really appreciate you taking the time to point me in the right direction.