josephdecock
commented
1 year ago IdentityServer needs cryptographic keys, called signing keys, to sign tokens such as JWT access tokens and id tokens. These keys are critical secrets for IdentityServer because a valid signature provides integrity and non-repudiation guarantees that allow client applications and APIs to trust those tokens.
The signing keys that IdentityServer generates using automatic key management are protected at rest using ASP.NET's data protection feature. Data protection is a separate cryptographic tool built into ASP.NET that signs and encrypts data. ASP.NET data protection has its own cryptographic keys, called data protection keys, that are managed separately from the signing keys that IdentityServer uses. The data protection keys can cause problems if you have a signing key stored in your signing key store, but try to decrypt it without the data protection key that encrypted it.
There are several ways that this can occur, but given that you started seeing problems when you moved into a load balanced environment, the most likely explanation is that the instances of IdentityServer are not configured to share data protection keys. The way that you should store and protect your data protection keys will vary depending on your environment and requirements, so take a look at Microsoft's extensive docs here describing how to configure storage and protection of data protection keys.
Duende IdentityServer 6.2.1 .NET 6
We currently have IdentityServer distributed in a LoadBalanced server environment. During initial testing we didn't encounter this, but now we are (because our initial test environments aren't load balanced). We are utilizing Automated Key Management in the Operational Store (Entity Framework).
When each server spins up it gets it's own Key (Key Id, etc.). This presents issues with the OWIN middleware that connects our API to our Sites.
Is there a way by configuration to configure each server so that it utilizes the same key across server environments?
Thanks in advance