RFCs for JWT, OAuth and MCP-auth, by Tom O'Rourke

Most of the identity work across the labs sits on a stack of IETF RFCs. This is the working reference list I keep open when writing or reviewing those pages, grouped by category.

A note on framing

Before the tables, two distinctions worth being explicit about:

JWT/JOSE and OAuth 2.0 are IETF standards with a deep stack of published RFCs. Everything in the tables below is one of those.
OIDC (OpenID Connect) is not an IETF RFC. It is a suite of specifications published by the OpenID Foundation that builds on the OAuth 2.0 and JWT/JOSE RFCs. There is no "OIDC RFC" to cite, so OIDC sits in its own section with a pointer to the OpenID Foundation specs.
MCP has no published RFC yet. There are Internet-Drafts in flight in 2026 but nothing standards-track. The MCP authorisation short-list below names the OAuth/JOSE RFCs that the current MCP authorisation model normatively pulls in, so you can pin down the contract without waiting for an RFC number to exist.

Every link in the "Where on the site" column points at a lab or KB page that actively puts that RFC to work. A "—" in that column means the RFC is included for reference completeness but no page on the site currently leans on it.

What JOSE actually is

JOSE stands for JSON Object Signing and Encryption. It's the IETF working group, and the family of RFCs that came out of it, defining how to sign, encrypt and represent cryptographic keys using JSON. The right mental model is that JOSE is the cryptographic envelope layer underneath JWT. JWT is the claims format. JOSE is what makes those claims tamper-evident, optionally confidential, and verifiable.

JOSE is essentially five interlocking RFCs:

RFC 7515 (JWS) — the structure for signed or MAC'd content. Three base64url segments separated by dots: header, payload, signature. This is the thing most people picture when they look at a JWT.
RFC 7516 (JWE) — the structure for encrypted content. Five segments: header, encrypted key, IV, ciphertext, authentication tag.
RFC 7517 (JWK) — how a cryptographic key is represented as a JSON object. Also defines JWK Set (JWKS), which is the array of keys you fetch from /.well-known/jwks.json on an IdP.
RFC 7518 (JWA) — the registry of algorithm identifiers: RS256, ES256, HS256, EdDSA, A256GCM and so on. The alg and enc header values point at this registry.
RFC 7519 (JWT) — the claims format that uses JWS or JWE as its envelope. A JWT is either a JWS wrapping a JSON claims payload, or (less commonly) a JWE wrapping a JWS.

How they fit together: the claims (iss, sub, aud, exp, ...) live in a JSON payload. That payload gets wrapped in a JWS (signed) or a JWE (encrypted). The JWS / JWE header names the algorithm via JWA. The verifier fetches the signing key as a JWK from a JWKS endpoint. The whole stack is JOSE.

So when you're debugging a real-world JWKS resolution issue against an external IdP: the token format is JWT (RFC 7519), the signature wrapper is JWS (RFC 7515), the alg: RS256 in the header is JWA (RFC 7518), and the keys at /.well-known/jwks.json are a JWK Set (RFC 7517). All four are JOSE.

JWT gets all the attention because it's what application developers touch, but JOSE is the bigger surface area. You can use JWS to sign anything, not just JWT claims. You can use JWE to encrypt arbitrary payloads. You can use JWK to publish keys for any purpose. JWT just happens to be JOSE's most popular consumer.

The reason this distinction matters in practice: the most common "JWT" vulnerabilities (alg: none, RS256-to-HS256 confusion, key injection via jku or x5u) are all JOSE-layer attacks, not JWT-layer ones. RFC 8725 (JWT BCP) is the spec that codifies the mitigations, which is why it sits at the top of the reading order below.

JWT and JOSE family

The cryptographic envelope under every signed or encrypted token.

RFC	Title	What it is	Where on the site
RFC 7515	JSON Web Signature (JWS)	The signing wrapper underneath every signed JWT. Defines the compact serialisation (`header.payload.signature`), the `alg` registry (RS256, ES256, EdDSA, etc.) and how to verify a signature against a public key.	jwt-mint helper — composes JWS-compact tokens for the negative-test cases used across the JWT labs.
RFC 7516	JSON Web Encryption (JWE)	The encrypted-token sibling of JWS. Same five-segment compact serialisation, but the payload is ciphertext. Used when claims themselves are sensitive and TLS termination at the edge isn't enough.	—
RFC 7517	JSON Web Key (JWK) and JWK Sets (JWKS)	How public keys are published as JSON so a gateway can fetch them and verify signed tokens without out-of-band key exchange. A JWKS endpoint is just a JSON document at a stable URL, served by the IdP.	jwt-claims-to-headers · jwt-mint helper — every JWT lab points the gateway's JWKS-remote config at a small in-cluster JWKS service.
RFC 7518	JSON Web Algorithms (JWA)	The registry behind the `alg` / `enc` identifiers used in JWS and JWE. Every RS256 / ES256 / A256GCM string in a JWT header is defined here.	—
RFC 7519	JSON Web Token (JWT)	The token format. Defines the standard claim set (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`) and how to construct, parse and validate a JWT on top of JWS.	jwt-claims-to-headers · jwt-oidc-obo · jwt-mint helper — the foundation every JWT page is built on.
RFC 7520	Examples of Protecting Content with JOSE	A test-vector RFC. Reference inputs and expected outputs for the JWS/JWE/JWK specs, useful when validating a fresh implementation against the standards.	—
RFC 7638	JWK Thumbprint	A canonical hash of a JWK's public key material. Gives every key a stable identifier independent of how the JWK is serialised. Used as the `kid` in many real-world JWKS deployments and as the binding identifier inside DPoP's `cnf.jkt`.	—
RFC 7797	JWS Unencoded Payload Option	Allows the JWS payload to be left unencoded and detached. Used where the payload is large or detached and base64url-encoding it inside the JWS is wasteful, e.g. some W3C Verifiable Credentials profiles, FAPI message signing, and JAdES (the EU eIDAS JSON signature format). Note: RFC 9421 (HTTP Message Signatures) does not use JWS at all, it defines its own canonicalisation-based signing.	—
RFC 8037	CFRG Curves (Ed25519/Ed448, X25519/X448) for JOSE	Adds the EdDSA signing algorithm (Ed25519 / Ed448) and the X25519 / X448 curves usable inside the ECDH-ES key agreement already defined by RFC 7518. The reason any of those algorithms or curves have a defined JOSE header value.	—
RFC 8725	JWT Best Current Practices (BCP 225)	The "what not to do" companion to RFC 7519. Mandatory reading for anyone implementing or reviewing JWT validation: pinned algorithms, audience checks, key rotation, `none`-algorithm bypass, mix-up attacks. If a JWT validation library or policy is wrong, it's usually wrong against this BCP.	—
RFC 8812	COSE and JOSE Registrations for WebAuthn	Registers ES256K and the secp256k1 curve for COSE and JOSE. Mostly relevant when JOSE meets WebAuthn / FIDO2 hardware.	—
RFC 9864	Ed25519 and Ed448 in JOSE	Updates RFC 8037 to lock down the Ed25519 / Ed448 signing details and clarify behaviour the original spec left ambiguous.	—

OAuth 2.0 — core

The framework everything else extends, plus the security BCPs that pin sane defaults.

RFC	Title	What it is	Where on the site
RFC 6749	The OAuth 2.0 Authorization Framework	The foundational spec. Defines the four grant types, the role names (resource owner / client / authorization server / resource server) and the wire-level endpoints everything else extends. Every other OAuth RFC builds on this.	—
RFC 6750	OAuth 2.0 Bearer Token Usage	How a client presents an access token to a resource server: the `Authorization: Bearer <token>` header, the form-encoded body alternative, and the `WWW-Authenticate: Bearer` challenge format with its `error` / `error_description` parameters.	—
RFC 6819	OAuth 2.0 Threat Model and Security Considerations	The threat-model companion to RFC 6749. Names the attack classes (token theft, CSRF, code injection, mix-up, open redirect) and the mitigations. Largely superseded by RFC 9700 but still useful for context.	—
RFC 8252	OAuth 2.0 for Native Apps (BCP 212)	The "use the system browser, not an in-app webview" BCP. Mandates PKCE, AppAuth-style redirect handling and external-agent authorisation for native clients.	—
RFC 9700	Best Current Practice for OAuth 2.0 Security (BCP 240)	The 2025 update to OAuth 2.0 security guidance, and effectively the OAuth 2.1 substrate. Pins PKCE for every client type, kills the implicit and password grants, hardens redirect-URI matching and updates the threat-model from RFC 6819. If you can only read one OAuth RFC, read this one.	—

OAuth 2.0 — tokens, format and lifecycle

How tokens are formatted, exchanged, introspected, bound to a sender, and revoked.

RFC	Title	What it is	Where on the site
RFC 7009	OAuth 2.0 Token Revocation	A standard endpoint a client can call to invalidate an access or refresh token before it naturally expires.	—
RFC 7521	Assertion Framework for OAuth 2.0	The generic plumbing for assertion-based client authentication and assertion grants. SAML and JWT both layer on top via the next two RFCs.	—
RFC 7522	SAML 2.0 Profile for OAuth 2.0	How to use a SAML assertion as either a client-authentication credential or an authorisation grant against the OAuth token endpoint.	—
RFC 7523	JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants	The JWT counterpart to RFC 7522. Lets a client authenticate with a signed JWT (client_assertion / private_key_jwt) or exchange a signed JWT for an access token. Underlies most modern machine-to-machine OAuth flows.	—
RFC 7662	OAuth 2.0 Token Introspection	A standard endpoint a resource server can call to ask the authorization server "is this access token still valid, and what does it look like inside?". Used when tokens are opaque, or when you want a fresh authoritative answer rather than trusting the cached JWT signature.	solo-ext-auth — the OAuth2 introspection plugin in the ext-auth-service plugin chain.
RFC 8693	OAuth 2.0 Token Exchange	A token exchange grant type at the authorization server: trade one token (subject) for another (the actor / on-behalf-of token), with explicit `audience` and `resource` parameters. The backbone of every "the gateway re-mints a downstream token before calling the next hop" pattern.	jwt-token-exchange · jwt-oidc-obo · agentgw-agentic-mcp · mcp-setup · solo-ext-auth — the most-referenced RFC on the site.
RFC 8705	OAuth 2.0 Mutual-TLS (mTLS-bound tokens)	Two related features: client authentication with an mTLS certificate at the token endpoint, and certificate-bound access tokens (the token carries a hash of the client cert in the `cnf` claim, so it's only usable by a holder of the matching private key). One of two standard ways to make a token non-bearer.	jwt-mint helper — supports the cnf-thumbprint claim for sender-constrained-token negative tests.
RFC 9068	JWT Profile for OAuth 2.0 Access Tokens	Standardises what an access-token JWT should look like: required claims, header type (`at+jwt`), audience semantics. Pins down the "JWT access token" shape that resource servers were previously free to interpret however they liked.	—
RFC 9449	OAuth 2.0 Demonstrating Proof of Possession (DPoP)	The other way to make a token non-bearer, without mTLS. The client signs each request with a private key and binds the access token to the matching public key via the `cnf` claim. Cheaper to deploy than mTLS at the edge, and works fine from a browser SPA.	jwt-mint helper — supports DPoP-style cnf claims so the sender-constrained-token cases line up with RFC 9449.
RFC 9701	JWT Response for OAuth Token Introspection	Lets the introspection endpoint return a signed JWT instead of a plain JSON document, so the resource server can verify and cache the answer cryptographically.	—

OAuth 2.0 — authorisation request flow

How the authorisation request itself is hardened: PKCE, device grant, audience pinning, signed and pushed requests, structured authorisation details, step-up.

RFC	Title	What it is	Where on the site
RFC 7636	Proof Key for Code Exchange (PKCE)	A short challenge / verifier pair that stops a stolen authorisation code from being redeemed by anyone other than the original client. RFC 9700 makes PKCE mandatory for every client type, public or confidential.	—
RFC 8628	OAuth 2.0 Device Authorization Grant	The "go to this URL on your phone and enter this code" flow for input-constrained devices (TVs, CLIs, embedded). Also used by some CLI tools that don't want to spin up a local listener.	—
RFC 8707	Resource Indicators for OAuth 2.0	Adds a `resource` request parameter to authorize / token / token-exchange calls so the client tells the AS exactly which resource server the issued token is for. The AS pins the matching `aud` claim, and the gateway rejects any token whose audience does not match the route's expected resource. Closes the confused-deputy class of attack.	gateway-api-ambient · kgateway-vs-istio-gw — the resource-binding negative tests in gateway-api-ambient exercise RFC 8707 directly.
RFC 9101	The OAuth 2.0 Authorization Request (JAR)	Lets the client send the authorisation request parameters inside a signed (and optionally encrypted) JWT instead of as query-string parameters. Stops parameter tampering between the user agent and the AS.	—
RFC 9126	OAuth 2.0 Pushed Authorization Requests (PAR)	Lets the client POST the authorisation request directly to the AS up-front, then redirects the user with just a short reference. Keeps potentially large or sensitive request parameters off the front channel.	—
RFC 9396	OAuth 2.0 Rich Authorization Requests (RAR)	Replaces the flat `scope` string with a structured `authorization_details` array, so a single token can carry per-resource, per-action, per-target authorisation. The "transfer £500 from account A to account B" shape rather than the "payments.write" shape. Where you go when scopes stop scaling.	securing-mcp-agentic-systems — referenced in the deep-dive on MCP tool-call authorisation granularity.
RFC 9470	OAuth 2.0 Step Up Authentication Challenge Protocol	How a resource server signals "you need to re-authenticate with a stronger factor" via the `WWW-Authenticate` challenge, and how the client triggers a new authorisation request that asks the AS for a higher `acr` claim.	—

OAuth 2.0 — discovery, registration, metadata

How clients find authorisation servers, how resource servers advertise which AS they trust, and how clients register themselves dynamically.

RFC	Title	What it is	Where on the site
RFC 7591	OAuth 2.0 Dynamic Client Registration	Lets a client register itself with an AS programmatically and receive client credentials in return. The mechanism MCP's existing authorisation guidance relies on (though MCP is moving toward client-id metadata documents per SEP-991).	—
RFC 7592	OAuth 2.0 Dynamic Client Registration Management (experimental)	The CRUD endpoints for managing a previously-registered client. Experimental status, but referenced anywhere an AS exposes a self-service client portal.	—
RFC 8414	OAuth 2.0 Authorization Server Metadata	The `.well-known/oauth-authorization-server` discovery document. Lets a client (or a resource server) ask the AS for its endpoints, supported grant types, signing keys and PKCE methods without configuring them by hand.	—
RFC 9207	OAuth 2.0 Authorization Server Issuer Identification	Adds an `iss` parameter to the authorisation response so the client can verify which AS actually answered the request. Mitigates the mix-up attack class where a malicious AS intercepts and replays codes for a different AS.	—
RFC 9728	OAuth 2.0 Protected Resource Metadata	The keystone for federated authorisation. A resource server publishes `.well-known/oauth-protected-resource` listing the authorisation servers it trusts, supported token types, and resource identifiers. This is exactly the discovery mechanism MCP uses so a client knows which AS to obtain a token from for a given MCP server.	—

Events and HTTP signing

The cross-domain signalling and request-signing RFCs that emerging agent protocols lean on.

RFC	Title	What it is	Where on the site
RFC 8417	Security Event Token (SET)	A JWT-shaped envelope for security events (logout, credential change, session revocation) that one security domain wants to push to another. The format under CAEP, OpenID Shared Signals and similar.	—
RFC 8935	Push-Based Delivery of SETs	Webhook-style delivery for Security Event Tokens. The transmitter POSTs SETs to a receiver's HTTPS endpoint.	—
RFC 8936	Poll-Based Delivery of SETs	The pull-style counterpart. The receiver polls a queue endpoint to pick up SETs the transmitter has enqueued.	—
RFC 9421	HTTP Message Signatures	A standard way to sign HTTP requests and responses end-to-end (method, headers, body), independent of TLS. Used by emerging agent and webhook specs that need integrity guarantees across intermediaries that terminate TLS.	—

MCP authorisation short-list

MCP has no published RFC yet, but the current MCP authorisation model normatively pulls in a specific subset of the OAuth and JOSE stack. If you're triaging an MCP-meets-IdP integration (token audience mismatch, JWKS resolution, "which AS does this MCP server trust"), this is where to look first:

RFC 6749 + RFC 9700 — OAuth 2.0 plus the 2025 security BCP. The OAuth 2.1 substrate MCP authorisation is defined against.
RFC 7636 — PKCE, mandatory for every MCP client.
RFC 7519 + RFC 9068 — JWT format plus the JWT access-token profile.
RFC 7517 — JWK / JWKS, how the AS publishes the keys an MCP server needs to verify tokens.
RFC 8414 — AS metadata discovery.
RFC 9728 — Protected Resource Metadata, how the MCP server advertises its AS. This is the keystone: it solves exactly the discovery problem JWKS / IdP integrations hit when the resource and the AS aren't co-owned.
RFC 8707 — Resource Indicators, audience binding, prevents confused-deputy.
RFC 7591 — Dynamic Client Registration, though MCP is migrating to Client ID Metadata Documents per SEP-991.

If an MCP integration is failing on token audience mismatch or JWKS resolution, RFC 9728 + RFC 8707 are the two specs to read first. Everything else either falls out from them or is a layering question on top.

OIDC — not an IETF RFC

OpenID Connect is not in the table because there is nothing to put there. The OIDC core specifications are published by the OpenID Foundation, not the IETF. They build heavily on the OAuth and JOSE RFCs above (every id_token is a JWT per RFC 7519, every JWKS is RFC 7517, every discovery document mirrors RFC 8414), but the OIDC specs themselves don't have RFC numbers.

The OIDC documents most often referenced alongside the RFCs in the tables above:

OpenID Connect Core 1.0 — the id_token contract, the standard claims, the authentication request flows that extend OAuth.
OpenID Connect Discovery 1.0 — the .well-known/openid-configuration document.
OpenID Connect Dynamic Client Registration 1.0 — OIDC's own client-registration profile, layered on RFC 7591.
OpenID Federation 1.0 — federation metadata and trust chains, for multi-party OIDC deployments.

A suggested reading order

If you're new to this material and want to get from "I've heard of JWT" to "I can read the agentgateway and kgateway policies and understand what they're enforcing", the order I'd suggest:

Read RFC 7519 (JWT) first. The whole token story falls into place once the standard claim set is in your head.
Skim 7515 (JWS) and 7517 (JWK). Format specs, not philosophy.
Read RFC 8725 (JWT BCP). The single highest-value security read in the list.
Skim RFC 6749 (OAuth 2.0) and read RFC 9700 (OAuth security BCP). 9700 is the modern lens on 6749.
Read RFC 8693 (token exchange). The on-behalf-of and downstream-re-mint patterns become precise, and it's the most-cited RFC across this site.
Read RFC 8707 (resource indicators) and RFC 9728 (PRM). Short, surgical, both fix real attack classes around audience and AS-discovery.
Pick up RFC 7662 (introspection) when you hit the introspection plugin in the ext-auth chain.
Save 9396 (RAR), 9449 (DPoP) and 8705 (mTLS-bound) for last. You only need these once your AS, your gateway and your clients all support them — that's an integration project rather than a reading project.

None of these RFCs are long. Most are a one-evening read. The compounding payoff is huge, because every gateway, every IdP and every authorisation library on the planet implements some subset of them, and reading the spec is faster than reverse-engineering the implementation.