← Back to Blog Tutorials

OpenID Connect: PQC Migration for IdP Signing Keys

12 min read

OpenID Connect (OIDC) is the identity layer that sits on top of OAuth 2.0. Where OAuth handles authorization (what an app is allowed to do on your behalf), OIDC handles authentication (proving you are who you say you are) and identity (carrying claims about you, like your email address or your role inside an organization).

Almost every "Sign in with Google", "Sign in with Microsoft", "Sign in with Okta" button in the world rides on OIDC. So does most of the modern enterprise SSO landscape. So does most of the workforce identity stack at companies that use Auth0, Ping Identity, ForgeRock, Keycloak, AWS Cognito, or Azure AD B2C.

The protocol is built around a single trust artifact: the ID Token. An ID Token is a signed JWT issued by an Identity Provider (IdP) that asserts a user has authenticated. Relying Parties (the apps that want to know who the user is) verify that signature using a public key fetched from the IdP's JWKS endpoint.

When that signing key needs to migrate to post-quantum cryptography, the migration touches every relying party in the ecosystem. This blog post is about how to do that without breaking the world.

The OIDC Trust Chain In Twenty Seconds

User opens an app. The app redirects to the IdP. The user logs in at the IdP. The IdP redirects back to the app with an authorization code. The app exchanges that code for tokens at the IdP's token endpoint. The IdP returns an access token and an ID Token, both JWTs. The app verifies the ID Token signature against the IdP's public key, fetched from the IdP's JWKS endpoint at a URL like https://idp.example.com/.well-known/jwks.json.

That signature verification is the critical step. If the signature is invalid, the app refuses to authenticate the user. If the signature is forged, the app is compromised.

Today, that signature is almost always RS256 (RSA-2048 with SHA-256) or ES256 (ECDSA with P-256 and SHA-256). Some modern IdPs use EdDSA (Ed25519). All three are vulnerable to a sufficiently powerful quantum computer running Shor's algorithm.

Why The IdP Signing Key Is Special

In a typical enterprise, the IdP signing key is the most powerful credential in the entire identity infrastructure. Whoever holds it can:

Forge ID Tokens for any user, including admins
Authenticate as anyone to any relying party
Bypass all RBAC (role-based access control) policies that key downstream from "the IdP says so"

In a PKI sense, the IdP signing key is closer to a root CA key than to a user's password. It is rotated rarely, protected heavily, and used constantly.

This is exactly why PQC migration for OIDC matters: an attacker who can forge IdP signatures has effectively rooted the organization. And harvest-now-decrypt-later applies in a particularly nasty way here. An attacker harvesting JWKS public keys today can wait years for quantum capability and then forge tokens that look identical to real ones, with no detection mechanism on the relying party side.

NIST FIPS 204 And ML-DSA For OIDC

NIST FIPS 204, finalized August 2024, standardizes ML-DSA. The three parameter sets are ML-DSA-44, ML-DSA-65, and ML-DSA-87, corresponding to security categories 2, 3, and 5. For OIDC IdP signing, the realistic choices are:

ML-DSA-65: 1,952-byte public keys, 3,309-byte signatures. NIST Category 3 (roughly 192-bit classical security).
ML-DSA-87: 2,592-byte public keys, 4,627-byte signatures. NIST Category 5 (roughly 256-bit classical security).

Most enterprises will land on ML-DSA-65 for the same reason they use AES-256 over AES-128: it is the conservative middle ground that is broadly considered "good enough for everything sensitive". For nation-state-grade or military-grade IdPs, ML-DSA-87 is the right answer. CNSA 2.0, the U.S. government's commercial cryptographic algorithm suite, mandates ML-DSA-87 for the highest classified workloads.

The JWKS Endpoint Needs Multi-Key Support

The good news is that JWKS endpoints have always supported multiple keys. A JWKS document is a JSON array of JWKs (JSON Web Keys), each with its own kid (key ID). Relying parties pick the right key by matching the kid from the ID Token header.

