Summary

  • On 24 August 2026, the IESG approved revision 10 of draft-ietf-oauth-rfc8725bis as a Best Current Practice. At the evidence freeze it was still an Internet-Draft in the RFC Editor queue; publication would obsolete RFC 8725 and update RFC 7519.
  • Its decisive operating rule is mutual exclusivity between JWT validation profiles. A good signature proves that a key accepted some bytes. Authorization also requires the expected token type, issuer, audience, claims, headers, algorithm, key and application context.

The green check that should have been red

Imagine an API gateway that accepts access tokens from one issuer. A security-event receiver in the same estate trusts the same issuer and key. Both token families contain an issuer, an audience and a subject. A Security Event Token arrives at the API endpoint, its signature verifies, and a generic JWT library returns success.

The cryptography is green. The authorization decision is wrong.

This is an illustrative gateway test, not a reported breach. It isolates the failure that the revised guidance calls cross-JWT confusion: a token issued for one purpose is substituted into a context that expects another. The attacker does not forge a signature. The receiver forgets to prove what the signed object is allowed to mean.

The correction is not “use stronger crypto.” It is to make each token kind a closed validation profile. The access-token endpoint and the event receiver must not accept the same set of objects merely because their objects use the same serialization and trust anchor.

What was approved—and what was not

The IESG announcement records approval on 24 August at 18:02 UTC of “JSON Web Token Best Current Practices,” revision 10, for publication as a Best Current Practice. The OAuth Working Group produced the document.

At the 28 August evidence freeze, the Datatracker showed the draft as active, dated 21 August and last updated on 25 August, with expiry on 22 February 2027. Its IESG state was RFC Ed Queue. The RFC Editor entry was blocked on a reference not yet received. IANA reported no new registry actions required, although its process status remained in progress.

Those distinctions prevent premature claims. IESG approval is real standards news. It is not yet an RFC number, completed editorial publication or proof that deployed validators follow the new profile. If published as stated, the document will obsolete RFC 8725 and update the base JWT specification, RFC 7519.

Four different questions hide behind “valid JWT”

JWT is a claims format. It can be represented as a signed JWS, an encrypted JWE, a nested object, or an unsecured JWT when an application explicitly permits that form. The compact serialization is a particular base64url-and-dot representation; JOSE also defines JSON serializations. A parser that silently treats every dot-separated object, decrypted payload or generic claims map as equivalent erases security boundaries before policy begins.

A receiver should separate four questions:

  1. Is the object legally encoded in the serialization this endpoint accepts?
  2. Does its signature or authenticated encryption verify under an explicitly allowed algorithm and the correct key?
  3. Does it belong to the token kind this endpoint is designed to consume?
  4. Do its claims authorize this operation now, for this issuer, audience, subject and application?

Success at one stage does not authorize the next. Decrypting a JWE does not prove that an inner JWT was signed. Parsing a legal compact object does not establish trust. Verifying a JWS does not make its claims suitable for every consumer that shares the key.

Type is a profile, not a decorative header

The revised guidance recommends explicit typing with the typ header when a token could be confused with another kind. A media type such as the Security Event Token value defined by RFC 8417 gives the receiver a discriminator. The generic value JWT does not: it says only that the object is a JWT, not which application contract governs it.

Type checking is only one wall. Different validators must be mutually exclusive. The draft says that each token kind should be distinguishable by one or more characteristics that the validator enforces: different explicit types, different required claims or values, different protected headers, different keys, different audiences or different issuers.

That list describes an authority boundary. A Security Event Token and an OAuth access token can both be correctly signed and still be legally non-substitutable. RFC 9068 gives access tokens their own JWT profile. RFC 8417 does the same for security events. The receiver is responsible for selecting one profile before treating claims as authority.

Retrofitting deserves care. Older tokens may omit typ; immediately requiring it can break a deployed population. A non-breaking first step is to reject any present type that is not the expected value, measure omissions, then migrate issuers and consumers toward a mandatory explicit type. Compatibility is a deployment fact, not a reason to accept contradictory types.

Issuer and audience are not optional context

The issuer identifies the authority that made the claims. The audience limits the consumers for which they were made. A receiver must validate both according to its application profile. Merely checking that the fields exist, or comparing them after claims have already influenced routing, is too late.

Audience deserves exactness. A token meant for an event receiver is not an API access token because both endpoints belong to the same company. A token meant for service A is not automatically valid at service B because they use the same identity provider. Shared administration does not collapse distinct relying parties.

Subject semantics also vary. In one token family, sub may identify a person; in another it may identify the subject of a security event or a client application. A field name is not a universal meaning. The token-kind profile supplies the interpretation.

The key must not choose the policy

Algorithm verification has to start from a receiver-controlled allowlist. The token's alg header is input to verify, not permission to decide which verification rule applies. The guidance also binds a key to exactly one algorithm, preventing a key intended for one cryptographic operation from being reinterpreted under another.

Key-selection headers add an input boundary of their own. Values such as kid, jku and x5u can influence database lookups or remote retrieval. If concatenated into queries or dereferenced without strict policy, they can become injection or server-side request-forgery paths. A signed header is still attacker-supplied until the object has been verified, and even a verified issuer should not receive arbitrary network access through a resolver.

The revision also consolidates less visible controls: minimum work factors for password-based encryption, decompression limits for encrypted content, and preference for fully specified algorithm identifiers such as those standardized in RFC 9864. These controls close resource-exhaustion and algorithm-ambiguity gaps that signature-only dashboards tend to miss.

The evidence chain for one authorization

A trustworthy record of acceptance should preserve:

  1. the received bytes and serialization form;
  2. the endpoint and expected token-kind profile;
  3. parser outcome and protected headers;
  4. the configured algorithm allowlist;
  5. the resolved key and its single allowed algorithm;
  6. signature or authenticated-decryption result;
  7. explicit type result;
  8. issuer and audience result;
  9. required-claim and time-window result;
  10. replay and revocation state where the profile requires them;
  11. the policy decision and requested action;
  12. the downstream effect.

A log line that says JWT valid compresses twelve distinct transitions into one ambiguous claim. It cannot show whether the wrong token kind reached the right verifier, whether a valid token crossed audiences, or whether a successful validation actually produced an authorized effect.

That is where the running-code discipline matters. Specifications define the minimum invariant; local systems must demonstrate it at the point where software turns signed claims into action. A standards label cannot substitute for observed validator behavior.

Sources