SAML single sign-on: verify signed assertions without losing the identity boundary

This guide uses SAML 2.0 Web Browser SSO with HTTP POST delivery and service-provider-initiated login. An identity provider authenticates a person; the service provider validates the response and establishes its own session. A browser carrying XML does not make that XML trusted. Keep issuer onboarding, message validation and local account authorization as separate decisions.

For this worked application, require a signed Response and signed authentication Assertion, accept one configured bearer confirmation and reject unsolicited responses. Requiring both signatures is this deployment’s restrictive contract. Do not silently weaken an established profile because an integration sends a different shape; resolve supported behavior during onboarding and test the exact library configuration.

Use a maintained SAML/XML signature implementation with hardened XML parsing, bounded input and local schemas. Disable external entity resolution and unapproved remote references. Reject duplicate IDs and ambiguous assertion selection. Schema validation and signature validation are different checks; successful parsing establishes neither issuer trust nor an authenticated user.

Signature wrapping exploits disagreement between the verifier and the consumer: a signature validates Assertion A1 while application XPath reads an unsigned A2. Consume the validated assertion object returned by the library. Do not verify a document, parse it again with a different routine and select the first element named Assertion. Record the signed reference and consumed element in a controlled regression fixture.

Trust comes from the tenant’s enrolled issuer and signing-key configuration. An embedded KeyInfo certificate is candidate key material, not permission to create accounts. A certificate chaining to a familiar public CA also does not establish that it is the configured identity provider’s SAML signing key.

Each of these advisories let an attacker change the identity or attributes that a service provider accepted from a signed SAML message, or read encrypted content. Most are the failure described above: the code that verified the signature and the code that read the identity disagreed about which XML they were looking at. Check your dependency tree, including libraries such as omniauth-saml or passport-saml that pull these in.

Validate the expected issuer, successful response status and configured Destination. For bearer confirmation, check Recipient against the actual assertion consumer service URL, its NotOnOrAfter cutoff, and InResponseTo against the outstanding login request. Bind that request to the initiating browser and tenant; expire and consume it. For this SP-initiated profile, an unknown request is denied.

Evaluate assertion Conditions separately from subject confirmation. NotOnOrAfter is an exclusive cutoff. Define and test clock skew rather than accepting an arbitrary time extension. In SAML audience restrictions, audiences inside one restriction are alternatives, while multiple restrictions must all be satisfied. The SP entity ID is an identity identifier; it is not interchangeable with the ACS URL.

A valid assertion is still a bearer credential. Atomically record its used ID and consume the correlated request before creating the session. Keep replay state for the full possible acceptance interval, including configured skew. Multiple application instances need a shared decision; independent in-memory sets let the same response establish multiple sessions.

The library verifies signatures, audience, time conditions and InResponseTo, and since 5.1.0 it reads only the verified assertion. Two checks remain yours: node-saml applies idpIssuer only to logout messages, and it does not check the bearer confirmation’s Recipient, so the handler checks both. It was tested with node-saml 5.1.0 and xml-crypto 6.3.2 on Node.js 26 against responses signed locally with RSA-SHA256: a solicited response succeeds once, and a replay, an unsolicited or unknown request ID, an unenrolled signing key, a NameID changed after signing, an extra unsigned assertion, another audience, another issuer, an expired assertion and another endpoint are all rejected. The same test shows the library default accepting an unsolicited response.

import {SAML, ValidateInResponseTo} from '@node-saml/node-saml';

const ACS_URL = 'https://billing.example/saml/acs';

// One instance per enrolled tenant, built from the values agreed at onboarding.
export function samlFor(tenant, sharedCache) {
  return new SAML({
    callbackUrl: ACS_URL,
    issuer: 'urn:example:billing', // this service provider's entity ID
    audience: 'urn:example:billing',
    entryPoint: tenant.ssoUrl,
    idpCert: tenant.signingCerts, // pinned at onboarding; never trust KeyInfo in the message
    wantAuthnResponseSigned: true,
    wantAssertionsSigned: true,
    validateInResponseTo: ValidateInResponseTo.always, // the default, "never", accepts unsolicited responses
    requestIdExpirationPeriodMs: 5 * 60_000,
    cacheProvider: sharedCache, // shared by every instance, so each request ID is consumed once
    acceptedClockSkewMs: 0,
    signatureAlgorithm: 'sha256',
  });
}

