OAuth access tokens: use RFC 9068 `at+jwt` typ header (config-overridable)

[rsharath]

Summary

Access-token credentials are currently signed with a JOSE header of typ: JWT. Per RFC 9068 — JWT Profile for OAuth 2.0 Access Tokens §2.1, an OAuth 2.0 access token in JWT form SHOULD carry the explicit media type at+jwt in its typ header. These are OAuth 2.0 access tokens, not JWT-SVIDs, so at+jwt is the more correct value and lets resource servers distinguish ATs from other JWTs (e.g. ID tokens) by type.

This is a security measure, not only a correctness one. Per the JWT BCP (RFC 8725 §3.11, reaffirmed in draft-ietf-oauth-rfc8725bis), explicit typing defends against cross-JWT confusion — a JWT minted for one purpose presented where another type is expected. The BCP is explicit that a generic typ: JWT value "does not constitute effective explicit typing." (Raised by @adeinega.)

Current behavior

Both signing paths set typ: JWT:

• internal/service/credential.go:423–426 (RS256 path)
• internal/service/credential.go:428–431 (ES256 path)

hdrs := jws.NewHeaders()
_ = hdrs.Set(jws.TypeKey, "JWT")

And nothing on the verify side enforces typ: pkg/authjwt performs no typ check on access tokens, so even the generic value isn't validated. For contrast, DPoP proofs already do effective explicit typing — pkg/dpop/proof.go:122-128 requires typ == "dpop+jwt" exactly and rejects anything else.

Proposed change

Effective explicit typing needs both halves — emit the specific type and require it:

1. Issue side — default the access-token typ to at+jwt.
   • Add a config option (e.g. access_token_typ, default at+jwt).
   • Update both signing sites in internal/service/credential.go.
   • Update any test that asserts typ: JWT on issued access tokens.
2. Verify side — pkg/authjwt must require typ == at+jwt on access tokens and reject other values, mirroring the DPoP dpop+jwt check. Without this, emitting at+jwt yields the correct header but none of the anti-confusion protection — the "not effective" state the BCP warns about.

The JWT override is a temporary migration affordance only — for a rolling upgrade where some verifiers don't yet accept at+jwt. During migration the verifier MAY also accept JWT; the end state is at+jwt emitted and enforced on both sides, with the override deprecated and removed. It should not be a permanent supported mode, since a generic typ re-introduces exactly the gap this issue closes.

Profile split — JWT-SVID vs at+jwt

A token has a single typ header, so it cannot be simultaneously a spec-compliant JWT-SVID (typ = JWT/JOSE) and a spec-compliant RFC 9068 access token (typ = at+jwt). ZeroID tokens currently serve both roles. Getting this right means choosing the profile per token — OAuth AT for OAuth resource servers (at+jwt), JWT-SVID for SPIFFE consumers (JWT/JOSE) — which requires the issuance path to know the intended consumer. That is the same missing input as #199 (resource indicators): once a caller names the target, the AS can set both typ and aud correctly. #189 and #199 are coupled.

References

• RFC 9068 §2.1 — typ header value at+jwt
• RFC 8725 §3.11 / draft-ietf-oauth-rfc8725bis — Use Explicit Typing (a generic typ: JWT is not effective typing)
• RFC 9449 §4.3 — the dpop+jwt precedent already enforced in pkg/dpop
• Related: OAuth access tokens: aud defaults to the issuer — adopt RFC 8707 resource indicators so it names the target resource server #199 (resource indicators → real aud), OAuth access tokens: serialize single-valued aud as a string; make multi-audience a policy-gated opt-in #200 (single-string aud)

---

Reported by Andrii Deinega via WIMSE WG review of ZeroID.

[adeinega]

For the record, the most recent JWT BCP indicates that

Another consideration for existing kinds of JWTs is that the use of a "typ" value of "JWT", as originally recommended in Section 5.1 of [RFC7519], does not constitute effective explicit typing.

https://www.ietf.org/archive/id/draft-ietf-oauth-rfc8725bis-04.html#name-use-explicit-typing

[saucam]

Good point — agreed, and it sharpens this issue. The "effective" qualifier is the key bit: emitting at+jwt only buys the anti-confusion property if the verifier actually requires it. Today our access-token verify path (pkg/authjwt) does no typ check at all, so this issue as originally written was really only half the fix.

We already do effective explicit typing for DPoP proofs — pkg/dpop/proof.go requires typ == "dpop+jwt" exactly and rejects anything else — so the plan is to mirror that for access tokens: emit at+jwt on the issue side and enforce it on the verify side, with the JWT override demoted to a temporary migration step rather than a permanent mode.

I've updated the issue body to capture both halves, plus the JWT-SVID-vs-at+jwt profile split (a token has a single typ, so it can't be both at once — which ties into #199, where knowing the target resource is what lets us type the token correctly). Thanks for the BCP pointer.