So the migration sequence is:

Phase 1: Add an ML-DSA-65 key to your JWKS without using it for signing. Publish it. Let it sit. Watch your relying parties' verification libraries. Most will silently ignore the new key because they do not understand the algorithm. That is fine.

Phase 2: Begin dual-signing. When a relying party requests an ID Token, return it signed with whichever algorithm the relying party can handle, based on metadata or a request parameter. Default to RS256 or ES256 for compatibility.

Phase 3: Default to ML-DSA-65 for relying parties that support it. This requires either out-of-band agreement with each relying party (in enterprise) or a discoverable signal (in federated public OIDC).

Phase 4: Sunset RS256/ES256. Set a deprecation date. Notify relying parties. Roll forward.

This sequence will take years. The longest tail in OIDC migration is small relying parties with old libraries that nobody is actively maintaining.

Token Size Implications For ID Tokens

ID Tokens are typically passed in the OIDC response from token endpoint to client, so they are not subject to URL length limits. But they are sometimes stored in cookies or in browser storage, and they are always carried in API logs.

A typical RS256-signed ID Token with email, name, sub claim, and a few group memberships is around 800–1,200 bytes. The same token signed with ML-DSA-65 jumps to roughly 4,500–5,000 bytes including the base64url-encoded signature.

This breaks a few things in practice:

Cookie storage of ID Tokens (a common but not recommended pattern) hits the 4 KB browser limit.
Session storage with multiple ID Tokens for different relying parties balloons.
Log volume roughly quadruples if you log every token.

The mitigations:

Move to opaque session identifiers and look up the token server-side.
Use OIDC's request_uri parameter (RFC 9126 PAR) to keep large authorization requests off the wire.
Strip ID Tokens from logs after authentication completes.

Discovery Endpoint Updates

OIDC defines a discovery document at /.well-known/openid-configuration that advertises the IdP's capabilities. The id_token_signing_alg_values_supported field lists which signing algorithms the IdP can use.

For PQC migration, this field needs to grow:

``json { "id_token_signing_alg_values_supported": [ "RS256", "ES256", "EdDSA", "ML-DSA-65" ] } ``

Relying parties that read the discovery document and only know about RS256/ES256 will simply pick those. Relying parties that have been updated will see ML-DSA-65 and may prefer it.

The exact algorithm identifier ML-DSA-65 matches what the IETF JOSE Working Group is registering with IANA, following the FIPS 204 naming. Implementations should not invent their own identifiers.

Hybrid Signing And Composite JWKs

Some deployments will want belt-and-braces during the transition: dual-sign every ID Token with both a classical key and an ML-DSA key. The IETF has explored this through composite signature schemes, where a single signature blob contains both ECDSA and ML-DSA components and verification requires both to pass.

The downside is signature size: a hybrid ECDSA-P256 + ML-DSA-65 signature is roughly 3,400 bytes, larger than ML-DSA alone. The upside is that even if ML-DSA is later broken (highly unlikely but not impossible), the ECDSA component still provides classical security, and vice versa.

For most enterprises, the simpler approach is parallel JWTs: issue both a classical-signed and a PQC-signed ID Token, let the relying party choose. This avoids new signature formats and works with existing JWT libraries.

Federated Identity And SAML

OIDC is not the only federated identity protocol. SAML (Security Assertion Markup Language) is still dominant in many enterprise environments. SAML assertions are signed XML, typically with RSA-SHA256.

The PQC story for SAML is similar to OIDC: the IdP signing key needs to migrate, and the certificate that holds the public key needs to be reissued with an ML-DSA-65 algorithm OID. The XML Signature Working Group is tracking the necessary identifier registrations.

The migration is harder for SAML because XML Signature's canonicalization rules are notoriously complex, and many SAML libraries are old and slow to update. Plan for a longer tail.

OIDC Logout And Session Management

