SAML Assertion: An Annotated Sample, Line by Line

A SAML assertion is the signed statement an identity provider sends an application: who signed in, when, and for whom, read here line by line.

Updated Oct 8, 2026

Request More Info

Every element of a real-looking assertion, and what the application does with it.

A SAML assertion is a signed XML document in which the identity provider (IdP) states who a user is, how and when that user authenticated, and optionally attributes such as email address or groups.

The application that receives it, the service provider (SP), accepts the user only when three conditions hold:

a certificate the SP trusts signed the assertion;
the assertion names this SP as its audience;
it arrived at the registered address within its validity window.

The sample below is fictional. It uses Acme Corp values in the structure the standard defines.

SAML 2.0 Core (section 2) defines the assertion itself. The delivery and processing rules are in the SAML 2.0 profiles (section 4.1.4).

An annotated sample assertion

Maria Lopez opens the expense service ExpenseDesk, and Acme’s IdP returns a response that contains this assertion. A ... stands for long encoded content.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_a75adf55-01d7-40cc" Version="2.0"
                IssueInstant="2026-10-08T14:02:11Z">
  <saml:Issuer>https://sso.acme.example/saml/idp</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      maria.lopez@acme.example
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
          InResponseTo="_req-4f2c91"
          Recipient="https://acme.expensedesk.example/saml/acs"
          NotOnOrAfter="2026-10-08T14:07:11Z"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-10-08T14:01:41Z"
                   NotOnOrAfter="2026-10-08T14:07:11Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://acme.expensedesk.example/saml/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-10-08T14:02:09Z" SessionIndex="_s-91ab">
    <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="displayName">
      <saml:AttributeValue>Maria Lopez</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>Finance</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Element	What it says	What the SP does with it
`ID`, `IssueInstant`	A unique identifier and the creation time	Records the ID so the same assertion cannot be used twice
`Issuer`	The IdP’s entity ID	Looks up which certificate belongs to that IdP
`Signature`	An XML signature over the assertion	Verifies it with the IdP’s certificate before reading anything else
`Subject` / `NameID`	Who the assertion is about, and the identifier format	Finds or creates the local account
`SubjectConfirmation` (bearer)	Whoever presents this assertion is the subject; `Recipient`, `NotOnOrAfter` and `InResponseTo` limit where, until when and in answer to what	Checks all three
`Conditions`	The validity window and the `AudienceRestriction`	Rejects the assertion outside the window or when it names another audience
`AuthnStatement`	When (`AuthnInstant`) and how (`AuthnContext`) the person signed in; `SessionIndex` identifies the session for single logout	Applies its own rules, such as requiring recent sign-in
`AttributeStatement`	Facts about the person	Maps them to profile fields or roles

What a service provider must validate

The Web Browser SSO profile (section 4.1.4.3) requires the SP to check four things:

Any signatures verify.
Recipient matches the ACS URL where the response arrived.
NotOnOrAfter has not passed, allowing for clock skew.
InResponseTo equals the ID of the request the SP sent.

Two further rules apply:

The SP must cache used assertion IDs for as long as the assertion could still be valid, which prevents replay of a captured assertion (section 4.1.4.5).
A bearer assertion must name the SP in an AudienceRestriction (section 4.1.4.2).

An IdP-initiated, unsolicited response has no InResponseTo, so the SP skips that check by design.

Two details cause most implementation errors:

Signature scope. A signature can cover the whole Response, only the Assertion, or both. Validate the element the IdP actually signs.
NameID format. A persistent identifier is stable and opaque. An emailAddress is readable, but it changes when the user’s address changes.

Common errors and what they mean

The messages below come from SSOGEN’s test sign-in for a connected SAML identity provider. Other products word the same causes differently.

Message	Cause in the assertion	Fix
The assertion was addressed to a different service provider.	`Audience` is not the SP’s entity ID	Set the identifier in the IdP to the SP’s entity ID exactly
The response came back to a different ACS URL than the one this provider registered.	`Recipient` differs from the registered ACS URL	Set the reply URL to the SP’s ACS URL exactly
The assertion’s signature did not verify.	Wrong or rotated signing certificate	Import the IdP’s metadata again
The assertion is outside its validity window.	Clocks disagree, so `NotBefore` or `NotOnOrAfter` fails	Correct the clock on either server (SSOGEN allows 5 minutes by default)
This assertion had already been used.	Replay, often from the browser’s Back button	Start the sign-in again
The assertion carried no subject (NameID).	`Subject` has no `NameID`	Add a stable NameID at the IdP

How SSOGEN builds the assertion

When SSOGEN is the IdP, the Test step of the application wizard shows a SAML assertion card. It lists the NameID, authentication context, audience, recipient and attributes a selected user would receive, without sending anything.

The default NameID is an opaque persistent identifier. If the application matches users by email address, select the email address on the Identity sent to app step. A user with no email address in SSOGEN is then refused rather than sent under a different identifier.
Additional attributes use the “basic” name format.
Assertions go only to the registered ACS URL.

Questions people ask

Is a SAML assertion encrypted?

It is signed, and it can also be encrypted to the SP’s certificate. Encryption matters when the browser or an intermediary could otherwise read attribute values.

How do I decode a SAML response?

With the HTTP POST binding, the response is base64-encoded text in a form field. Decode it and read the XML. Never paste a production assertion into an online decoder.

How long is an assertion valid?

Minutes. The window in Conditions and NotOnOrAfter is deliberately short; the SP’s own session lasts longer.

Where to go next

Values. For the values the assertion is checked against, see ACS URL, entity ID and audience.
The flow. For the full flow, start with what is SAML, then follow register a SAML application to see these values in a console.
Upstream provider. Use add a SAML identity provider.
Choosing. If you are unsure whether SAML is the right fit, see choose how to connect an application.
Where checks sit. Read how SAML authentication works.
Forgery. An attacker who steals the signing key can forge assertions; see Golden SAML in is SSO secure.

Sources, all read 2026-10-09: SAML 2.0 Core, SAML 2.0 Profiles.