up:: In the Protocols MOC

PQC in OAuth 2.0 and OIDC

PQC in OAuth 2.0 and OIDC is the work of moving the cryptographic proofs that authorization flows depend on onto post-quantum algorithms, and it reaches a set of surfaces the token-signing view alone doesn’t cover. OAuth 2.0 (RFC 6749) and OpenID Connect layer several security mechanisms on top of plain token signing: DPoP (RFC 9449) proves a client possesses a key pair, mutual-TLS-bound tokens (RFC 8705) tie a token to a client certificate, the private_key_jwt client assertion (RFC 7523) authenticates a client with a signed JWT, and JWT-secured authorization requests (JAR, RFC 9101) sign the request itself.

Every one of these rests on a classical digital signature or a classical TLS key exchange, which a quantum computer can forge or break, so the whole authorization layer that every SaaS API and B2B integration runs on is in scope for the migration, on the same signature-forgery clock as certificates.

The short version:

1. OAuth 2.0 and OIDC secure their flows with signatures and key proofs that reach well beyond the signed token, so the migration covers DPoP, mTLS-bound tokens, private_key_jwt, and signed requests.
2. DPoP (RFC 9449) binds a token to a client’s key pair with a signed proof JWT, so the proof signature has to move to ML-DSA.
3. mTLS-bound tokens (RFC 8705) tie a token to a client certificate over Mutual TLS, so both the TLS key exchange and the certificate signature are in scope.
4. The private_key_jwt client assertion (RFC 7523) and signed authorization requests (JAR, RFC 9101) are client-authenticity signatures that a forged post-quantum key could impersonate.
5. These are forge-in-real-time surfaces, not harvestable ones, so they migrate on the slower signature track, but their blast radius is large because one authorization server underwrites every API that trusts it.

Think of OAuth like a building’s access-badge system. The badge itself is the token, but the real security is in the machinery around it: a reader that checks the badge is genuinely yours rather than a photocopy (proof-of-possession), a turnstile that only accepts a badge presented through your own registered card (certificate binding), a signature on the visitor request that proves it came from a real department head (the client assertion and the signed request). A quantum computer is a master forger that can reproduce any of those signatures. Replacing them with post-quantum signatures is re-issuing the whole system’s seals so the forger’s copies stop working, and it has to reach every checkpoint, the readers and turnstiles as much as the badge.

What is OAuth 2.0 and OIDC, and where does cryptography live in it?

OAuth 2.0 is the authorization framework that lets an application obtain scoped access to a resource on a user’s behalf without handling the user’s password, and OpenID Connect (OIDC) is the identity layer built on top of it that adds authentication and an identity token. Assuming professional fluency with the flows, the cryptography lives in four places, and each is a distinct migration surface:

1. Token signatures. The access token or OIDC ID token is often a signed JWT (JOSE alg values like RS256 or ES256), and the signature is what a resource server verifies. This is the surface JWT covers in depth.
2. Client authentication. A confidential client proves its identity to the authorization server, and the strong methods are cryptographic: private_key_jwt (a signed JWT assertion, RFC 7523) and mutual-TLS client authentication (RFC 8705).
3. Token binding (proof-of-possession). Instead of a bearer token anyone holding it can use, a sender-constrained token is bound to a key the legitimate client must prove it holds, through DPoP (RFC 9449) or mTLS certificate binding (RFC 8705).
4. Request integrity. The authorization request itself can be signed as a JWT so its parameters can’t be tampered with in transit, which is JAR (RFC 9101).

Source: D. Hardt, Ed., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012, RFC 6749; OpenID Connect Core 1.0, openid.net.

The reason to name all four is that a team can migrate its token signatures, believe OAuth is handled, and leave the client-authentication, binding, and request-integrity signatures classical. Those are separate cryptographic surfaces on the same framework, and a quantum-safe authorization layer needs all of them moved.

How does DPoP go post-quantum?