The id_token_hint parameter used in OIDC logout flows requires the relying party to send back the ID Token to the IdP. With PQC-sized tokens, this can hit URL length limits.

The fix is logout_hint (a non-token identifier) or pushed logout requests, both of which keep the token off the URL.

Userinfo Endpoint And Profile Claims

OIDC's /userinfo endpoint returns user profile claims (email, name, picture, etc.) when called with a valid access token. The response can itself be a signed JWT (id_token_signed_response_alg), which means the same PQC migration story applies: ML-DSA-65 signatures, larger response sizes, the same trade-offs about cookies and headers.

For most deployments, userinfo responses are fetched server-side by relying parties and then forwarded to clients. This means the size penalty of PQC userinfo JWTs is server-to-server traffic only, where bandwidth is cheap. Less of an operational concern than client-facing ID tokens.

OIDC Logout And Front-Channel Logout

OIDC defines several logout patterns: RP-initiated logout (the relying party redirects to an IdP logout endpoint), front-channel logout (the IdP loads logout URLs in iframes), and back-channel logout (the IdP makes server-to-server logout notifications).

Back-channel logout uses signed JWTs (logout tokens) sent to relying parties. These will inherit the same PQC migration as ID tokens. Front-channel logout typically does not involve signed payloads, so PQC is not directly relevant there.

For relying parties that handle logout tokens, the same operational concerns apply: larger tokens, library support requirements, and migration timing tied to the IdP.

What QNSQY Does

QNSQY's website offers Sign in with Google, and QNSQY Business supports single sign-on through OIDC with an organization's own identity provider. In both cases QNSQY is a relying party, not an identity provider, so post-quantum OIDC sign-in for QNSQY depends on identity providers and JWT libraries adding ML-DSA signatures.

The pattern we recommend to any SaaS vendor: let the major identity providers migrate their signing keys on their own timeline, and plan the migration of any tokens you sign yourself on yours.

Frequently Asked Questions

Q: Will Google and Microsoft migrate their IdP keys soon? Both have published PQC roadmaps. Google has been deploying ML-KEM hybrid in TLS for several quarters. ID Token signing migration is on their roadmap but no specific date has been announced as of 2025.

Q: Can I use ML-DSA-44 instead of ML-DSA-65 to save bytes? Yes, for non-critical workloads. ML-DSA-44 produces 2,420-byte signatures versus ML-DSA-65's 3,309. But CNSA 2.0 mandates ML-DSA-87 for the highest classified workloads, and ML-DSA-65 is the current recommended baseline for general enterprise use. Saving 900 bytes on a token rarely justifies dropping a security category.

Q: What about session cookies and refresh tokens? Refresh tokens are usually opaque random strings, not JWTs, so they are not affected. Session cookies are typically opaque session identifiers backed by a server-side session store. The PQC story applies to JWTs specifically, not to opaque tokens.

Q: Does my OIDC library validate ML-DSA today? Probably not. Major libraries are tracking the IETF and IANA work. Check release notes; jose, jose-jwt, nimbus-jose-jwt, and similar libraries are the ones to watch.

Q: Can I just keep using RS256 forever? Eventually no. NIST is deprecating RSA on the timeline laid out in the FIPS guide. The harvest-now-decrypt-later threat applies to signing keys too — an attacker who captures your public RS256 key today and reverses it via quantum factoring later can mint forgeries against any token they can replay.

Sources

OpenID Connect Core 1.0. https://openid.net/specs/openid-connect-core-1_0.html
RFC 7517 — JSON Web Key (JWK). https://datatracker.ietf.org/doc/html/rfc7517
RFC 8414 — OAuth 2.0 Authorization Server Metadata. https://datatracker.ietf.org/doc/html/rfc8414
NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final
CNSA 2.0 Algorithm Suite Guidance. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
IANA JOSE Algorithms Registry. https://www.iana.org/assignments/jose

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY