Glossary

SAML 2.0

SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP), enabling web-based single sign-on (SSO).

Get in touch Learn more

Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.

API AUTHENTICATION FLOWS

What is SAML 2.0?

SAML 2.0 is the foundational XML-based standard for enterprise web single sign-on (SSO) and federated identity.

Security Assertion Markup Language 2.0 (SAML 2.0) is an open, XML-based standard for exchanging authentication and authorization data between a trusted Identity Provider (IdP) and a Service Provider (SP). It enables web-based single sign-on (SSO), allowing a user to authenticate once at the IdP and subsequently access multiple SP applications without re-entering credentials. The protocol defines a framework for constructing, transporting, and processing SAML assertions—security statements about a user's identity, attributes, and entitlements.

The core exchange is the SAML flow, where the SP redirects an unauthenticated user to the IdP. The IdP authenticates the user (often with Multi-Factor Authentication) and issues a digitally signed SAML response containing an assertion. The user's browser posts this response back to the SP, which validates the signature and establishes a local session. As a federated identity standard, it decouples authentication from application logic, centralizing it at the IdP for improved security and manageability compared to individual application credentials.

PROTOCOL ARCHITECTURE

Key Components of SAML 2.0

SAML 2.0 is an XML-based open standard that defines the core entities, messages, and bindings for federated identity and single sign-on (SSO).

Assertions

An Assertion is the core XML security token that conveys statements about a Subject (user). It is issued by the Identity Provider (IdP) and consumed by the Service Provider (SP). There are three primary statement types:

Authentication Statements: Confirm the user was authenticated at a specific time using a particular method.
Attribute Statements: Carry specific data about the user (e.g., email, group memberships).
Authorization Decision Statements: (Rarely used) State whether the user is permitted to access a resource.

Protocols

SAML defines request/response Protocols for performing identity operations. The most critical is the SAML Authentication Request Protocol, which governs the SSO flow:

The SP initiates the flow by sending a <samlp:AuthnRequest> to the IdP.
The IdP processes the request, authenticates the user, and returns a <samlp:Response> containing one or more Assertions.
Other protocols exist for Single Logout (SLO), Name ID management, and Artifact resolution.

Bindings

Bindings define how SAML protocol messages are mapped onto standard communication frameworks. They specify the transport and encoding:

HTTP Redirect Binding: Encodes messages in URL query parameters. Used to initiate SSO from the SP.
HTTP POST Binding: Encodes messages in an HTML form, which is auto-submitted via JavaScript. Used by the IdP to deliver the SAML Response.
HTTP Artifact Binding: Exchanges a reference (an artifact) instead of the full assertion, which is then resolved via a back-channel SOAP call. Enhances security for large tokens.
SOAP Binding: Used for back-channel communications like Artifact resolution.

Profiles

Profiles are concrete combinations of assertions, protocols, and bindings to achieve specific use cases. The definitive profile is the Web Browser SSO Profile:

Outlines the step-by-step message exchange for browser-based single sign-on.
Typically uses the HTTP Redirect Binding for the <AuthnRequest> and the HTTP POST Binding for the <Response>.
Other profiles include the Single Logout Profile, Identity Provider Discovery Profile, and the Assertion Query/Request Profile.

Metadata

SAML Metadata is an XML format used to exchange configuration information between an Identity Provider and a Service Provider, enabling automated federation. A metadata file includes:

EntityID: The unique identifier for the IdP or SP.
X.509 certificates for signing and encryption.
Endpoint URLs for Single Sign-On, Single Logout, and other services.
Supported bindings and NameID formats.
This allows for plug-and-play integration without manual configuration of endpoints and certificates.

Security & Signatures

SAML relies heavily on XML Digital Signatures (XML DSig) and optional encryption for message integrity, authentication, and confidentiality.

Message Signing: Critical SAML elements (like the entire <Response> or an <Assertion>) are digitally signed. The recipient validates the signature using the issuer's public key (from metadata) to ensure the message is untampered and truly from the claimed issuer.
Assertion Encryption: The <Assertion> can be encrypted using the service provider's public key, ensuring only the intended SP can read its contents.
Security considerations include replay attacks (mitigated by NotOnOrAfter conditions), proper validation of signatures and audience restrictions (<AudienceRestriction>).

PROTOCOL COMPARISON

SAML 2.0 vs. OAuth 2.0 & OpenID Connect

A technical comparison of three core identity and access management protocols, highlighting their primary use cases, token formats, and architectural models.

Feature	SAML 2.0	OAuth 2.0	OpenID Connect (OIDC)
Primary Purpose	Authentication & Authorization for Web SSO	Authorization Delegation (API Access)	Authentication & Identity Layer on OAuth 2.0
Core Use Case	Enterprise Single Sign-On (SSO)	Securing API access for applications	Consumer & modern app login (Identity verification)
Token Format	XML-based SAML Assertion	Opaque or structured (e.g., JWT) Access Token	JSON Web Token (JWT) ID Token
Communication Protocol	HTTP POST/Redirect (XML payloads)	HTTP with bearer tokens	HTTP with JWTs (extends OAuth 2.0)
Flow Initiation	Service Provider (SP) initiated	Client (Relying Party) initiated	Client (Relying Party) initiated
User Identity Data	Embedded in SAML Assertion attributes	Not natively provided (scope-dependent)	Standardized claims in the ID Token (sub, email, etc.)
API Access Delegation
Authentication Context
Profile & Email Scope
Typical Architectural Model	Identity Provider (IdP) & Service Provider (SP)	Authorization Server, Resource Server, Client	OpenID Provider (OP) & Relying Party (RP)
Common Transport Binding	HTTP POST Binding	Bearer Token usage in Authorization header	Bearer Token usage & ID Token in POST body or fragment

SAML 2.0

Frequently Asked Questions

Security Assertion Markup Language 2.0 is the foundational XML-based protocol for enterprise-grade web single sign-on (SSO). These questions address its core mechanisms, differences from modern protocols, and integration patterns for AI agents and API authentication.

SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data between a trusted Identity Provider (IdP) and a Service Provider (SP), enabling web-based single sign-on (SSO). It works through a redirect-based flow where the SP, upon detecting an unauthenticated user, generates an authentication request (a SAMLRequest) and redirects the user's browser to the IdP. The IdP authenticates the user (e.g., via password or MFA), creates a SAML assertion containing identity claims, signs it digitally, and sends it back to the SP (via the browser in a SAMLResponse) for validation and session establishment.

Key components of the flow include:

SAML Assertion: An XML document with statements about the user (authentication, attributes, authorization decisions).
Protocol Bindings: Definitions like the HTTP POST Binding or HTTP Redirect Binding for transporting messages.
Metadata: XML files exchanged between IdP and SP containing endpoints, certificates, and supported bindings for secure configuration.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.

Talk to Us

SAML 2.0

What is SAML 2.0?