DPoP goes post-quantum by moving the proof signature it relies on from a classical algorithm to ML-DSA, because DPoP’s whole mechanism is a signature the client makes with a private key to prove possession of the matching public key. RFC 9449 sender-constrains OAuth access and refresh tokens by binding them to a client’s public/private key pair: the client includes a DPoP header, a JWT signed with its private key, on each request, and the authorization server binds the issued token to that public key using a JWK thumbprint confirmation. A token bound this way can only be used by whoever holds the private key.

Source: D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite, “OAuth 2.0 Demonstrating Proof of Possession (DPoP),” RFC 9449, September 2023, RFC 9449.

The quantum exposure is the proof signature. If the DPoP proof is signed with a classical algorithm like ES256, a quantum computer running Shor’s algorithm could derive the private key from the public key and forge a valid proof, defeating the binding. The migration re-registers the client’s proof key as an ML-DSA key and signs the proof with the corresponding post-quantum JOSE alg, so the signature verification pins to a post-quantum algorithm. The practical catch is size: an ML-DSA signature is kilobytes where an ES256 signature is tens of bytes, and a DPoP proof rides in an HTTP header on every request, so header-size limits are a real deployment constraint, the same one JWT migration hits.

How do mTLS-bound tokens and client authentication migrate?

mTLS-bound tokens and mutual-TLS client authentication migrate on two fronts at once, because RFC 8705 uses a full Mutual TLS connection, so both the TLS key exchange and the client certificate’s signature are in scope. RFC 8705 lets a client authenticate to the authorization server with mutual TLS (self-signed or PKI certificates) and binds the issued access token to the client certificate, represented in a JWT by the x5t#S256 confirmation method, so the token is usable only over a TLS connection presenting that same certificate.

Source: B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens,” RFC 8705, February 2020, RFC 8705.

The two surfaces migrate differently:

1. The TLS key exchange is the harvestable half, and it moves onto a hybrid handshake like X25519MLKEM768 exactly as any Mutual TLS connection does, closing the harvest-now-decrypt-later window on the channel.
2. The client certificate signature is the forge-in-real-time half, and it moves onto ML-DSA certificates so a quantum attacker can’t forge a certificate matching the bound thumbprint.

The private_key_jwt client assertion (RFC 7523) is the pure-signature sibling. The client authenticates by signing a JWT with its own private key and sending it as a client_assertion, so there’s no TLS binding, only a signature, and its migration is re-registering the client’s assertion key as an ML-DSA key. A forged post-quantum signature here would let an attacker impersonate the client to the authorization server, which is why it’s a real surface even though it carries no harvesting clock.

Source: M. Jones, B. Campbell, C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” RFC 7523, May 2015, RFC 7523.

What about signed authorization requests (JAR)?

Signed authorization requests migrate by re-signing the request JWT with a post-quantum algorithm, because JAR (RFC 9101) packages the authorization request parameters into a signed JWT so they can’t be tampered with or injected in transit, and that integrity rests entirely on the signature. Where a plain authorization request passes its parameters in the URL, JAR wraps them in a JWT the authorization server verifies, so a valid signature is what proves the request is genuine and unaltered.

Source: N. Sakimura, J. Bradley, M. Jones, “The OAuth 2.0 Authorization Framework, JWT-Secured Authorization Request (JAR),” RFC 9101, August 2021, RFC 9101.

The quantum exposure is the same forge-the-signature problem. If the request JWT is signed classically, a quantum attacker could forge a request that appears to come from a legitimate client, so the migration moves the request signature to ML-DSA. JAR shares the size constraint of every JWT-based mechanism here, because a post-quantum signature enlarges the request object, which matters when the request travels as a URL parameter or a pushed authorization request payload.

Which OAuth surfaces are urgent, and which can wait?

None of the OAuth signature surfaces are harvestable, so they all sit on the slower forge-in-real-time track, but their blast radius makes the central ones a near-front priority anyway. The table sorts them by mechanism, exposure type, and what actually migrates.

