Skip to content

Conversation

@execute008
Copy link

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:

  • JWT tokens include aud: clientID claim when created
  • No validation of the audience claim during token verification
  • Only issuer (iss) was being validated

Attack 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)

  • Added audience parameter to VerifyOptions interface with full documentation
  • Implemented audience validation in client.verify() using jose library's built-in validation
  • Enhanced /userinfo endpoint with explicit audience claim validation and proper error handling
  • Defaults to clientID when no explicit audience provided (backward compatible)

Before:

const result = await jwtVerify(token, jwks, {
  issuer, // Only validates issuer
})

After:

const expectedAudience = options?.audience || input.clientID
const result = await jwtVerify(token, jwks, {
  issuer,
  audience: expectedAudience, // Now validates audience
})

Test Coverage (commit fc264df)

Added comprehensive test suite with 21 tests (533 lines) covering:

  • Token mix-up attack prevention
  • Audience claim validation (correct/incorrect/missing)
  • RFC 7519 §4.1.3 compliance verification
  • Attack scenario demonstrations
  • Edge cases and backward compatibility
  • Regression protection

All tests pass with the fix applied and would fail if the vulnerability were reintroduced.

Dependency Updates

  • Hono 4.6.9 → 4.10.5 : Latest security patches

Security Benefits

  • Prevents token mix-up attacks where tokens for one service can be used on another
  • RFC 7519 compliant audience validation
  • Defense in depth - adds validation layer beyond issuer checking
  • No performance impact - validation integrated into existing JWT verification
  • Fully backward compatible - defaults to client's configured clientID

Backward Compatibility

The implementation is fully backward compatible. When no explicit audience option is provided, the validation defaults to the client's clientID:

const expectedAudience = options?.audience || input.clientID

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.ts

All 21 tests should pass, demonstrating:

  • Tokens with matching audience are accepted
  • Tokens with mismatched audience are rejected
  • Tokens without audience claims are handled correctly
  • Attack scenarios are prevented

Files Changed

packages/openauth/package.json                          |   2 +-
packages/openauth/src/client.ts                         |  14 +-
packages/openauth/src/issuer.ts                         |  56 +++--
packages/openauth/test/vuln-jwt-audience-validation.test.ts | 533 +++++++
4 files changed, 586 insertions(+), 19 deletions(-)

References


Review Priority: High (Security Fix)
Deployment Risk: Low (Backward Compatible)
Breaking Changes: None

Update hono to address JWT audience validation security advisory.
While we don't currently use Hono's JWT middleware, this ensures
we stay current with security patches.
Implement proper audience (aud) claim validation to prevent token
mix-up attacks where tokens issued for one service could be used
to authenticate with another service.

Changes:
- Add audience parameter to VerifyOptions interface
- Validate audience in client.verify() using jose library
- Default to clientID if audience not explicitly provided
- Enhance /userinfo endpoint with audience claim validation
- Add proper error handling for invalid tokens

This fixes a critical security vulnerability where JWT tokens
were created with audience claims but never validated during
verification, violating RFC 7519 §4.1.3 requirements.

The implementation is fully backward compatible, defaulting to
the client's configured clientID when no explicit audience is
provided.
Add comprehensive test suite for JWT audience (aud) claim validation
vulnerability that was fixed in commit 4676a2f. Tests verify that tokens
are properly restricted to their intended service/client and cannot be
used across different services (token mix-up attacks).

Test Coverage (21 tests):
- Token mix-up attack prevention (3 tests)
- Audience claim validation (3 tests)
- Correct audience validation (3 tests)
- Backward compatibility (2 tests)
- RFC 7519 §4.1.3 compliance (3 tests)
- Attack scenarios (3 tests)
- Edge cases (3 tests)
- Informational (1 test)

The tests currently PASS because commit 4676a2f is already applied in
this codebase. They serve as regression protection and demonstrate:
- What the vulnerability looked like (would fail if fix reverted)
- How the fix prevents token theft and privilege escalation
- Proper audience validation per RFC 7519 requirements

Vulnerability Details:
- Type: Token mix-up attacks
- Severity: Critical
- RFC: RFC 7519 §4.1.3 (Audience Claim)
- Fix: Commit 4676a2f

All tests use real assertions that fail when vulnerable and pass when
secure, suitable for CI/CD integration.

Reference: https://tools.ietf.org/html/rfc7519#section-4.1.3
@troyvaca999
Copy link

It's because somebody's using my account and writing code on my phone and parental controls and block list or blacklist without my permission and I'm 33 years old. I don't know how to take it off and I don't know how to run the code completely. Please help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants