By Phil Schmieder (University of Wuppertal), Ethan Heilman (Cloudflare), with thanks to the following editors, reviewers, and contributors:  Ralph Bragg, Gail Hodges, Frederik Krogsdal Jacobsen, Michael Jones, Nat Sakimura, Bas Westerbaan.

Please note: A number of corrections and clarifications were made in October a few weeks after initial publication by the OpenID Connect Working Group. Particular thanks to the following post-publication contributors: Brian Campbell, Dick Hardt, Joseph Heenan, Michael Jones, Aaron Parecki, and Filip Skokan.

As the Internet migrates to post-quantum cryptography, we wanted to look at some potential issues OpenID Connect deployments may face when migrating to post-quantum algorithms and what best practices can be employed to smooth this migration.

On a high level, making OpenID Connect post-quantum secure appears easy. Post-quantum signature schemes like ML-DSA are drop-in replacements for classical, i.e. not post-quantum secure, signature schemes like RS256. Simply replace the algorithm RS256 with ML-DSA, right? The IETF standard enabling ML-DSA signatures for OpenID Connect is done.  However, in many cases it may not be that easy. We consider the following issues and some best practices that help mitigate these issues.

1. Post-quantum signature algorithms have significantly larger signatures and/or public keys. This can break software and protocols that are unable to handle the increased size.
2. The introduction of new algorithms may surface existing bugs in OpenID Connect  implementations.
3. Most OpenID Connect software implementations do not support post-quantum algorithms.
4. A practical post-quantum transition strategy should rely on leveraging existing protocol mechanisms and metadata structures enabling cryptographic agility.

Below we step through these issues one by one, looking at the current state of the ecosystem, and what steps can be taken to remediate these risks.

Most OpenID Connect flows depend not just on JWT signing but also on the underlying server-authenticated TLS for authentication, integrity, and confidentiality. Migrating to PQ TLS should therefore be a priority, with post-quantum key exchange (PQ-KEMs) in TLS being an urgent need to protect current traffic against passive harvest-now-decrypt-later attacks, and TLS authentication becoming critical as Q-Day approaches. At any layer of the stack, however, deploying new algorithms can take years, making early migration efforts essential to ensure preparedness and smooth out unforeseen bumps in the road.

The Size Problem: Bigger Keys and Signatures

One source of these problems is the large size of cryptographic public keys and signatures for novel post-quantum secure schemes when compared to RS256 or ES256. Today’s most commonly used algorithm RS256 (2048-bit) has public keys which are 256 bytes and signatures that also are 256 bytes. In contrast, ML-DSA-44, a leading post-quantum secure signature algorithm, has public keys of 1,312 bytes and signatures of 2,420 bytes. That still makes ML-DSA-44 relatively small for a post-quantum signature scheme. In addition, public keys and signatures are then Base64url-encoded which further increases their size. Naturally, a size increase like this will lead to data structures (such as ID Tokens) that are then much larger than today and may cause them to exceed hard size limits in certain places.

Lingering Bugs That Surface Now

As with all changes to technology, seemingly unrelated bugs may arise unexpectedly. This can be, for example, due to oversights in the new technology, bugs in older technology that were never triggered or protocol ossification.

Latent bugs have surfaced in OpenID Connect implementations. Ralph Bragg from Raidiam reported on a common bug in JWT libraries when parsing JWKS that contain a JWK with the newer key type of  `AKP` (RFC 9964). The bug occurs when the library parses a JWKS and encounters a JWK it does not know how to parse. The specification states that the implementation  should ignore the JWK it does not know how to handle and continue to parse and use the rest of the JWKs in the JWKS that it understands. The bug is that the library throws an error and fails the entire JWKS. This is not unique to post-quantum algorithms. The same may happen with a classical cryptographic algorithm. 

This is a huge problem when OpenID Providers (OPs) publish keys of that type in their JWKS. Even when the mandatory RS256 public key is included in the JWKS and the OP additionally publishes a public key that is using the `AKP` type, which is used for ML-DSA public keys, affected libraries fail to parse the entire JWKS. This bug not only leads to `AKP` type public keys not being able to be fetched, but also any public key in a JWKS where an `AKP` type public key is present.

