<p>Identity infrastructure sits at the boundary of most enterprise security models. Authentication assertions from a compromised IdP do not just affect one application. For IAM engineers and security architects working through a post-quantum migration programme, SAML and OIDC warrant careful attention, but the risk model differs from long-lived data encryption in ways that should inform how urgently you sequence this work. This article covers where the quantum vulnerability sits, what algorithm migration technically requires, where the major commercial providers stand, and what options you have if you cannot wait for vendor GA support.</p>

<p>For foundational context on what post-quantum digital signatures are and why RSA and ECDSA fail against a CRQC, see <a href="/quantum-news/digital-signatures-post-quantum-explainer-non-technical/">Post-Quantum Digital Signatures: A Non-Technical Explainer</a>. For the distinction between post-quantum cryptography and quantum key distribution, see <a href="/quantum-news/post-quantum-vs-quantum-cryptography-difference/">Post-Quantum vs Quantum Cryptography: What Is the Difference</a>.</p>

<h2>Where SAML and OIDC are quantum-vulnerable</h2>

<p>SAML 2.0 uses XML Digital Signatures (XMLDSig, W3C Recommendation) for signing authentication assertions and responses. Current SAML deployments predominantly rely on RSA with SHA-256 (rsa-sha256) for the signing algorithm. RSA-PSS with SHA-256 is the currently recommended variant. ECDSA with P-256 (ecdsaWithSHA256) is less common but present in some deployments. All three are quantum-vulnerable: RSA to Shor's algorithm via polynomial-time integer factoring, ECDSA P-256 to Shor's algorithm via polynomial-time discrete logarithm on elliptic curves.</p>

<p>OIDC, built on OAuth 2.0, uses JSON Web Signatures (JWS, RFC 7515) to sign ID tokens and in some flows access tokens. The JWS algorithm identifier in the JOSE header determines the signing algorithm. RS256 (RSA-PKCS1-v1.5-SHA256) is the OIDC default and most widely deployed. PS256, PS384, PS512 (RSA-PSS variants) are the recommended alternatives. ES256, ES384, ES512 (ECDSA with NIST curves) are common in modern deployments. Every RSA and ECDSA variant in this list is quantum-vulnerable on the same basis as their SAML equivalents.</p>

<p>The HNDL risk for token signing differs from long-lived data encryption. OIDC ID tokens have validity windows typically of one hour or less. SAML authentication assertions carry a <code>NotOnOrAfter</code> attribute, often set to 5 to 60 minutes. Short-lived tokens captured in transit cannot be replayed after the validity window closes. The primary threat is not token replay. It is signing key compromise: if a CRQC can recover the IdP's RS256 private key from intercepted traffic, the attacker can forge arbitrary new tokens, not just replay captured ones. The signing key is the critical asset, not the individual tokens.</p>

<p>This distinction matters operationally. Protecting the signing key at rest (HSM-backed key storage) and in transit (post-quantum TLS on the token endpoint) reduces the risk without requiring PQC algorithm migration of the token signatures themselves. For most enterprise deployments, transport layer migration provides the greater HNDL protection in the near term.</p>

<h2>What PQC algorithm migration requires technically</h2>

<p>Migrating OIDC token signing to ML-DSA requires three things: a new JWS algorithm identifier registered for ML-DSA; IdP support for ML-DSA signing of ID tokens; and relying party library support for ML-DSA JWS verification. The IETF JOSE working group is standardising these algorithm identifiers through draft-ietf-jose-pqc-kem and draft-ietf-jose-fully-specified-algorithms. Proposed identifiers follow the FIPS 204 parameter set naming: ML-DSA-44, ML-DSA-65, ML-DSA-87. Until IANA registration of these identifiers is complete, PQC OIDC token signing is not interoperable between arbitrary clients and servers. An application that implements PQC JOSE signing today uses draft identifiers that may change when the RFC publishes, requiring another update cycle.</p>

<p>SAML's migration path is less mature. XMLDSig uses W3C-defined algorithm URIs rather than an IANA registry. The <code>&lt;ds:SignatureMethod Algorithm="..."&gt;</code> element requires a URI identifying the signing algorithm. As of August 2025, no W3C XMLDSig PQC algorithm URI had been standardised. SAML federations migrating to ML-DSA early must coordinate on a provisional URI and plan to update it when a standard URI is published. The operational complexity of propagating that URI change across all service providers in a large SAML federation is not trivial.</p>

<p>The ML-DSA-65 parameter set (NIST FIPS 204) produces signatures of 3,309 bytes, compared to 64 bytes for ECDSA P-256. The size increase has implications for SAML assertion payloads and OIDC ID token sizes, though these are typically transmitted over HTTPS where size overhead is modest relative to other factors. ML-DSA-65 public keys are 1,952 bytes; ECDSA P-256 public keys are 64 bytes. JWKS endpoints and SAML metadata documents will grow correspondingly.</p>

<h2>JWKS and SAML metadata: how keys are distributed</h2>

<p>OIDC identity providers publish their public signing keys via JWKS (JSON Web Key Set, RFC 7517) at a well-known endpoint, referenced from the OpenID Provider Configuration at <code>/.well-known/openid-configuration</code>. Relying parties poll this endpoint to refresh key material. A PQC OIDC migration requires adding ML-DSA public key entries to the JWKS document, using the new key type and algorithm values from the PQC JOSE drafts. During transition, both classical RSA or ECDSA keys and ML-DSA keys should appear in the JWKS document simultaneously, so that relying parties that have not yet updated their JOSE libraries can continue verifying tokens. OIDC's JWKS polling mechanism already handles rolling key rotation; adding PQC keys alongside classical keys follows the same operational pattern.</p>

