SAML Token Example: What’s Inside a SAML Assertion

Security Assertion Markup Language (SAML) is one of the most established standards for identity federation and single sign-on (SSO). It allows organizations to authenticate users once and securely grant access to multiple applications without requiring repeated credential entry.

At the heart of every SAML-based authentication flow is the SAML assertion, often referred to as a SAML token. This assertion is a structured XML document issued by an Identity Provider (IdP) and consumed by a Service Provider (SP). It carries verifiable claims about a user’s identity, authentication state, and associated attributes. 

Understanding what is inside a SAML assertion is essential for anyone designing, integrating, or maintaining SAML-based systems.

What Is a SAML Token?

A SAML token is a digitally signed assertion generated by an Identity Provider after a user successfully authenticates. It represents a trusted statement that confirms who the user is and how they authenticated.

Unlike session cookies or OAuth access tokens, a SAML token is not meant to be reused or stored long-term. Its sole purpose is to convey authentication results securely from the IdP to the SP during the login process. 

Once validated, the Service Provider establishes its own session and no longer relies on the assertion.

How SAML Assertions Enable Single Sign-On

SAML enables single sign-on by decoupling authentication from application access. Instead of each application handling credentials independently, authentication is centralized at the Identity Provider.

When a user attempts to access an application, the Service Provider redirects the user to the Identity Provider for authentication. After authentication, the IdP issues a SAML assertion and sends it back to the Service Provider. 

The Service Provider validates the assertion and grants access without prompting the user for credentials again. This approach improves security while significantly reducing user friction.

High-Level Structure of a SAML Assertion

A SAML assertion is an XML document that follows a strict schema defined by the SAML specification. Although the XML syntax can appear complex, the logical structure is consistent and predictable.

At a high level, a SAML assertion contains metadata about its issuance, information about the authenticated user, statements describing authentication and attributes, and conditions that limit its validity. Each of these components plays a specific role in establishing trust between the Identity Provider and the Service Provider.

Example of a Simplified SAML Assertion

Examining a simplified SAML assertion helps illustrate how the document is structured. Real-world assertions typically include additional elements such as digital signatures, encryption blocks, and namespaces, but the fundamental layout remains the same.

This simplified example highlights the core elements that appear in nearly every SAML assertion, making it easier to understand how identity information is conveyed.

<saml:Assertion ID="_id12345"
    IssueInstant="2026-01-19T10:15:30Z"
    Version="2.0">

  <saml:Issuer>https://idp.example.com</saml:Issuer>

  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      user@example.com
    </saml:NameID>
  </saml:Subject>

</saml:Assertion>

The <Assertion> Element

The <Assertion> element is the root container for the entire SAML token. Every other element in the document exists within this element.

This element includes critical metadata such as a unique identifier, the SAML version, and the exact time the assertion was issued. These values allow Service Providers to detect replay attacks, enforce expiration rules, and ensure the assertion conforms to the expected protocol version.

The <Issuer> Element

The <Issuer> element identifies the Identity Provider that generated the assertion. It typically contains a URI that uniquely represents the IdP within the federation.

Service Providers rely heavily on this value to determine trust. Even if all other validation checks succeed, an assertion must be rejected if the issuer does not match a preconfigured and trusted Identity Provider. This check forms the foundation of SAML’s trust model.

The <Subject> Element

The <Subject> element defines the identity that the assertion applies to. It establishes who the authenticated user is from the perspective of the Identity Provider. This element is essential for mapping external identities to internal user accounts. Without a subject, the assertion would not be able to convey meaningful identity information to the Service Provider.

NameID

The <NameID> element contains the primary identifier for the user. This identifier is used by the Service Provider to recognize the user and associate them with a local account.

Different NameID formats serve different purposes. Email-based identifiers are easy to understand but may change over time, while persistent identifiers remain stable and opaque, improving long-term account correlation and privacy.

Subject Confirmation

Subject confirmation defines how the Service Provider should verify that the assertion is legitimately presented by the authenticated user. The most common method is bearer confirmation, which assumes that possession of the assertion is sufficient proof. Because this method is sensitive to interception, strict validation of time limits, recipients, and signatures is critical to maintaining security.

The <Conditions> Element

The <Conditions> element specifies the rules under which the assertion is valid. These rules prevent assertions from being used outside their intended scope.

Conditions are evaluated every time an assertion is processed. If any condition fails, the assertion must be rejected immediately, regardless of other valid data.

Time-Based Conditions

Time-based conditions define the window during which the assertion can be used. This limits the usefulness of stolen or intercepted assertions.

Assertions are typically valid for only a few minutes, which significantly reduces the risk of replay attacks while still allowing enough time for legitimate processing.

Audience Restriction

Audience restriction limits which Service Providers are allowed to accept the assertion. This ensures that assertions cannot be reused at unintended services.

The Service Provider must verify that its own identifier appears in the allowed audience list before accepting the assertion.

The <AuthnStatement> Element

The authentication statement describes how and when the user authenticated at the Identity Provider. It provides context that helps Service Providers evaluate authentication strength.

This information is especially important for applications that enforce security policies based on authentication method or recency.

Authentication Time and Session Information

The authentication time records when the user last authenticated, which may differ from when the assertion was issued.

Session identifiers allow multiple Service Providers to coordinate logout actions, ensuring that sessions are terminated consistently across systems.

