Security: Implement RFC 7519 Compliant JWT Audience Validation #309
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.
Summary
Fixes a critical security vulnerability in JWT token validation that could allow token mix-up attacks (confused deputy vulnerability). Tokens were being issued with
aud(audience) claims but never validated during verification, violating RFC 7519 §4.1.3 requirements.Vulnerability Details
Type: Token mix-up / Confused deputy attack
Severity: Critical
RFC Reference: RFC 7519 §4.1.3 (Audience Claim)
Problem:
aud: clientIDclaim when creatediss) was being validatedAttack Scenario:
An attacker could obtain a valid JWT token for Service B and successfully use it to access Service A, since only the issuer was validated. This violates the principle of least privilege and RFC 7519 requirements that state: "Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the 'aud' claim when this claim is present, then the JWT MUST be rejected."
Changes Made
Security Implementation (commit 4676a2f)
VerifyOptionsinterface with full documentationclient.verify()using jose library's built-in validationBefore:
After:
Test Coverage (commit fc264df)
Added comprehensive test suite with 21 tests (533 lines) covering:
All tests pass with the fix applied and would fail if the vulnerability were reintroduced.
Dependency Updates
Security Benefits
Backward Compatibility
The implementation is fully backward compatible. When no explicit
audienceoption is provided, the validation defaults to the client'sclientID:Existing code without explicit audience specification will continue to work but will now properly validate tokens against the client's own ID.
Testing
Run the test suite to verify the fix:
bun test packages/openauth/test/vuln-jwt-audience-validation.test.tsAll 21 tests should pass, demonstrating:
Files Changed
References
Review Priority: High (Security Fix)
Deployment Risk: Low (Backward Compatible)
Breaking Changes: None