SAML Assertion vs SAML Response
A SAML Response is the protocol message an identity provider (IdP) returns to a service provider (SP). It carries delivery information such as Destination, InResponseTo, and a Status code. On a successful sign-in, it usually contains an Assertion: the statement about the user, with a subject, validity conditions, audience, and authentication or attribute statements.
| Question | Look in the Response | Look in the Assertion |
|---|---|---|
| Did the IdP return success? | Status/StatusCode |
— |
| Which SP endpoint is targeted? | Destination |
— |
| Which user is represented? | — | Subject/NameID |
| When may this statement be accepted? | — | Conditions, including NotBefore and NotOnOrAfter |
| Which SP may consume it? | — | AudienceRestriction/Audience |
| Where is the XML signature? | May be on the Response | May be on the Assertion; requirements depend on the profile and SP configuration |
A compact example
This XML is illustrative and unsigned. It shows placement of fields; it is not a SAML message to use for login.
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_response123" Version="2.0"
InResponseTo="_request123"
IssueInstant="2026-09-29T00:00:00Z"
Destination="https://sp.example.com/acs">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<saml:Assertion ID="_assertion123" Version="2.0" IssueInstant="2026-09-29T00:00:00Z">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject><saml:NameID>user@example.com</saml:NameID></saml:Subject>
<saml:Conditions NotBefore="2026-09-29T00:00:00Z"
NotOnOrAfter="2026-09-29T00:05:00Z">
<saml:AudienceRestriction><saml:Audience>https://sp.example.com</saml:Audience></saml:AudienceRestriction>
</saml:Conditions>
</saml:Assertion>
</samlp:Response>
In a real SSO flow, the IdP and SP must follow the selected SAML profile and binding. For the HTTP POST browser SSO profile, a signature can protect the Response or the Assertion; an SP may require a particular signature location or both. Never accept an assertion because its XML merely contains a <ds:Signature> element. The SP must cryptographically validate the applicable signature against the trusted IdP certificate and ensure the signed content is the content it consumes.
Debug a failed sign-in safely
- Decode a test or redacted message with the SAML Decoder. It accepts XML or encoded SAML and shows the parsed fields. Raw assertions can contain personal data and act as credentials; do not paste live values into tickets or public examples.
- Check the Response's
StatusCode,Destination, andInResponseToagainst the request your SP sent. - Check the Assertion's
Audience,NotBefore,NotOnOrAfter, and subject confirmation against your SP configuration and clock. TheNotOnOrAfterboundary is exclusive. - Use the SP's trusted SAML library and configured IdP certificate to verify signatures, recipient, replay protection, and all profile-specific checks.
The SAML Validator performs basic XML, structure, status, and time checks. It does not verify XML signatures or compare an audience to a configured SP entity ID. A “valid” result there is a debugging hint, not an authentication decision. For detailed protocol semantics, consult the OASIS SAML 2.0 technical overview.