DEV Community

Cover image for Validating OAuth Metadata and JWTs
Raylabs
Raylabs

Posted on Originally published at raylabs.app

Validating OAuth Metadata and JWTs

#authentication #security #oauth #jwt

Engineers frequently confuse fetching configuration endpoints with verifying cryptographic credentials, assuming that locating a server means its tokens are automatically safe to accept. When an application accepts a digitally signed JSON Web Token without validating its runtime claims against the actual protocol environment, it opens the system up to cross-context impersonation and unauthorized data access.

Quick solution:

Implement strict runtime checks for issuer, audience, and algorithm alongside metadata discovery, as shown in this minimal Node.js verification snippet using explicit claim validation.

const jwt = require('jsonwebtoken');

function verifyToken(token, expectedIssuer, expectedAudience, jwksUri) {
  // Prerequisite: Never rely solely on discovery metadata for trust
  const options = {
    issuer: expectedIssuer,
    audience: expectedAudience,
    algorithms: ['RS256']
  };

  try {
    const decoded = jwt.verify(token, getKey, options);
    return { valid: true, claims: decoded };
  } catch (err) {
    return { valid: false, error: err.message };
  }
}
Enter fullscreen mode Exit fullscreen mode

What do RFC 9728 and RFC 8414 each discover?

Configuration discovery separates client configuration from hardcoded URLs. As outlined in RFC 8414, authorization servers publish metadata documents containing endpoints, supported scopes, and public signing key locations. This allows clients to dynamically locate token endpoints without manual configuration updates when infrastructure shifts.

Complementing authorization server metadata, RFC 9728 defines protected resource metadata. It enables protected resources to advertise their required authorization servers, scopes, and supported bearer token methods. While this mechanism tells a client where to authenticate and which authorization server governs the resource, it does not inspect inbound tokens, evaluate cryptographic signatures, or confirm that a presented token matches the expected operational context.

Why can a valid signature still belong to the wrong audience?

A cryptographic signature proves only that a trusted private key generated the token, not that the token was minted for the service currently inspecting it. If an authorization server issues a valid JWT for Service A, an attacker can capture that token and present it to Service B if both services trust the same issuer.

{
  "iss": "https://auth.example.com",
  "aud": "https://service-a.example.com",
  "sub": "user-123",
  "exp": 1800000000
}
Enter fullscreen mode Exit fullscreen mode

When Service B receives this payload, a naive implementation might inspect only the cryptographic signature, see that it matches the public key from the authorization server, and grant access. Because the audience claim (aud) points to Service A, Service B must reject the token. Enforcing strict audience checks prevents multi-tenant token replay attacks across microservices.

How are issuer mismatch and token-type confusion rejected?

Authentication boundaries require explicit rejection rules to handle malformed claims, unexpected issuers, and mismatched token types. Following RFC 8725 guidance on JSON Web Token best current practices, validators must explicitly enforce expected header parameters and payload constraints. For instance, token-type confusion occurs when an application accepts an ID token or an opaque assertion where an access token is required.

When designing machine commerce protocols or agent architectures, managing trust boundaries requires robust protocol segregation as detailed in discussions on agent authentication and machine commerce protocols, where clear credential validation rules prevent unintended privilege escalation.

Validation Check When to Use It Trade-off or Failure Mode Recommendation
Issuer Check (iss) Every incoming token Rejects tokens from unknown or untrusted auth servers Always match against a strict allowlist of authorized issuers.
Audience Check (aud) Microservice authorization Rejects valid tokens minted for different application tiers Bind every endpoint to its exact expected audience string.
Algorithm Check Signature verification Rejects 'none' or asymmetric-to-symmetric key confusion Hardcode allowed algorithms (e.g., RS256); never trust the alg header blindly.

Execution and Verification Checklist

  • [ ] Verify that a token with a valid signature but an unexpected audience string is rejected with an audience mismatch error.
  • [ ] Confirm that an unexpected issuer string causes immediate rejection even if the signing key is recognized.
  • [ ] Ensure that unapproved algorithms, such as 'none' or HMAC variants where RSA is expected, fail signature validation.
  • [ ] Test that metadata endpoints from RFC 9728 and RFC 8414 are used exclusively for endpoint discovery rather than runtime claim evaluation.

Top comments (0)