A SAML assertion is a digitally signed XML document that an identity provider (IdP), such as Okta or Microsoft Entra ID, sends to a service provider (SP) to state who a user is, when and how they authenticated, and which attributes they carry. The SP trusts the assertion instead of asking for a password. That exchange is what makes SAML single sign-on (SSO) work.
Assertions are defined by the SAML 2.0 OASIS Standard, approved on March 1, 2005 and still the current version in 2026. In a browser login, the assertion travels inside a SAML Response, is valid for only a few minutes, and is safe only if the SP verifies its signature, audience, recipient, and time window.
SAML assertion at a glance
| Question | Answer |
|---|---|
| SAML full form | Security Assertion Markup Language |
| Current version | SAML 2.0 (OASIS Standard, March 2005; also approved as ITU-T X.1141) |
| Format | XML, signed with W3C XML Signature, optionally encrypted |
| Who creates it | Identity provider, called the asserting party |
| Who consumes it | Service provider, called the relying party, at its Assertion Consumer Service (ACS) URL |
| How it travels in browser SSO | Inside a <samlp:Response>, over the HTTP-POST or HTTP-Artifact binding |
| Statement types | Authentication, Attribute, Authorization Decision (frozen since SAML 2.0) |
| Typical validity window | Minutes; the OASIS reference example uses 5 minutes |
| Built-in revocation | None; short lifetimes and Single Logout end access |
| Main 2026 risk | SP libraries that skip signature checks (2026 CVEs rated up to 9.8 Critical) and stolen IdP signing keys (Golden SAML) |
What is inside a SAML assertion?
Every SAML assertion has a root <saml:Assertion> element and up to six child elements, which must appear in a fixed order set by the SAML 2.0 Core specification. A validating parser rejects an assertion whose children are out of order, so hand-built samples that put <Conditions> before <Subject> will fail.
| Order | Element | Required? | What it carries | What the SP does with it |
|---|---|---|---|---|
| Root | ID, Version, IssueInstant attributes | Yes | Unique ID, “2.0”, UTC creation time | Stores the ID to block replays; checks the timestamp |
| 1 | <Issuer> | Yes | IdP entity ID, e.g. https://idp.example.org/SAML2 | Matches it to the trusted IdP in metadata |
| 2 | <ds:Signature> | Optional in schema; required when the Response carrying it is not signed | XML digital signature and signing certificate | Verifies it with the IdP certificate stored locally |
| 3 | <Subject> | Optional in schema; required for web SSO | NameID (user identifier) and SubjectConfirmation | Identifies the user; checks Recipient, InResponseTo, NotOnOrAfter |
| 4 | <Conditions> | Optional in schema; always used in practice | NotBefore, NotOnOrAfter, AudienceRestriction | Rejects the assertion outside the window or for another audience |
| 5 | <Advice> | Optional | Supporting evidence, rarely used | Usually ignored |
| 6 | Statements | Zero or more | AuthnStatement, AttributeStatement, AuthzDecisionStatement | Creates the session and maps roles |
Look Further: What Is SAML? How SAML Works, How SAML Is Used, and Where It Breaks
What is a NameID in a SAML assertion?
The NameID is the identifier the IdP uses for the user at that SP. SAML 2.0 predefines formats including email address, X.509 subject name, Kerberos principal, persistent, and transient. Persistent and transient formats are privacy-preserving pseudonyms, so the SP never sees the user’s real IdP username.
What is an encrypted SAML assertion?
An <EncryptedAssertion> wraps the whole assertion with XML Encryption using the SP’s public key. Only the SP’s private key can decrypt it. Encryption protects attribute privacy when the assertion passes through the browser; it does not replace signature validation.
What are the 3 types of SAML assertion statements?
SAML 2.0 defines three statement types, but only two carry weight in modern SSO. The third, the Authorization Decision statement, has been frozen since SAML 2.0 with no enhancements planned, and the specification points implementers who need richer authorization to XACML instead.
| Statement | XML element | What it proves | Example content | Use in 2026 |
|---|---|---|---|---|
| Authentication | <saml:AuthnStatement> | The user logged in at the IdP, when, and how | AuthnInstant, SessionIndex, AuthnContextClassRef such as PasswordProtectedTransport | Present in every SSO assertion |
| Attribute | <saml:AttributeStatement> | Facts about the user | email, first name, department, groups, role | Standard; drives role mapping and just-in-time provisioning |
| Authorization Decision | <saml:AuthzDecisionStatement> | Permit, Deny, or Indeterminate for one resource and action | Resource, Decision, Action | Frozen; almost never emitted by major IdPs |
How does an assertion show MFA was used?
The AuthnContextClassRef inside the Authentication statement names the login method. Standard class URIs are listed in the SAML 2.0 Authentication Context specification. An SP that requires MFA should request a specific class in its AuthnRequest and reject assertions that report a weaker one.
Check the full guide: What Is SAML Authentication? How It Works, With Examples
What does a SAML assertion example look like?
The sample below follows the schema order from the Core specification, uses RSA-SHA256, and mirrors the timing of the OASIS reference flow: a 5-minute validity window for a bearer assertion. Signature values are shortened.
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
Version="2.0"
IssueInstant="2026-09-25T14:02:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>q9FfB2...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>kX1pC7...</ds:SignatureValue>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
priya.shah@example.com
</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="_req-4f1c9e"
Recipient="https://app.example.com/saml/acs"
NotOnOrAfter="2026-09-25T14:07:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2026-09-25T14:01:35Z"
NotOnOrAfter="2026-09-25T14:07:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://app.example.com/saml/metadata</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2026-09-25T14:02:00Z"
SessionIndex="_sess-8b2e">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>priya.shah@example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="groups">
<saml:AttributeValue>finance-admins</saml:AttributeValue>
<saml:AttributeValue>all-staff</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>| Field in the example | Value | Why it matters |
|---|---|---|
| ID | _a75adf55-… | The signature Reference URI points to this ID; the SP caches it to reject replays |
| SignatureMethod | rsa-sha256 | The SP must enforce its own configured algorithm, not the one named here |
| Recipient | https://app.example.com/saml/acs | Must equal the SP’s own ACS URL |
| InResponseTo | _req-4f1c9e | Must match the ID of the AuthnRequest the SP sent; absent in IdP-initiated SSO |
| NotBefore | 30 seconds before issue | Small backdate that tolerates clock skew |
| NotOnOrAfter | 5 minutes after issue | After this time the assertion is dead |
| Audience | SP entity ID | Stops an assertion minted for one app from working on another |
| groups attribute | Two values | One attribute can carry several values; map them to roles |
What is the difference between a SAML assertion and a SAML response?
A SAML response is the envelope; the SAML assertion is the signed letter inside it. The response carries protocol data such as status and destination, while the assertion carries the identity claims the SP acts on. A SAML request is the SP’s message that starts the exchange.
| SAML request | SAML response | SAML assertion | |
|---|---|---|---|
| XML element | <samlp:AuthnRequest> | <samlp:Response> | <saml:Assertion> |
| Namespace | protocol (samlp) | protocol (samlp) | assertion (saml) |
| Sent by | SP to IdP | IdP to SP | Carried inside the response |
| Purpose | “Please authenticate this user” | Delivers the result and status | States who the user is and what is true about them |
| Key fields | ID, Issuer, AssertionConsumerServiceURL, NameIDPolicy | InResponseTo, Destination, Status | Subject, Conditions, statements |
| Browser bindings | HTTP-Redirect, HTTP-POST, or HTTP-Artifact | HTTP-POST or HTTP-Artifact only | Travels with the response |
| Can hold | Nothing else | One or more assertions, or an error status with none | Three statement types |
The HTTP-Redirect binding is never used for the Response, per the OASIS SAML 2.0 Technical Overview. Redirect URLs are length-limited, and signed assertions are too large.
Should the IdP sign the SAML response or the assertion?
With the HTTP-POST binding, each assertion must be protected by a signature, either on the assertion itself or on the enclosing Response. Signing the assertion is the safer default because the proof stays attached if the assertion is extracted and processed alone. Microsoft Entra ID, for example, lets admins sign the response, the assertion, or both (Microsoft Learn). Whatever the setting, the SP must verify that the signature it checked actually covers the assertion it reads.
How does a SAML assertion move through a SAML SSO login?
SAML SSO is the login pattern in which one IdP authenticates the user and every connected app accepts that IdP’s assertion instead of its own password prompt. SAML authentication is the same process viewed from the app: the SP authenticates the user by validating the assertion. The common SP-initiated flow takes 6 steps.
- The user opens the app without a session.
- The SP builds an AuthnRequest, saves its ID, and redirects the browser to the IdP’s SSO URL.
- The browser delivers the request; the IdP checks for an existing IdP session.
- The IdP authenticates the user if needed (password, MFA, passkey), builds and signs the assertion, and returns an auto-submitting HTML form holding the Base64-encoded Response.
- The browser POSTs the Response to the SP’s ACS URL.
- The SP validates the assertion, creates its own session cookie, and discards the assertion.
In IdP-initiated SSO, the user starts from the IdP dashboard, so steps 1 to 3 are skipped and the assertion has no InResponseTo. This makes IdP-initiated flows harder to protect against injected or replayed responses, so many SPs disable them.
Read More: SAML vs SSO: Is SAML the Same as Single Sign-On?
What is SAML used for?OAuth
- Workforce SSO: employees reach SaaS apps such as Salesforce, Workday, and AWS with one IdP login.
- B2B SaaS enterprise login: vendors accept each customer’s IdP, commonly a requirement in enterprise security reviews.
- Research and education federations: networks such as InCommon (US), eduGAIN (Europe and global), the Australian Access Federation, the Canadian Access Federation, and INFED (India) exchange SAML assertions between universities and publishers.
- Government and regulated access: US federal federation guidance in NIST SP 800-63C-4, published July 2025, sets Federation Assurance Levels (FAL1 to FAL3) for assertions.
- Token exchange: a SAML assertion can be swapped for an OAuth 2.0 access token under RFC 7522.
Click here: SAML vs OAuth: What Is the Difference and Which Should You Use in 2026?
How do you validate a SAML assertion?
An SP should accept an assertion only after all 8 checks below pass, in this order. Checks 1 to 3 establish that the IdP really sent the XML; checks 4 to 8 establish that it was sent to you, for this login, right now. Skipping any one of them is the root cause of the 2026 failures listed in the next section.
- Use only the IdP certificate from your stored metadata. Ignore any certificate embedded in the incoming message’s KeyInfo.
- Enforce your own signature algorithm allowlist. Accept RSA-SHA256 or stronger as configured; never let the message’s SignatureMethod choose the algorithm.
- Require a valid signature that covers the exact assertion you read. Reject unsigned assertions, resolve the Reference URI to that assertion’s ID, and read claims only from the signed element to block XML Signature Wrapping.
- Match the Issuer to the configured IdP entity ID.
- Match the Audience to your own SP entity ID.
- Check SubjectConfirmation and Response routing. Method is bearer, Recipient and the Response Destination equal your ACS URL, and InResponseTo equals a request ID you issued and have not used.
- Enforce the time window. Current time must fall between NotBefore and NotOnOrAfter, with at most a few minutes of clock-skew allowance and NTP-synced servers.
- Enforce one-time use. Store each assertion ID until its NotOnOrAfter passes and reject repeats.
Use a maintained SAML library for checks 1 to 3 rather than custom XML code, and keep it patched. Parser-level differences between the XML used for signature checking and the XML used for reading claims have produced full authentication bypasses in widely used libraries.
Why does a working SAML login suddenly reject assertions?
Most SAML assertion errors are configuration drift, not attacks. The table maps each error message to its usual cause and the check above that raises it.
| Error or symptom | Usual cause | Fix | Check |
|---|---|---|---|
| Every user fails on the same day with “invalid signature” | IdP signing certificate rolled over or expired; the SP still trusts the old one | Load the new certificate from IdP metadata before it becomes active; support two certificates during rollover | 1 |
| “Signature algorithm not allowed” | IdP set to RSA-SHA1 while the SP requires RSA-SHA256 | Switch the IdP to SHA-256 | 2 |
| “Invalid audience” | SP entity ID differs from the IdP’s configured identifier, often by a trailing slash or http vs https | Make both strings identical | 5 |
| “Invalid recipient” or “invalid destination” | ACS URL differs, often behind a proxy or load balancer | Match the ACS URL exactly, including scheme and port | 6 |
| “InResponseTo mismatch” on dashboard logins | IdP-initiated SSO sends no request ID | Allow IdP-initiated flows explicitly, or start logins at the SP | 6 |
| “Assertion expired” or “not yet valid” at random | Server clocks drift apart | Sync both servers to NTP | 7 |
| “Assertion replayed” after pressing Back | Browser re-POSTs a used assertion | Redirect after the ACS POST | 8 |
Certificate expiry is the most predictable outage. Microsoft Entra ID creates SAML signing certificates valid for 3 years by default and emails up to five addresses 60, 30, and 7 days before expiry. Microsoft also warns that an app that does not validate certificate expiry keeps accepting an expired certificate, so the SP should check the certificate’s validity dates, not only its key.
What goes wrong when SAML assertions are not validated? (2025 to 2026 cases)
In every case below, the IdP did its job, and the SP-side code trusted something in the incoming XML that it should have verified. Each maps to one of the 8 checks above.
| Published | CVE | Affected software | What the SP trusted | Severity | Check that prevents it |
|---|---|---|---|---|---|
| Aug 2026 | CVE-2026-19842 | SAML Single Sign On plugin for WordPress, before 5.4.7 | A certificate embedded in an unverified SAML response, later promotable to the trusted signing certificate | Auth bypass to any user once an admin promotes the planted certificate | 1 |
| Jul 16, 2026 | CVE-2026-15013 | Same plugin, through 5.4.3 | The SignatureMethod in the response; attackers chose HMAC-SHA1 and used the IdP’s public RSA key as the HMAC secret | CVSS 3.1: 9.8 Critical | 2 |
| Apr 6, 2026 | CVE-2026-22734 | Cloud Foundry UAA, bearer-assertion grant | SAML 2.0 bearer assertions that were neither signed nor encrypted | CVSS 3.1: 8.6 High | 3 |
| Dec 8, 2025 | CVE-2025-66567, CVE-2025-66568 (PortSwigger research) | ruby-saml before 1.18.0, with related PHP ecosystem bypasses | XML parsed differently by the signature verifier and the claims reader | Full authentication bypass | 3 |
The pattern: none of these flaws are in the SAML standard itself. All four sit in SP libraries and plugins, which is why checks 1 to 3 belong in a patched, widely reviewed library.
Can a validly signed SAML assertion still be forged?
Yes, if an attacker steals the IdP’s token-signing private key. This attack, called Golden SAML, produces assertions that pass all 8 SP checks because the signature is genuine. The IdP never authenticates the user, so passwords and MFA are bypassed. It was used in the 2020 SolarWinds intrusions (CISA Alert AA20-352A).
2026 status:
- July 14, 2026: Microsoft patched CVE-2026-56155, an Active Directory Federation Services (AD FS) privilege-escalation flaw exploited as a zero-day. It sits in the permissions on the Distributed Key Manager container, which holds the keys protecting AD FS token-signing certificates. CVSS 3.1 score: 7.8; CISA added it to the Known Exploited Vulnerabilities catalog the same day. Microsoft’s hardening becomes the default with the October 2026 update.
- September 15, 2026: NIST and CISA finalized NIST IR 8587, guidance on protecting tokens and assertions from forgery, theft, and misuse. It separates secure storage from secure usage of signing keys, ties signing-key validity periods to system classification and transaction sensitivity, and emphasizes automated key rotation.
| Control | What it stops or detects |
|---|---|
| Keep IdP signing keys in a hardware security module or managed key service | Key extraction from a compromised federation server |
| Rotate signing certificates on a schedule and immediately after any IdP compromise | Continued use of a stolen key |
| Match every SP sign-in to an IdP token-issuance log entry | Forged assertions, which have no matching IdP event |
| Patch or retire on-premises AD FS servers | Privilege escalation to the key store |
Which common SAML assertion claims are wrong?
Several widely repeated explanations of SAML assertions contradict the OASIS specification. The corrections below are the points most often misstated.
| Common claim | What the specification says |
|---|---|
| “Every SAML assertion includes a digital signature.” | The signature element is optional in the schema. With the HTTP-POST binding, the assertion must be protected by a signature on itself or on the Response; with the HTTP-Artifact binding, signing is not mandated. |
| “Authorization Decision is one of the three main assertion types.” | It is defined but frozen since SAML 2.0, and major IdPs rarely emit it. Authorization is normally done by the SP from attributes. |
| “An IdP can revoke an issued assertion.” | SAML 2.0 has no assertion revocation message. Access ends when NotOnOrAfter passes or when Single Logout ends the SP session. |
| “SAML includes a built-in Assertion Validator.” | No such component exists in the standard. Validators are third-party debugging tools. |
| “The assertion ID prevents replay attacks.” | Only if the SP stores used IDs and rejects repeats (check 8). |
| “A SAML response can be sent over HTTP-Redirect.” | Browser SSO responses use HTTP-POST or HTTP-Artifact only. |
| “An encrypted assertion is a trusted assertion.” | Encryption uses the SP’s public key, which anyone can obtain. Only the IdP’s signature proves origin. |
SAML vs OAuth vs OIDC: which one uses assertions?
SAML sends a signed XML assertion to log a user into an app. OAuth 2.0 (RFC 6749) is an authorization framework that issues access tokens so an app can call an API; it does not define user login. OpenID Connect adds login on top of OAuth 2.0 with a signed JSON ID token, which plays the same role as a SAML assertion.
| SAML 2.0 | OAuth 2.0 | OpenID Connect (OIDC) | |
|---|---|---|---|
| Main job | Authentication and SSO | Delegated API authorization | Authentication and SSO |
| Identity artifact | XML assertion | Access token (format not defined by OAuth) | JWT ID token |
| Published | 2005, OASIS | 2012, IETF | 2014, OpenID Foundation |
| Typical fit | Enterprise web apps, B2B SaaS, education federations | Third-party API access, machine-to-machine | Consumer login, mobile apps, SPAs, new builds |
| Mobile and SPA support | Weak (browser POST, large XML) | Strong | Strong |
| Can work together | A SAML assertion can be exchanged for an OAuth token via RFC 7522 | Yes | Yes |
Decision rule: support SAML when enterprise customers require it, since many workforce IdP deployments still standardize on it. Choose OIDC for new consumer, mobile, or API-first products. Use OAuth 2.0 only for API authorization, never on its own as a login protocol. OAuth stands for Open Authorization, not “OpenAuth”.
Click here: SAML vs OIDC: Which SSO Protocol Should You Use in 2026?
Frequently Asked Questions (FAQs)
Is SAML a protocol?
SAML is a framework, not a single protocol. It defines four layers: assertions (the XML claims), protocols (request and response messages such as AuthnRequest and LogoutRequest), bindings (how messages ride on HTTP or SOAP), and profiles (combinations for a use case, such as Web Browser SSO).
What is the difference between SSO and SAML?
SSO is the outcome: one login gives access to many apps. SAML is one standard that delivers SSO; OIDC, Kerberos, and proprietary vendor methods also deliver it.
What is a SAML bearer assertion?
A bearer assertion uses the urn:oasis:names:tc:SAML:2.0:cm:bearer confirmation method, so any party holding it can present it. That is why bearer assertions depend on short lifetimes, Recipient and Audience checks, TLS, and one-time use. The alternative, holder-of-key, requires the presenter to prove possession of a specific key.
How do I decode or decrypt a SAML assertion?
To decode, capture the SAMLResponse form field with a browser tool such as SAML-tracer and Base64-decode it; the result is readable XML. Requests sent over HTTP-Redirect are also DEFLATE-compressed. To decrypt an <EncryptedAssertion>, you need the SP’s private key, so only the SP or its SAML library can do it.
Is SAML being deprecated?
No. SAML 2.0 remains the current OASIS Standard in 2026, and no standards body has deprecated it. New consumer and mobile projects usually choose OIDC, while enterprise and education SSO still rely heavily on SAML. US federal guidance finalized in September 2026 (NIST IR 8587) still covers protecting federation assertions.
Can you use SAML and OAuth together?
Yes. A common pattern uses SAML for the user’s browser login and OAuth 2.0 access tokens for API calls, and a SAML assertion can be exchanged directly for an access token.
Does Okta use SAML or OAuth?
Both. Okta, Microsoft Entra ID, Google Workspace, and Ping Identity all act as SAML 2.0 IdPs and as OAuth 2.0 and OIDC providers; the app decides which it supports.
About this guide
Written by: Cade Miller
Cade Miller is a cybersecurity specialist with an interest in identity and access management, authentication protocols, and enterprise security. He explores topics like SAML assertions to help readers understand how secure authentication and identity verification work in modern systems.
Method: Assertion structure and processing rules are taken from the OASIS SAML 2.0 specifications linked above. Vulnerability data comes from vendor advisories and CVE records published between December 2025 and September 2026. All sources are linked inline where first used.
Update log: September 25, 2026: first published; links and figures verified against OASIS, NIST, Microsoft Learn, and vendor advisories the same day.
