You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow custom JWS algorithms and custom cnf members to be handled entirely through SPIs
#53407
Keycloak's signature / keys / client-signature SPIs let a provider add a new JWS algorithm, and the token-post-processor SPI lets a provider add claims. In practice two closed types in keycloak-core still block this, so a fully provider-based implementation is impossible without patching core:
JWSHeader.alg is deserialized into the closed org.keycloak.jose.jws.Algorithm enum (already @Deprecated). A token signed by a custom SignatureProvider (e.g. GOST R 34.10-2012 per RFC 7091, SM2, or any algorithm not yet in the enum) is issued correctly, but Keycloak cannot parse its own token afterwards: introspection returns active=false, userinfo 401, logout 400, and incoming request objects / private_key_jwt with that alg are rejected — even though everything downstream already looks providers up by the string getRawAlgorithm().
AccessToken.Confirmation only knows x5t#S256, jkt, kc-jkt-type. RFC 7800 §3.1 defines cnf as extensible (IANA "JWT Confirmation Methods" registry). If a TokenPostProcessor adds another confirmation member (e.g. a certificate thumbprint with a different hash), Keycloak fails to parse its own token with UnrecognizedPropertyException.
Proposed changes (small, backwards compatible, no new public API besides getters):
JWSHeader keeps alg as a string. getAlgorithm() returns the enum value or null for unknown algorithms; getRawAlgorithm() returns the original string. TokenVerifier.verifySignature() (the legacy no-verifier path) reports "Unknown or unsupported token algorithm" instead of an NPE.
AccessToken.Confirmation gets Map<String, Object> otherClaims with @JsonAnySetter / @JsonAnyGetter, the same pattern as JsonWebToken.
Change 1 touches the same area as #50358 (ML-DSA), which also moves from getAlgorithm().name() to a string-based name — happy to align with or rebase on it.
We run this as a patch on 26.6–26.8 together with a provider that implements the algorithm via existing SPIs; with these two changes the patch becomes unnecessary. Would maintainers accept PRs for these?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Keycloak's
signature/keys/client-signatureSPIs let a provider add a new JWS algorithm, and thetoken-post-processorSPI lets a provider add claims. In practice two closed types inkeycloak-corestill block this, so a fully provider-based implementation is impossible without patching core:JWSHeader.algis deserialized into the closedorg.keycloak.jose.jws.Algorithmenum (already@Deprecated). A token signed by a customSignatureProvider(e.g. GOST R 34.10-2012 per RFC 7091, SM2, or any algorithm not yet in the enum) is issued correctly, but Keycloak cannot parse its own token afterwards: introspection returnsactive=false, userinfo 401, logout 400, and incoming request objects /private_key_jwtwith thatalgare rejected — even though everything downstream already looks providers up by the stringgetRawAlgorithm().AccessToken.Confirmationonly knowsx5t#S256,jkt,kc-jkt-type. RFC 7800 §3.1 definescnfas extensible (IANA "JWT Confirmation Methods" registry). If aTokenPostProcessoradds another confirmation member (e.g. a certificate thumbprint with a different hash), Keycloak fails to parse its own token withUnrecognizedPropertyException.Proposed changes (small, backwards compatible, no new public API besides getters):
JWSHeaderkeepsalgas a string.getAlgorithm()returns the enum value ornullfor unknown algorithms;getRawAlgorithm()returns the original string.TokenVerifier.verifySignature()(the legacy no-verifier path) reports "Unknown or unsupported token algorithm" instead of an NPE.AccessToken.ConfirmationgetsMap<String, Object> otherClaimswith@JsonAnySetter/@JsonAnyGetter, the same pattern asJsonWebToken.Change 1 touches the same area as #50358 (ML-DSA), which also moves from
getAlgorithm().name()to a string-based name — happy to align with or rebase on it.We run this as a patch on 26.6–26.8 together with a provider that implements the algorithm via existing SPIs; with these two changes the patch becomes unnecessary. Would maintainers accept PRs for these?
All reactions