Authentication Context

The authentication context specifies the method used to authenticate the user, such as password-based login or multi-factor authentication.

Service Providers can use this information to enforce policies, such as requiring stronger authentication for sensitive actions.

The <AttributeStatement> Element

The attribute statement contains additional information about the user beyond the primary identifier. These attributes often drive authorization decisions and personalization.

Attributes are supplied by the Identity Provider and can vary depending on configuration and trust agreements.

Common Attributes

Common attributes include email address, display name, department, role, and group membership.

Service Providers frequently rely on these attributes to determine access levels, assign roles, or customize the user experience.

Attribute Naming and Mapping

SAML does not enforce a universal attribute naming standard. This flexibility allows customization but also requires careful configuration.

Explicit attribute mapping ensures that the Service Provider correctly interprets identity data provided by the Identity Provider.

Digital Signatures in SAML Assertions

Digital signatures protect the integrity and authenticity of SAML assertions. They ensure that the assertion has not been altered and that it was issued by a trusted Identity Provider.

Service Providers must validate signatures using the IdP’s public certificate. Accepting unsigned or improperly signed assertions introduces serious security risks.

Common Implementation Mistakes

Many SAML security vulnerabilities do not originate from weaknesses in the SAML standard itself, but from incomplete, inconsistent, or incorrect implementations. Because SAML is highly flexible and configuration-driven, small mistakes can significantly weaken the trust model between the Identity Provider and the Service Provider.

Below are some of the most common SAML implementation mistakes that lead to authentication bypass, token replay, or unauthorized access:

• Skipping Signature Validation
  
  • Some implementations fail to properly validate the digital signature on the SAML assertion or response. If signature verification is skipped, misconfigured, or applied to the wrong XML element, attackers may be able to forge assertions or modify identity data without detection.

• Accepting Unsigned Assertions
  
  • Allowing unsigned assertions, even in test or internal environments, creates a dangerous precedent. Any assertion that is not cryptographically signed by a trusted Identity Provider should always be rejected.

• Overly Long Assertion Lifetimes
  
  • Configuring assertions with long validity windows increases the risk of replay attacks. If an assertion is intercepted, it can be reused for an extended period, undermining the purpose of time-based restrictions.

• Incorrect Audience Restriction Validation
  
  • Some Service Providers fail to verify that the assertion was intended specifically for them. Without proper audience validation, a valid assertion could be replayed against unintended services.

• Improper Subject Confirmation Checks
  
  • Neglecting to validate recipient URLs, confirmation methods, or expiration values can allow assertions to be reused or redirected to unauthorized endpoints.

Encryption of SAML Assertions

Encryption protects sensitive information contained within the assertion as it passes through the user’s browser.

While not always mandatory, encryption is strongly recommended when assertions contain personally identifiable or regulated data.

Where SAML Assertions Are Commonly Used

SAML assertions are a key part of enterprise identity and access management, providing a secure way to share authentication and authorization data across systems and organizations. Here are the most common use cases:

• Corporate Single Sign-On (SSO)
  
  • SSO lets employees access multiple applications with one set of credentials. SAML assertions carry identity, roles, and permissions from the Identity Provider (IdP) to the Service Provider (SP), reducing password fatigue, improving security, and streamlining user access.

• SaaS Integrations
  
  • Many SaaS platforms, like Salesforce, Workday, and Microsoft 365, use SAML for authentication. Organizations configure these services to trust assertions from their IdP, ensuring consistent access policies, preventing unauthorized logins, and simplifying IT administration.

• Cross-Organization Identity Federation
  
  • SAML allows secure collaboration between organizations without separate accounts for each system. Common in supply chains and joint ventures, assertions grant controlled access to external users while maintaining centralized authentication and security policies.

• Government and Higher Education Environments
  
  • In regulated environments, SAML enables secure access to shared resources while supporting compliance with standards like FERPA, HIPAA, or GDPR. Institutions can authenticate staff, students, and external collaborators securely and audibly.

• Legacy Enterprise Systems
  
  • Many organizations rely on SAML for older applications. It ensures compatibility with legacy systems while still providing secure authentication and federated identity management, allowing gradual IT modernization without disrupting existing workflows.

This shows that SAML assertions remain relevant across diverse organizational contexts, providing secure, federated authentication and simplified management for users and IT teams alike.

Bottom Line

A SAML assertion is a structured, signed identity document that enables secure authentication across systems. Understanding each component and its purpose allows teams to build reliable integrations, simplify troubleshooting, and maintain strong security practices. 

Even with the emergence of newer authentication standards, SAML remains a critical part of enterprise identity systems. Modern identity platforms like Authgear make it easier for organizations to implement SAML alongside contemporary protocols such as OAuth and DPoP. 

Start your free Authgear trial today and simplify your SAML integrations while strengthening your authentication flows with modern security features like DPoP and OAuth.

FAQs

Is a SAML assertion reusable?

No. It is short-lived and intended for one-time use.

Does a SAML assertion authenticate or authorize users?

It primarily supports authentication, while attributes help inform authorization.

Are SAML assertions always encrypted?

No, but encryption is recommended when sensitive data is involved.

Why does SAML use XML instead of JSON?

SAML was designed before JSON-based standards and relies on XML for extensibility and signatures.

Is SAML still relevant today?

Yes. It remains widely deployed in enterprise identity environments.