Repository navigation
Compatability key store should respect configured algorithms #132
Description
Compatability key store returns the newest key of any algorithm, rather than selecting an available key based the configured algorithms for the server and/or clients.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Medium
Effort
None yet
Activity
oleks9o6 commentedon Oct 27, 2026
Some notes from our side in case they help - we replaced the compatibility store with our own key handling during our Duende migration, so we went through the same questions.
It's not only the default algorithm. A client restricted to RS256 (
AllowedIdentityTokenSigningAlgorithms = ["RS256"]) can't sign in at all once the newest key in the table is ES256:/connect/authorizethrowsNo signing credential for algorithms (RS256) registered(fromAuthorizeResponseGenerator.CreateCodeAsync), although the table holds a valid RS256 key.DefaultKeyMaterialServiceasks eachISigningCredentialStorefor one credential, and the compatibility store only ever offers the newest key. Checked on 3.1.2.One way that fits the current design: an ordered list of signing algorithms on
CompatibilityKeyStoreOptions(default RS256, like Duende'sKeyManagement.SigningAlgorithms), with one signing credential store registered per algorithm in that order, each returning the newest valid key of its algorithm.DefaultKeyMaterialServicethen uses the first one by default and finds the right one for a client that restricts algorithms, and the only API change is the added option.Which key of an algorithm to sign with: Duende doesn't sign with a new key until it has been published for
PropagationTime(14 days by default), so relying parties already have it in their cached JWKS. What worked for us: sign with the newest key published at least that long; if none qualifies, fall back to the oldest valid key rather than the newest, since relying parties have had it longest.Happy to help with tests or a review.