1. Home /
  2. Architecture /
  3. SAML 2.0 Explained: How SSO and Federated Identity Work
Architecture 2026-01-23

SAML 2.0 Explained: How SSO and Federated Identity Work

Understand SAML 2.0 and how it enables Single Sign-On (SSO), the roles of Identity Provider and Service Provider, and how it compares to OAuth 2.0 and OpenID Connect.

Read in: ja
SAML 2.0 Explained: How SSO and Federated Identity Work

OASIS Security Assertion Markup Language (SAML) 2.0 key points summary.

Overview

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data.

It is a framework for securely exchanging user authentication and attribute information between different security domains. It is primarily used for SSO (Single Sign-On) in enterprise environments.

Item Content
Established OASIS (March 2005)
Format XML
Main Uses Web Browser SSO, Federation
Predecessor SAML 1.1

Comparison with OAuth/OIDC

Item SAML 2.0 OAuth 2.0 / OIDC
Purpose Authentication + Attribute Exchange Authorization (OAuth) / Authentication (OIDC)
Data Format XML JSON
Token Format XML Assertion JWT (OIDC)
Signature Method XML Signature JWS
Encryption Method XML Encryption JWE
Main Uses Enterprise SSO Web/Mobile Apps
Complexity High Low

Key Terms

Term Description
Identity Provider (IdP) Entity that authenticates users and issues Assertions
Service Provider (SP) Entity that receives Assertions and provides services
Assertion XML document issued by IdP containing authentication, attribute, and authorization information
Principal Entity being authenticated (usually the end-user)

Four Components of SAML

SAML is structured with a hierarchical design.

flowchart TB subgraph Profiles["Profiles (Use Case Definitions)"] P1[Web Browser SSO] P2[Single Logout] P3[ECP] end subgraph Bindings["Bindings (Communication Methods)"] B1[HTTP Redirect] B2[HTTP POST] B3[SOAP] B4[Artifact] end subgraph Protocols["Protocols (Message Exchange)"] Pr1[AuthnRequest] Pr2[Response] Pr3[LogoutRequest] end subgraph Assertions["Assertions (Security Information)"] A1[AuthnStatement] A2[AttributeStatement] A3[AuthzDecisionStatement] end Profiles --> Bindings --> Protocols --> Assertions

1. Assertions

XML documents containing security information about the subject.

2. Protocols

Request/response message sets.

3. Bindings

Methods for transferring SAML messages over lower-layer protocols.

4. Profiles

Combinations of Assertions, Protocols, and Bindings for specific use cases.

Assertion

Structure

<saml:Assertion Version="2.0"
    ID="_abc123"
    IssueInstant="2024-01-15T10:00:00Z">

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

    <saml:Subject>
        <saml:NameID>user@example.com</saml:NameID>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml:SubjectConfirmationData
                NotOnOrAfter="2024-01-15T10:05:00Z"
                Recipient="https://sp.example.com/acs"/>
        </saml:SubjectConfirmation>
    </saml:Subject>

    <saml:Conditions NotBefore="..." NotOnOrAfter="...">
        <saml:AudienceRestriction>
            <saml:Audience>https://sp.example.com</saml:Audience>
        </saml:AudienceRestriction>
    </saml:Conditions>

    <saml:AuthnStatement AuthnInstant="2024-01-15T09:59:00Z">
        ...
    </saml:AuthnStatement>

    <saml:AttributeStatement>
        ...
    </saml:AttributeStatement>

</saml:Assertion>

Three Types of Statements

Statement Description
AuthnStatement Information about the authentication event (method, time)
AttributeStatement User attribute information (name, email, group, etc.)
AuthzDecisionStatement Authorization decision (access permission/denial to resources)

SubjectConfirmation Method

Method to confirm the validity of an Assertion.

Method Description
bearer Usable by the holder of the Assertion
holder-of-key Usable by the holder of a specific key
sender-vouches Usable based on criteria confirmed by the issuer

Protocols

Major Protocols

