-
Notifications
You must be signed in to change notification settings - Fork 363
Fix EC JWKS authentication support #6106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -25,8 +25,10 @@ | |
| import com.nimbusds.jose.JOSEException; | ||
| import com.nimbusds.jose.JWSVerifier; | ||
| import com.nimbusds.jose.crypto.factories.DefaultJWSVerifierFactory; | ||
| import com.nimbusds.jose.jwk.ECKey; | ||
| import com.nimbusds.jose.jwk.JWK; | ||
| import com.nimbusds.jose.jwk.OctetSequenceKey; | ||
| import com.nimbusds.jose.jwk.RSAKey; | ||
| import com.nimbusds.jose.proc.SimpleSecurityContext; | ||
| import com.nimbusds.jwt.JWTClaimsSet; | ||
| import com.nimbusds.jwt.SignedJWT; | ||
|
|
@@ -52,7 +54,6 @@ public JwtVerifier(KeyProvider keyProvider, int clockSkewToleranceSeconds, Strin | |
| public SignedJWT getVerifiedJwtToken(String encodedJwt) throws BadCredentialsException { | ||
| try { | ||
| SignedJWT jwt = SignedJWT.parse(encodedJwt); | ||
|
|
||
| String escapedKid = jwt.getHeader().getKeyID(); | ||
| String kid = escapedKid; | ||
| if (!Strings.isNullOrEmpty(kid)) { | ||
|
|
@@ -61,7 +62,6 @@ public SignedJWT getVerifiedJwtToken(String encodedJwt) throws BadCredentialsExc | |
| log.debug("JWT token is missing 'kid' (Key ID) claim in header. This may cause key selection issues."); | ||
| } | ||
| JWK key = keyProvider.getKey(kid); | ||
|
|
||
| JWSVerifier signatureVerifier = getInitializedSignatureVerifier(key, jwt); | ||
| boolean signatureValid = jwt.verify(signatureVerifier); | ||
|
|
||
|
|
@@ -104,10 +104,14 @@ private JWSVerifier getInitializedSignatureVerifier(JWK key, SignedJWT jwt) thro | |
|
|
||
| validateSignatureAlgorithm(key, jwt); | ||
| final JWSVerifier result; | ||
| if (key.getClass() == OctetSequenceKey.class) { | ||
| if (key instanceof OctetSequenceKey) { | ||
| result = new DefaultJWSVerifierFactory().createJWSVerifier(jwt.getHeader(), key.toOctetSequenceKey().toSecretKey()); | ||
| } else { | ||
| } else if (key instanceof RSAKey) { | ||
| result = new DefaultJWSVerifierFactory().createJWSVerifier(jwt.getHeader(), key.toRSAKey().toRSAPublicKey()); | ||
| } else if (key instanceof ECKey) { | ||
| result = new DefaultJWSVerifierFactory().createJWSVerifier(jwt.getHeader(), key.toECKey().toECPublicKey()); | ||
| } else { | ||
| throw new IllegalArgumentException("Unsupported JWK key type: " + key.getClass()); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure if it makes sense but should we keep the fallback logic in place? Any idea what the entire universe of key types can be?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I leaned toward explicit key type handling here since failing closed felt safer than broadly falling back and potentially masking unsupported JWK types. If preserving backward compatibility with prior RSA fallback makes more sense here, I’m happy to adjust it. |
||
| } | ||
|
|
||
| if (result == null) { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we write tests to hit all of these branches?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have already addded test coverage for the missing EC (ECKey) branch here.
I also looked into adding OCT (OctetSequenceKey) coverage, but the current JWKS authentication flow does not appear to successfully authenticate symmetric OCT keys in the existing test infrastructure (extractCredentials() returns null), so that test is currently failing.
RSA coverage is already present, so this PR focuses on covering the missing EC path.