Identifying and fixing bugs like this is crucial before post-quantum secure algorithms are rolled out. Thus, we should aim to fix any blockers or bugs now so they don’t delay the post-quantum transition in the future. The OpenID Conformance Suites for OpenID Connect, FAPI1, FAPI2, FAPI-CIBA and OpenID4VP have already added tests to check that OAuth Clients / OpenID4VP Wallets are ignoring unknown keys in the most critical locations (see OIDCC/FAPI1/FAPI2/FAPI-CIBA client: publish unusable keys in the Issuer's JWKS in all RP tests  and VP Wallet: surround the usable encryption key with unusable ones ).

Support for New Algorithms

Before post-quantum secure tokens are issued to them, Relying Parties (RPs) must be able to verify their signatures during token validation. However, as of today, most JWT libraries used for token validation do not yet support post-quantum signatures.

The table below shows a snapshot as of October 2026 of JWT libraries and their support for JWTs secured with ML-DSA for some popular programming languages.

Crypto Agility for a Smooth Post-Quantum Transition

A practical post-quantum transition strategy should rely on leveraging existing protocol mechanisms and metadata structures enabling cryptographic agility.

While parameters like id_token_signed_response_alg originated in OpenID Connect Dynamic Client Registration, client metadata has come to serve as a general configuration data model across OAuth and OIDC (a concept reinforced in RFC 9126, Section 6). Regardless of whether an RP uses dynamic registration or static administrative configuration, this metadata establishes the baseline cryptographic capabilities and functional intent for each client.

By implementing per-RP signature algorithm controls grounded in this metadata model, OPs and RPs can manage the post-quantum rollout incrementally:

• Gradual RP Migration: OPs can allow individual RPs to update their configured id_token_signed_response_alg to post-quantum algorithms (such as ML-DSA-44) as their software, dependencies, and local policy are upgraded. They can then update algorithm(s) accepted at runtime, so that only PQ-safe signatures are accepted. 
• Coexistence in Heterogeneous Environments: Per-RP metadata enables upgraded RPs to receive PQ-signed ID Tokens while legacy RPs continue using classical algorithms (like RS256 or ES256) during the larger migration window.  Per-Redirection URI algorithms are also a possible approach.
• Policy Enforcement & Deprecation: As PQ adoption matures, OPs can begin to mandate post-quantum algorithms and eventually phase out classical options. In the interim, the rotation interval of the keys for classical algorithms can be accelerated to offset the emergent risk as the cryptographic relevance of quantum computers advances.

Grounding client management in existing metadata constructs provides a clear operational model today, giving the flexibility to transition RPs at their own pace as both configuration management and runtime protocol capabilities evolve.

Conclusion

The transition to post-quantum OpenID Connect requires a coordinated effort across libraries, services, RPs, and OPs. Libraries and services must implement support for post-quantum signatures and fix bugs that are triggered by the adoption of post-quantum signature algorithms. Vendors and RPs must update to the latest versions of these libraries and test systems.  The OpenID Connect Working Group and the OpenID Foundation are actively considering what best practices and practical steps implementations and deployments can use to ease the transition to post-quantum cryptography.

About the OpenID Foundation

The OpenID Foundation (OIDF) is a global open standards body committed to building trusted identity ecosystems. Our mission is to lead the global community in identity standards that are secure, interoperable, and privacy respecting. Founded in 2007, we are a community of technical experts. The Foundation's OpenID Connect standard is now used by billions of people across millions of applications. More recently, the FAPI security profile - built on OAuth 2.0 - has become the standard of choice for interoperable Open Banking and Open Data implementations, while OpenID for Verifiable Credentials specifications are underpinning a new generation of digital wallets. Today, the OpenID Foundation's standards are the connective tissue that enable people to assert their identity and access their data at scale, the scale of the Internet, enabling "networks of networks" to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.