Protocol Description
Authentication Request Protocol SP requests authentication from IdP
Single Logout Protocol Logout from all SPs
Artifact Resolution Protocol Obtain Assertion via Artifact
Name Identifier Management Protocol Change/terminate identifiers

AuthnRequest

<samlp:AuthnRequest
    ID="_req123"
    Version="2.0"
    IssueInstant="2024-01-15T10:00:00Z"
    Destination="https://idp.example.com/sso"
    AssertionConsumerServiceURL="https://sp.example.com/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">

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

    <samlp:NameIDPolicy
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
        AllowCreate="true"/>

</samlp:AuthnRequest>

Response

<samlp:Response
    ID="_res456"
    Version="2.0"
    IssueInstant="2024-01-15T10:00:05Z"
    Destination="https://sp.example.com/acs"
    InResponseTo="_req123">

    <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>
        <!-- Assertion content -->
    </saml:Assertion>

</samlp:Response>

Bindings

Methods for transferring SAML messages.

Binding Method Features
HTTP Redirect GET Sent as URL query parameters with DEFLATE compression. Size limit applies
HTTP POST POST Sent as Base64 encoded in HTML form
HTTP Artifact GET/POST Sends a small Artifact for reference, retrieved separately
SOAP POST Sent in SOAP envelope. Back-channel communication
PAOS - Reverse SOAP. For ECP Profile

HTTP Redirect Binding

https://idp.example.com/sso?
    SAMLRequest=fZJNT8MwDIbv...（DEFLATE + Base64）
    &RelayState=token
    &SigAlg=...
    &Signature=...

HTTP POST Binding

<form method="post" action="https://sp.example.com/acs">
    <input type="hidden" name="SAMLResponse" value="PHNhbW...（Base64）"/>
    <input type="hidden" name="RelayState" value="token"/>
    <input type="submit" value="Submit"/>
</form>

Profiles

Web Browser SSO Profile

The most common profile. There are two flows.

SP-Initiated SSO

sequenceDiagram participant U as User participant SP as Service Provider participant IdP as Identity Provider U->>SP: (1) Access protected resource SP-->>U: (2) Redirect to IdP<br/>(AuthnRequest) U->>IdP: (3) Send AuthnRequest IdP->>U: (4) Display login page U-->>IdP: (5) Enter authentication information IdP-->>U: (6) Redirect to SP<br/>(Response + Assertion) U->>SP: (7) Send Response Note over SP: (8) Verify signature and process Assertion SP-->>U: (9) Grant access to resource

Feature: The user first accesses the SP and requests authentication from the IdP.

IdP-Initiated SSO

sequenceDiagram participant U as User participant IdP as Identity Provider participant SP as Service Provider U->>IdP: (1) Already logged in to IdP U->>IdP: (2) Click link to SP IdP-->>U: (3) Redirect to SP<br/>(Response + Assertion) U->>SP: (4) Send Response Note over SP: (5) Verify signature and process Assertion SP-->>U: (6) Grant access to resource

Feature: The user logs in to the IdP first and accesses the SP from there. No AuthnRequest needed.

Single Logout Profile

sequenceDiagram participant U as User participant SP1 as Service Provider 1 participant IdP as Identity Provider participant SP2 as Service Provider 2 U->>SP1: (1) Logout request SP1->>IdP: (2) LogoutRequest IdP->>SP2: (3) LogoutRequest SP2-->>IdP: (4) LogoutResponse IdP-->>SP1: (5) LogoutResponse SP1-->>U: (6) Logout complete

Binding × Profile Combinations

Possible combinations for Web Browser SSO Profile:

AuthnRequest Sending Response Sending
HTTP Redirect HTTP POST
HTTP POST HTTP POST
HTTP Redirect HTTP Artifact
HTTP POST HTTP Artifact

Metadata

XML documents describing IdP and SP configuration information.

IdP Metadata Example