// POST /saml/acs. Every value comes from the assertion the library verified.
export async function acs(saml, tenant, body) {
  const {profile} = await saml.validatePostResponseAsync({SAMLResponse: body.SAMLResponse});
  // node-saml checks idpIssuer only on logout messages and never checks Recipient: do both here.
  if (profile.issuer !== tenant.idpEntityId) throw new Error('assertion from an unexpected issuer');
  const confirmations = profile.getAssertion().Assertion.Subject[0].SubjectConfirmation;
  if (!confirmations.some(c => c.SubjectConfirmationData?.[0]?.$?.Recipient === ACS_URL))
    throw new Error('assertion was issued for another endpoint');
  return {issuer: profile.issuer, nameID: profile.nameID, format: profile.nameIDFormat};
}

For this product, the mapping key contains enrolled tenant, issuer and the configured NameID identifier semantics, including relevant qualifiers. An email attribute is display/contact data unless an explicit verified linking process says otherwise. The same email at two tenants must not merge their accounts. An issuer-provided group string becomes a local grant only through an approved mapping.

Check that the local account remains active after SAML validation. Disabling a user in provisioning, which the SCIM guide at /domains/identity-crypto/authentication/scim-provisioning-deprovisioning/ covers, must not be undone by an older login assertion or just-in-time account creation. Store the selected local account ID in the session and rotate the browser session identifier, as the session guide at /domains/identity-crypto/authentication/session-lifecycle/ describes. Treat RelayState as an opaque, browser-bound lookup into an allowed local destination; it is not a trusted arbitrary redirect URL.

An onboarding checklist should identify entity IDs, ACS endpoints, signing algorithms, signing keys, metadata ownership and refresh rules. Planned key rollover needs a controlled overlap and tests for both keys. A compromise requires removal of affected trust and review of sessions already created; merely changing the IdP’s current signer leaves other accepted keys and sessions untouched.

Use redacted event records with correlation ID, tenant, configured issuer, validation stage and reason. Avoid logging complete SAML responses, session cookies or sensitive attributes. Keep a test account and a deliberate failure matrix for each supported IdP configuration. A real integration test must execute the selected SAML library against signed XML; the supplied trace below deliberately starts after cryptographic verification.

Library versions are part of the trust configuration. Record the SAML and XML-signature packages each service uses, their minimum safe versions from the table above, and who upgrades them when a new advisory appears.

• Subscribe to advisories for every SAML and XML-signature package you use, through Dependabot, OSV or your scanner.
• Keep regression fixtures of real signed responses, including published attack payloads, and run them against every library upgrade.
• Reject documents that contain more than one Assertion or a DOCTYPE, before any signature processing.
• Treat an IdP built on a SAML library as part of your attack surface too: CVE-2026-46490 let users inject attributes that the IdP signed.

The baseline below is accepted only when every row remains true. A failing identity-binding check must prevent session creation even if cryptography succeeds. A current-authority failure can reject a perfectly valid SAML response without implying that its signature is broken.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OASIS SAML 2.0 Profiles — Web Browser SSO processing. OASIS Standard, 15 March 2005.
2. OASIS SAML 2.0 Core — Conditions and audience restrictions. OASIS Standard, 15 March 2005.
3. OWASP SAML Security Cheat Sheet — parsing and signature wrapping
4. OASIS SAML 2.0 Security and Privacy Considerations. OASIS Standard, 15 March 2005.
5. GitHub Security Lab: bypassing SAML authentication with parser differentials (March 2025)
6. PortSwigger Research: The Fragile Lock, novel bypasses for SAML authentication (December 2025)
7. GitHub Advisory Database: node-saml CVE-2025-54369
8. node-saml documentation and options

Reference information

SAML 2.0 OASIS specifications. The linked identity-lifecycle project models normalized lifecycle events, not SAML parsing.

Tags

Authentication and sessionsSAML, SCIM and enterprise SSO

SDLC phase

Development

Role

Developers

ASVS 5.0.0 requirements

v5.0.0-6.8.1 · v5.0.0-6.8.2 · v5.0.0-6.8.3

Download this guide as Markdown

Continue exploring