Post-Quantum Migration: Which Algorithm Path Fits Your OpenID Connect Deployment?

Your OpenID Connect infrastructure will need post-quantum signatures. The question isn't whether to migrate, it's which migration path matches your current constraints and risk tolerance.

The Decision You're Facing

You're choosing between three migration approaches for post-quantum cryptography in OpenID Connect:

1. Immediate full cutover to ML-DSA or SLH-DSA across all relying parties
2. Phased migration supporting both classical and post-quantum algorithms during transition
3. Wait-and-monitor until library support and tooling mature

Each path carries distinct trade-offs in risk exposure, operational complexity, and resource requirements. Your choice depends on four factors that directly affect feasibility.

Key Factors That Affect Your Choice

Library ecosystem maturity. Most JWT libraries don't yet support post-quantum signatures. As of early 2025, only Microsoft IdentityModel (C#/.NET), jose (Node.js), lestrrat-go/jwt (Go), and jose-rs (Rust) have implemented ML-DSA support. If your stack relies on Auth0's jsonwebtoken, PyJWT, or firebase/php-jwt, you're waiting on upstream maintainers.

Size tolerance in your deployment. RS256 produces 256-byte signatures. ML-DSA-44 produces 2,420-byte signatures, nearly 10x larger. After Base64url encoding, ID tokens can easily exceed the 4 KB cookie size limit that browsers enforce. If you store tokens in cookies or pass them through systems with hard size constraints, you'll hit breaking points.

Client diversity and upgrade control. Can you update all relying parties simultaneously, or do you operate a mix of modern services and legacy systems? If you control the entire client fleet and deployment pipeline, coordinated cutover becomes viable. If third-party integrations or embedded clients exist in your ecosystem, you need algorithm flexibility.

Quantum threat timeline vs. operational risk. Q-Day, the point when quantum computers can break RSA and ECDSA, remains years away. But "harvest now, decrypt later" attacks are already happening. You're balancing the urgency of quantum resistance against the operational risk of deploying immature cryptographic implementations.

Path A: Immediate Full Cutover

Choose this path when:

• You control all relying parties and can coordinate deployment windows
• Your JWT library already supports ML-DSA (check the support matrix above)
• You've tested token size limits across your infrastructure and confirmed headroom
• Your risk model prioritizes quantum resistance over short-term compatibility

Implementation steps:

Set id_token_signed_response_alg to ML-DSA-44 during client registration. Update your JWKS to publish ML-DSA public keys. Deploy updated libraries to all token-validating services in a single maintenance window.

Critical pre-flight checks:

Audit cookie storage, URL parameters, and HTTP headers for size constraints. A 2,420-byte signature becomes roughly 3,227 bytes after Base64url encoding. Add overhead for claims, headers, and separators, you're looking at 4-5 KB minimum for even basic ID tokens.

Test JWKS parsing behavior. The bug Ralph Bragg identified affects libraries that fail when encountering unknown key types like AKP (used for ML-DSA). If your library throws errors on unrecognized JWKs instead of skipping them, you can't publish hybrid JWKS during transition.

When this path fails:

You discover size limits during production rollout. A legacy service can't parse tokens. A third-party integration breaks because their library doesn't support ML-DSA. Rollback becomes your only option, and you've burned credibility with stakeholders.

Path B: Phased Migration with Algorithm Flexibility

Choose this path when:

• You operate heterogeneous client environments (SaaS integrations, mobile apps, legacy services)
• You need to test post-quantum signatures with a subset of relying parties first
• Your risk tolerance allows gradual transition over quarters, not weeks
• You can influence or contribute to OpenID Connect standards work

Implementation challenge:

The id_token_signed_response_alg parameter accepts only one algorithm and can't change per-request. You need a mechanism to specify algorithm preference dynamically, something the current OpenID Connect specification doesn't provide.

Workaround options:

Issue separate client IDs for modern vs. legacy services. Register your modern client with ML-DSA-44, your legacy client with RS256. Route authentication requests based on client capabilities. This doubles your registration overhead but gives you per-service algorithm control.

Negotiate with your OpenID Provider vendor for custom extensions. Some enterprise identity platforms allow request-time algorithm selection through proprietary parameters. Document this dependency for future migration.

Contribute to standards development. The OpenID Foundation is aware of this gap. If your organization has the resources, participate in working groups to define multi-algorithm support and request-time selection.

Migration sequence:

1. Deploy ML-DSA support to a canary service with full observability
2. Monitor for parsing failures, size-related errors, and performance degradation
3. Expand to additional services in cohorts based on criticality
4. Maintain RS256 for long-tail integrations until library support improves
5. Deprecate classical algorithms only after quantum threat becomes imminent

When this path fits:

You're managing enterprise-scale deployments where a single breaking change affects hundreds of integrations. You have the operational maturity to run dual-algorithm infrastructure. You're comfortable with extended transition timelines.

Path C: Wait and Monitor

Choose this path when:

• Your JWT library has no ML-DSA support and no timeline for implementation
• You've identified size constraints that would require infrastructure redesign
• Your threat model doesn't prioritize quantum resistance in the near term
• You lack resources for testing and validation of post-quantum implementations

Active monitoring requirements:

Track library adoption monthly. When your primary JWT library ships ML-DSA support, begin planning. Monitor NIST post-quantum standardization for algorithm changes or deprecations. Watch for JWKS parsing bugs in your stack, these will block future migration even if you're not ready today.

Audit size limits now. Even if you're not migrating yet, document every place tokens flow through size-constrained channels. This becomes your migration blockers list.

Risk acceptance:

You're explicitly accepting quantum vulnerability until migration becomes feasible. Document this in your risk register. If you handle high-value authentication (financial services, healthcare, government), this path may not satisfy regulatory expectations.

When this path makes sense:

You're operating internal systems with limited external exposure. You're a small team without bandwidth for experimental deployments. You're waiting for ecosystem maturity before committing resources.

Summary Matrix

Factor	Path A: Immediate	Path B: Phased	Path C: Wait
Library support	Already available	Available for subset	Not yet available
Size constraints	Validated headroom	Manageable with redesign	Blocking issues
Client control	Full control	Mixed environment	Limited control
Timeline	Weeks	Quarters	12+ months
Quantum risk tolerance	Low	Medium	Higher
Operational complexity	Single deployment	Dual-algorithm ops	Deferred

The post-quantum transition isn't a binary switch. It's a phased infrastructure upgrade that requires honest assessment of your current constraints. Choose the path that matches your actual capabilities, not your aspirational roadmap.