<EntityDescriptor entityID="https://idp.example.com">
    <IDPSSODescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>...</ds:KeyInfo>
        </KeyDescriptor>
        <SingleSignOnService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
            Location="https://idp.example.com/sso"/>
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://idp.example.com/slo"/>
    </IDPSSODescriptor>
</EntityDescriptor>

SP Metadata Example

<EntityDescriptor entityID="https://sp.example.com">
    <SPSSODescriptor>
        <KeyDescriptor use="signing">
            <ds:KeyInfo>...</ds:KeyInfo>
        </KeyDescriptor>
        <AssertionConsumerService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://sp.example.com/acs"
            index="0"/>
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://sp.example.com/slo"/>
    </SPSSODescriptor>
</EntityDescriptor>

Information Included in Metadata

Item Description
EntityID Unique identifier of the entity (URI)
SSO Endpoint URL for Single Sign-On
SLO Endpoint URL for Single Logout
ACS Assertion Consumer Service URL
Certificate Public key for signature verification and encryption

Security Considerations

Signature and Encryption

Target Signature Encryption
AuthnRequest Recommended -
Response Recommended -
Assertion Required (usually) Optional

TLS Requirements

Requirement Recommendation
HTTP over SSL 3.0 / TLS 1.0 or higher Recommended
Response signature when using HTTP POST Required

Major Threats and Countermeasures

Threat Countermeasure
Replay Attack Assertion expiration (NotOnOrAfter), InResponseTo verification
Man-in-the-Middle Attack Mandatory TLS, signature verification
Assertion Forgery Signature verification with XML Signature
Session Hijacking Secure session management, SLO implementation

Assertion Verification Checklist

Item Verification Content
Signature Signed with the legitimate IdP's private key
Issuer Trusted IdP's EntityID
Audience Targeted to own SP
NotBefore / NotOnOrAfter Within valid period
InResponseTo Matches the ID of the sent AuthnRequest
Recipient Matches own SP's ACS URL

NameID Format

Format of user identifiers.

Format Description
unspecified No specific format
emailAddress Email address format
persistent Persistent pseudonymous identifier
transient Temporary identifier (per session)
X509SubjectName X.509 certificate Subject

Privacy Considerations

Format Usage
persistent Persistently identify the same user (opaque value)
transient One-time identifier. Prevents linking across SPs

Error Handling

Status Code

StatusCode Description
Success Success
Requester Error on the requester's side
Responder Error on the responder's side
VersionMismatch SAML version mismatch

Second-Level Status Code

StatusCode Description
AuthnFailed Authentication failed
NoPassive Passive authentication not possible
UnknownPrincipal Unknown user
RequestDenied Request denied

References

Tags: SAML Authentication Authorization
Share: 𝕏 Post Facebook Hatena
✏️ View source / Discuss on GitHub
☕ Support

If you enjoy this blog, consider supporting it. Every bit helps keep it running!

💳 PayPal 📚 Amazon Wishlist 🐙 GitHub Sponsors 📖 Zenn Books

Related Articles

The Abstraction Trap in Architecture Design
Architecture 2026-04-23

The Abstraction Trap in Architecture Design

#Design#DDD
Viability Conditions for Building a Platform
Architecture 2026-04-19

Viability Conditions for Building a Platform

#Architecture#Platform Engineering#DDD
What's the Difference Between Product Development and Platform Development?
Architecture 2026-04-06

What's the Difference Between Product Development and Platform Development?

#Architecture#Team Topologies#Platform Engineering#Organization Design
Migrating bmf-tech.com from gobel to gohan — A Full Static Site Transition
Architecture 2026-03-20

Migrating bmf-tech.com from gobel to gohan — A Full Static Site Transition

#gohan#Migration#SSG#Golang
Engineering in the AI Era: Evolution from Prompts to Autonomous Systems
Architecture 2026-02-25

Engineering in the AI Era: Evolution from Prompts to Autonomous Systems

#LLM as Judge#Prompt as Code#Prompt Ops#Context Engineering#Prompt Engineering#Continuous AI