Surface	RFC	What’s cryptographic	Quantum exposure	Migration
Token signature (JWT)	JOSE / RFC 9964	Signature on the access or ID token	Forge a token	Re-sign with ML-DSA
DPoP proof	RFC 9449	Signature proving key possession	Forge the proof, defeat binding	Re-key proof to ML-DSA
mTLS-bound token	RFC 8705	TLS handshake plus client certificate	Harvest the channel; forge the certificate	Hybrid TLS plus ML-DSA certificate
private_key_jwt	RFC 7523	Signature on the client assertion	Impersonate the client	Re-key assertion to ML-DSA
Signed request (JAR)	RFC 9101	Signature on the request JWT	Forge the request	Re-sign with ML-DSA

The prioritization rule is the one from the protocol hub: signatures are Non-HNDL, so there’s nothing to harvest, but a central authorization server’s signing key underwrites every API and every client that trusts it, so its blast radius is enormous and it belongs near the front despite the slower clock. The mTLS-bound-token surface is the exception that carries a harvesting clock, because its TLS key exchange is harvestable like any other TLS channel, so that half moves first.

Common misconceptions

1. “Migrating our JWT signatures makes OAuth quantum-safe.” Token signing is one surface of several. DPoP proofs, mTLS binding, private_key_jwt client authentication, and signed requests each carry their own classical signature or key exchange, and a quantum-safe authorization layer moves all of them.
2. “OAuth is bearer tokens, so there’s no key to migrate.” Modern OAuth increasingly uses sender-constrained tokens (mTLS or DPoP) and cryptographic client authentication, so there are real key pairs and signatures throughout the flow, all of them classical by default.
3. “These flows are harvestable, so they’re urgent like TLS key exchange.” The signature surfaces are forge-in-real-time, so they migrate on the slower track. The exception is the TLS key exchange inside mTLS binding, which is harvestable and moves first.
4. “DPoP just needs a config flag for post-quantum.” DPoP’s proof is a signed JWT on every request, so moving it to ML-DSA enlarges the header on every call, and header-size limits become a real deployment constraint, the same one JWT migration hits.
5. “Client authentication isn’t part of the quantum problem.” private_key_jwt and mTLS client authentication are exactly a quantum problem, because a forged post-quantum signature or certificate would let an attacker impersonate a client to the authorization server, which underwrites everything that client can reach.

Questions people ask

Does the quantum threat affect OAuth and OIDC? Yes. Every cryptographic mechanism in the flow, token signatures, DPoP proofs, mTLS binding, private_key_jwt, and signed requests, rests on a classical signature or TLS key exchange that a quantum computer can forge or break, so the whole authorization layer is in scope.

Isn’t migrating the JWT signature enough? No. Token signing is one surface, and DPoP (RFC 9449), mTLS-bound tokens (RFC 8705), the private_key_jwt assertion (RFC 7523), and signed authorization requests (RFC 9101) are separate cryptographic surfaces that each need to move to a post-quantum algorithm.

How does DPoP migrate? By re-keying its proof to ML-DSA. DPoP binds a token to a client key pair through a signed proof JWT (RFC 9449), so moving the proof signature to a post-quantum algorithm is what keeps a quantum attacker from forging the proof and defeating the binding.

Are these OAuth surfaces harvestable? Mostly no. They’re signature surfaces, so they’re forge-in-real-time and migrate on the slower signature track. The exception is the TLS key exchange inside mTLS-bound tokens, which is harvestable like any TLS channel and moves first.

What replaces the signatures? ML-DSA is the general-purpose post-quantum signature, and the IANA JOSE and COSE code points for it are specified so a JWT, DPoP proof, client assertion, or signed request can name a post-quantum alg. The main deployment friction is the larger signature size against header and URL limits.

Why prioritize the authorization server if signatures aren’t harvestable? Blast radius. A central authorization server’s signing key underwrites every API and every client that trusts it, so a forged key impersonates the whole trust fabric, which is why it belongs near the front of the plan even though the harvesting clock isn’t running on it.

Does this touch my B2B API integrations? Directly. Machine-to-machine OAuth commonly uses private_key_jwt or mTLS client authentication, so every B2B integration authenticating that way has a client key pair or certificate that needs to move to a post-quantum algorithm.

---

Everything here is the map, given freely. When your team needs its OAuth and OIDC estate inventoried across every proof, binding, and client-authentication surface, its harvestable mTLS channels prioritized, and its signing keys sequenced onto post-quantum algorithms, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.