fix(generic-oauth): support symmetric ID token verification - #11237
fix(generic-oauth): support symmetric ID token verification#11237jhapriyavart10 wants to merge 3 commits into
Conversation
|
@jhapriyavart10 is attempting to deploy a commit to the better-auth Team on Vercel. A member of the Team first needs to authorize it. |
|
There was a problem hiding this comment.
🟡 Changes recommended
The HS* key resolver currently falls back to remote JWKS when clientSecret is missing/empty, which can violate the “fail closed” expectation and may weaken verification for misconfigured providers.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR updates the generic-oauth plugin’s OIDC discovery-based ID token verification so that symmetric ID tokens (HS256/HS384/HS512) can be verified using the configured clientSecret, while asymmetric algorithms continue to use the remote JWKS from discovery metadata—addressing failures like JWKSNoMatchingKey for providers that correctly omit symmetric keys from public JWKS.
Changes:
- Wraps the discovery JWKS resolver with an
alg-aware key resolver that returnsclientSecretbytes for HS* algorithms. - Adds regression tests covering HS256 verification for both redirect flow (nonce-bound) and direct client
idTokensign-in, plus negative cases. - Adds a changeset documenting the patch behavior change for
better-auth.
File summaries
| File | Description |
|---|---|
| packages/better-auth/src/plugins/generic-oauth/index.ts | Makes ID-token key resolution algorithm-aware, using clientSecret for HS* and remote JWKS for asymmetric algorithms. |
| packages/better-auth/src/plugins/generic-oauth/generic-oauth.test.ts | Adds HS256 discovery verification regression tests (happy path + rejection cases). |
| .changeset/generic-oauth-hs256-id-token.md | Publishes a patch changeset describing the new HS* discovery verification behavior. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| jwks: async (protectedHeader, token) => { | ||
| if ( | ||
| protectedHeader.alg === "HS256" || | ||
| protectedHeader.alg === "HS384" || | ||
| protectedHeader.alg === "HS512" | ||
| ) { | ||
| if (secretBytes) { | ||
| return secretBytes; | ||
| } | ||
| } | ||
| return remoteJWKS(protectedHeader, token); | ||
| }, |
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Summary
When configuring an OIDC provider with
discoveryUrl, genericOAuth currently binds ID-token verification strictly tocreateRemoteJWKSet(jwksUrl). For identity providers that issue symmetrically signed ID tokens (e.g.HS256,HS384,HS512), verification unconditionally fails withJWKSNoMatchingKeybecause OIDC Discovery §3 specifies that symmetric keys must not be published in the public JWKS.Root Cause
genericOAuth's discovery initialization unconditionally assignsidTokenConfig.jwks = createRemoteJWKSet(jwksUrl)wheneverdiscovered.jwks_urianddiscovered.issuerare present, without inspecting the token's algorithm header at verification time.Fix
remoteJWKSin an algorithm-awareJWTVerifyGetKeyresolver.HS256,HS384,HS512), verify using the pre-encoded bytes of the configuredclientSecretper OIDC Core 1.0 §3.1.3.7.remoteJWKS.clientSecretis absent or empty, HMAC verification safely fails closed.Tests
Added regression tests under
describe("HS256 discovery verification")inpackages/better-auth/src/plugins/generic-oauth/generic-oauth.test.ts:RS256).pnpm typecheckpasses with 0 errors.Closes #11121
Summary by cubic
Fixes generic OAuth ID token verification for providers that issue symmetric (HS256/HS384/HS512) tokens. Verification previously always used the remote JWKS, which per OIDC Discovery doesn't include symmetric keys, so these tokens failed with
JWKSNoMatchingKey. Now HMAC tokens are verified against the pre-encodedclientSecret, but only when the token's algorithm is advertised in the discovery metadata; asymmetric tokens keep using the JWKS, and verification fails closed ifclientSecretis missing or the algorithm isn't advertised.Tests
Written for commit be89cec. Summary will update on new commits.