<p>SAML metadata distribution works differently. The SAML metadata document (defined in the OASIS SAML 2.0 Metadata specification) carries the IdP's signing certificate as an X.509 certificate in the <code>&lt;md:KeyDescriptor&gt;</code> element. Service providers cache this metadata. Migrating SAML to ML-DSA requires an ML-DSA X.509 certificate for the IdP signing key, distribution of that certificate to all SPs in the federation via metadata exchange, and SP XML signature validation library updates to support ML-DSA. ML-DSA OIDs for X.509 certificates are being defined in IETF draft-ietf-lamps-pqc-certificates. Until public certificate authorities issue ML-DSA certificates, SAML federations migrating early must use self-signed or privately signed ML-DSA certificates. Federation metadata distribution across large multi-SP deployments (Microsoft 365, Salesforce, Workday, and similar) is slower and operationally heavier than the OIDC JWKS polling approach.</p>

<h2>What the major identity providers support today</h2>

<p>As of August 2025, none of the major commercial IdP platforms had released generally available ML-DSA signing support. The status across the main platforms:</p>

<p><strong>Okta</strong> (Workforce Identity Cloud and Customer Identity Cloud): token signing via RS256 (default), PS256, and ES256. No documented GA PQC signing algorithm support. Okta's cryptographic agility roadmap was aligned with monitoring IETF JOSE PQC draft progression. [ASSUMED: verify current Okta release notes before deployment planning.]</p>

<p><strong>Auth0</strong> (Okta's developer platform): RS256, PS256, RS384, ES256 for OIDC token signing; RS256 for SAML assertion signing. No PQC GA support documented. Auth0 rotates tenant signing keys automatically every 60 days by default. That rotation infrastructure could extend to PQC key types without protocol changes, once ML-DSA key support is added to the signing backend. [ASSUMED: verify current Auth0 documentation.]</p>

<p><strong>Microsoft Entra ID</strong> (formerly Azure Active Directory): RS256 for OIDC token signing by default, PS256 available. Microsoft published its PQC migration strategy in September 2024, confirming alignment with NIST FIPS 203, 204, and 205, with a phased migration roadmap. No documented GA ML-DSA token signing for Entra ID OIDC or SAML as of August 2025. Entra ID is also the primary IdP for enterprise SAML federation serving Microsoft 365 deployments, adding organisational scale to the migration surface. [ASSUMED: verify at Microsoft Entra documentation.]</p>

<p>The common dependency across all vendors is IETF JOSE PQC algorithm identifier stabilisation. Commercial IdP platforms will not release GA ML-DSA signing against unstable draft identifiers. A breaking draft-to-RFC identifier change would require an emergency update cycle for every token-consuming relying party, a risk no enterprise product team will accept. The IANA registration of stable algorithm identifiers is the practical unblocking event for commercial GA.</p>

<h2>Three options for organisations that cannot wait</h2>

<p>Most enterprise IAM teams will wait for commercial IdP GA support. For organisations with a compliance deadline, a regulatory mandate, or an elevated threat profile, three options are available.</p>

<p><strong>Option A: Deploy an open-source IdP with a PQC-capable backend.</strong> Keycloak (Red Hat / community), Hydra (ORY), and Dex support pluggable signing algorithm backends. A Keycloak deployment backed by a liboqs JOSE library can implement ML-DSA token signing ahead of commercial IdP support. This approach requires owning the operational complexity of a self-hosted IdP and accepting that algorithm identifiers may require an update when JOSE PQC RFCs are finalised.</p>

<p><strong>Option B: Migrate the transport layer now and defer token signing.</strong> Post-quantum TLS on the token endpoint, the JWKS endpoint, and the SAML metadata exchange channel protects key material in transit without touching the signing algorithm. For the near-term HNDL exposure, this is the higher-impact move. OIDC ID tokens are short-lived and have limited replay value. The IdP signing key, protected in an HSM with hybrid TLS on all access paths, has the most concentrated risk. Option B addresses that risk within reach of current tooling.</p>

<p><strong>Option C: Wait for commercial IdP GA support aligned with finalised IETF JOSE PQC algorithm identifiers.</strong> For most enterprise deployments with RSA-signed tokens in a well-protected HSM, this is the proportionate choice. Document the decision, the risk accepted, and the trigger criteria for migration when vendor GA support arrives.</p>

<h3>OIDC versus SAML: which migrates first</h3>

<p>OIDC has a structurally cleaner PQC migration path than SAML, and vendor GA support for OIDC PQC signing will arrive before SAML support. The reasons are technical:</p>

<table>
  <thead>
    <tr>
      <th>Factor</th>
      <th>SAML</th>
      <th>OIDC</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Signing mechanism</td>
      <td>XMLDSig</td>
      <td>JWS</td>
    </tr>
    <tr>
      <td>Algorithm specification</td>
      <td>W3C XML URI (no PQC URI standardised)</td>
      <td>IANA "alg" identifier (PQC drafts active)</td>
    </tr>
    <tr>
      <td>Key distribution</td>
      <td>X.509 in metadata federation</td>
      <td>JWKS endpoint polling</td>
    </tr>
    <tr>
      <td>Migration complexity</td>
      <td>Higher</td>
      <td>Lower</td>
    </tr>
    <tr>
      <td>Expected vendor GA timing</td>
      <td>Later</td>
      <td>Earlier</td>
    </tr>
  </tbody>
</table>

<p>Organisations running both protocols should plan for OIDC-based application migrations to follow vendor GA sooner than SAML federation migrations, particularly for older enterprise SAML federations serving Microsoft 365, Salesforce, and Workday. That sequencing is worth building into migration roadmaps now.</p>