Repository navigation
fix(oidc): accept a token when the allowed algorithms mix key families - #189
Merged
Merged
Conversation
OidcValidator built one jsonwebtoken Validation with every allowed algorithm. jsonwebtoken 9 refuses a key whose family differs from any algorithm in that list, so a config such as [RS256, ES256] rejected every token, RSA and EC alike. A token is now verified with its own header alg only. The allow-list check before key lookup is unchanged, so an alg outside the list is still refused as UnsupportedAlgorithm, and a key is used only for the family the token names. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
OidcValidatorrejected every token whenOidcValidationConfig.algorithmsmixed key families, e.g.[RS256, ES256].try_validate_jwtbuilt a singlejsonwebtoken::Validationthat listed every allowed algorithm. jsonwebtoken 9 refuses a key whose family differs from any algorithm inValidation::algorithms, withInvalidAlgorithm. So with[RS256, ES256], an EC key failed because RS256 was listed, and an RSA key failed because ES256 was listed. Configs with one algorithm, or one family, were not affected.Now the token is verified with its own header
algonly (Validation::new(header.alg)). The allow-list check that runs before the key lookup is unchanged.Found while wiring Pauta's owner sign-in (rudaia-hq/pauta, spec 012). Pauta accepts RS256, Keycloak's default, and ES256, because
TestIssuermints ES256.What could be bypassed, and the test that shows it is not
algorithms_of_different_families_can_be_allowed_togethersends a forgedHS256header and getsUnsupportedAlgorithm, with both orders of the list.Validationnow holds exactly one algorithm, the header's, and jsonwebtoken refuses a key of another family. The same test sends a forgedRS256header under the EC key'skidand getsUnsupportedAlgorithm.[RS256, ES256]and[ES256, RS256]. Without this fix the test fails, so it is a regression test.exp/nbf, leeway and the required claims are still set on the sameValidation. Every other test inmulti_issuer.rsandserver_validation.rspasses without changes.src/browser/) hardcodes[RS256], so it cannot hit this. It still has the same two-line pattern, which can be cleaned up separately.Checks
cargo test -p cli-framework-oidc --all-features: all pass.cargo clippy -p cli-framework-oidc --all-features -- -D warnings: clean.cargo fmt --all -- --check: clean.[Unreleased]→Fixed.🤖 Generated with Claude Code