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 and SLH-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 10x to 100x larger signatures + 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. Some OpenID Connect RPs may not be able to upgrade all of their client software to post-quantum algorithms at once and may need a way of selecting what algorithm is used to sign an ID Token when that ID Token is requested.

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.

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. SLH-DSA-*-128s has 7,856 byte signatures! 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.

One such example is the maximum cookie size of ~4kB. Although the ~4 kB figure is technically a minimum that browsers must support according to IETF RFC 6265, in practice many systems treat it as a hard maximum. Therefore, going over this threshold risks breaking functionality. If a cookie exceeds this size, it may be silently dropped. An application relying on the token stored in this cookie may therefore not receive the token at all and thereby lose crucial authenticity provided by it.

We must start auditing browsers and other software that we rely on, for potential breaking issues caused by these size increases and update them to accommodate the increased sizes.

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.

Bugs caused by protocol ossification have already surfaced in OpenID Connect. 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. What should happen is that the library ignores the JWK it does not know how to handle and continues 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 a huge problem when 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 blocks or bugs now so they don’t delay the post-quantum transition in the future.

Support for New Algorithms

Before post-quantum secure tokens are issued to them, RPs and other token verifying services behind them 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 current snapshot of JWT libraries and their support for JWTs secured with ML-DSA for the five most popular programming languages as reported by GitHub for Octoverse 2025 as well as Go and Rust.

Crypto Agility for a Smooth Post-Quantum Transition

A related concern is not with the general feasibility of post-quantum OpenID Connect, but instead with the transition process towards post-quantum cryptography. This is primarily driven by the need for RPs to support multiple signature schemes at the same time. For instance, imagine an RP that has two different services consuming the ID Tokens, a legacy service and a more modern service. While maintainers might be able to rapidly update the modern service to support post-quantum signatures, the legacy service may take more time and testing. Here it would be helpful if the RP could support ML-DSA-44 and a classical algorithm like RS256 at the same time such that maintainers can move the modern service over first, fix any problems they encounter and then update the legacy service. In such scenarios, RPs must be able to decide whether they want to receive tokens signed with ML-DSA-44 or RS256. Naturally, ML-DSA-44 is the favorable choice after Q-Day, but RPs may use RS256 with sufficiently fast rotation for compatibility reasons.

If supported by the OP, an RP can specify what algorithm must be used to sign tokens issued to it via the id_token_signed_response_alg registration parameter. However, it only allows a single algorithm, making the RP algorithm choice all-or-nothing. Additionally, this parameter is set during registrations, i.e. it can’t be changed on the fly. RPs that want a more gentle transition would need a way to specify more than one algorithm and to select which algorithm should be used to sign a token on a request-by-request basis.  Additional standards work would be needed to achieve this.

Conclusion

The transition to post-quantum OpenID Connect requires a coordinated effort across libraries, RPs, and perhaps even the OpenID Connect standard itself. Libraries 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. We must consider introducing additional algorithm agility mechanisms to OpenID Connect to lower the risks and complexity of the switch.

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.