How Does SAML SSO Work? | Inside The Trust Handshake

You click a link to an app. You land on a sign-in screen. Then you’re suddenly inside, already recognized. That “one login” feeling is the payoff people want from SSO.

SAML is one of the oldest, most common ways enterprises pull that off for browser-based apps. It’s not magic. It’s a carefully choreographed swap of messages, checks, and trust settings.

This article walks through that choreography in plain terms, then gets practical: what the parts are, what the messages contain, where deployments break, and how to fix the usual failures without guessing.

What SAML SSO Is Doing Behind The Scenes

SAML stands for Security Assertion Markup Language. It’s a standard that lets one system vouch for who a user is to another system.

The system that vouches for the user is the Identity Provider (IdP). The system that accepts that vouch and grants access is the Service Provider (SP), often called “the application.”

At the center is a SAML assertion. Think of it as a signed statement that says, “This user authenticated, at this time, with these details, and this statement is meant for this app.”

Who’s Involved In A Typical SAML Login

Identity Provider (IdP)

The IdP handles the sign-in. It can ask for a password, a security key, a push approval, or any mix of factors. After it’s satisfied, it creates a SAML response that carries an assertion.

Service Provider (SP)

The SP is your app. It trusts the IdP to authenticate users, then it creates a local session after it validates what the IdP sent.

The Browser

The browser is the courier. Most SAML web SSO relies on browser redirects and form posts to carry messages between the IdP and the SP.

Metadata And Certificates

Before any login works, both sides need to agree on a few facts: endpoint URLs, entity identifiers, and signing certificates. Most teams exchange these via SAML metadata files.

How Does SAML SSO Work? Step-By-Step

There are two common starting points. The most used is SP-initiated, where the app starts the flow. Another is IdP-initiated, where the identity system starts the flow. The middle of the flow looks similar in both.

Step 1: You Request The App

You visit the app URL. The app checks for an existing session cookie. If it doesn’t find one, it prepares a SAML AuthnRequest.

Step 2: The App Redirects You To The IdP

The SP sends your browser to the IdP’s SSO URL, often with the AuthnRequest attached. This request includes the SP’s entity ID and tells the IdP where to send the response.

Step 3: The IdP Authenticates You

The IdP checks whether you already have a valid IdP session. If you do, you might not see a prompt.

If you don’t, the IdP runs its sign-in steps, including MFA if the policy calls for it.

Step 4: The IdP Creates A SAML Response

After authentication, the IdP builds a SAML response containing an assertion. The assertion is typically signed, and it includes conditions that limit where and when it can be used.

Step 5: The Browser Posts The Response To The App

Most deployments use the HTTP-POST binding. The IdP returns an HTML form that auto-submits to the SP’s Assertion Consumer Service (ACS) URL with the SAML response in a hidden field.

Step 6: The App Validates And Creates A Session

The SP validates the response and assertion, checks signature trust, confirms audience and destination, checks time windows, then maps attributes (like email or username) to a local user record.

Once it’s satisfied, it creates a session and sets a session cookie. From that point on, the app treats you as signed in until the session expires or you sign out.

How SAML Single Sign-On Works Across Two Domains

SAML shines when the IdP and the app live in different domains. Your corporate identity might be on one domain, while the SaaS app is on another. Cookies can’t easily span those domains.

SAML gets around that by using browser redirects and posts, plus a signed assertion that the app can validate without calling the IdP in real time.

If you want to see the exact shapes of the browser messages and which parts Microsoft Entra ID supports, the Microsoft Entra ID SAML protocol reference is a clear, implementation-focused read.

What’s Inside A SAML Assertion

SAML assertions are XML. The XML can be long, but the pieces that matter during troubleshooting are easy to name once you know where to look.

Subject And NameID

The assertion identifies the user with a subject element. Often this includes a NameID, like an email address, a username, or a persistent opaque identifier.

The format of NameID matters. Some apps expect email format. Others prefer a persistent ID that never changes even if the email changes.

AuthnStatement

This states that the user authenticated at a specific time. It can also include an authentication context that hints at the method used, like password-only vs MFA.

AttributeStatement

This is where the IdP sends extra user data: email, given name, groups, roles, department, or anything the app needs for access decisions.

Many “login works but access is wrong” issues live here. The user gets in, then lands in the wrong role because the attribute mapping doesn’t match what the app expects.

Conditions

Conditions limit where and when the assertion can be accepted. Common checks include NotBefore/NotOnOrAfter time limits and an AudienceRestriction that names the SP entity ID.

This is a guardrail against replay and against an assertion being reused at a different service.

Table: The Full SAML Web SSO Flow And What Each Check Proves

Bindings And Endpoints You’ll See In Admin Screens

SAML can travel via different “bindings.” In web SSO, you’ll see a small set again and again.

HTTP-Redirect

Often used for sending the AuthnRequest from the app to the IdP. The message is URL-encoded and carried on a redirect.

HTTP-POST

Often used for sending the SAML response from the IdP to the app. The message is base64-encoded and posted in a form field to the ACS URL.

ACS URL

This is the app endpoint that receives the response. If the ACS URL in the IdP setup doesn’t match what the app expects, you’ll get hard failures like “Reply URL mismatch” or “Invalid destination.”

Signatures, Encryption, And Why Certificates Matter

SAML relies on cryptography to establish trust between the IdP and the app. The most common pattern is: the assertion is signed, and the app verifies the signature with the IdP’s public certificate.

Signed Assertions

Signing proves the assertion came from the IdP that owns the private key. It also proves the XML content wasn’t altered in transit.

In many setups, the app will reject responses that are not signed, even if everything else looks right.

Encrypted Assertions

Some apps request encryption for privacy. In that case, the IdP encrypts the assertion so only the app can decrypt it using the app’s private key.

Encryption adds setup steps and can complicate debugging. Teams often start with signing only, then add encryption once the flow is stable and the security requirements call for it.

Certificate Rotation

Certificates expire and get rotated. If the IdP rotates signing certs and the app still trusts the old cert, the next login can fail instantly.

Metadata-driven rotation helps, since the app can ingest the updated IdP certificate set from metadata instead of relying on a pasted certificate that nobody updates.

If you want a standards-level description of what SAML asserts and how profiles fit together, the OASIS SAML V2.0 Technical Overview lays out the pieces in a vendor-neutral way.

Why Time Skew Breaks SAML More Than People Expect

SAML is time-sensitive by design. Assertions carry timestamps and validity windows, often only a few minutes long.

If the IdP and the app servers disagree on time, the app may treat a fresh assertion as “not yet valid” or “already expired.”

A simple fix solves a lot of pain: make sure both sides use reliable time sync (NTP) and that the app allows a small clock skew window if the app supports it.

SP-Initiated Vs IdP-Initiated: What Changes In Practice

SP-Initiated

The user starts at the app. The app sends an AuthnRequest that can include details like requested auth context or a relay state to return the user to a specific page after login.

This is the flow most teams prefer because the app controls where the response should land, and troubleshooting has a clear starting line.

IdP-Initiated

The user starts at the IdP portal and clicks the app tile. The IdP sends a response to the app without a prior AuthnRequest from that app.

Some apps accept this cleanly. Some apps treat it as riskier because there’s no request to match, so they require extra checks like strict destination and audience validation.

Table: SAML Settings That Decide Whether Login Works Or Fails

The Most Common SAML Errors And What They Mean

“Invalid Signature”

This nearly always points to trust or certificate issues: wrong cert, expired cert, rotated cert not updated, or a response altered by a middle layer.

Start by checking that the app trusts the current IdP signing certificate from metadata and that the response is signed the way the app expects.

“Audience Is Invalid”

The AudienceRestriction value in the assertion doesn’t match what the app expects as its entity ID. This is often a copied identifier that looks close but is not exact.

Fix it by aligning the SP entity ID in the IdP configuration with the value the app documents as its audience/issuer requirement.

“Destination Mismatch” Or “Reply URL Mismatch”

The response was posted to an ACS URL that the app didn’t expect. It can be a missing path segment, http vs https, a trailing slash, or a region-specific domain.

Copy the ACS URL from the app’s SAML setup page and paste it into the IdP as-is. Then retest.

“Assertion Expired”

Either the assertion validity window is too tight for the real-world redirect chain, or server time is out of sync.

Confirm NTP sync on both ends, then widen the allowable skew or validity window if your app supports it and your security posture allows it.

“User Not Found” After A Successful Login

The IdP authenticated the user, yet the app can’t map the assertion to a local account. The NameID might be wrong, or the app expects a specific attribute for lookup.

Check what identifier the app uses as its user key, then align NameID or send the needed attribute in the assertion.

A Practical Way To Debug SAML Without Guessing

When SAML fails, don’t change five settings at once. Use a simple loop: capture, read, verify, change one thing, retest.

Capture The Response

Use a browser SAML tracer extension or your IdP/app logs to capture the SAML response. You need the raw assertion content, not just a generic error screen.

Read The Key Fields

Check issuer, audience, destination, NotBefore, NotOnOrAfter, NameID, and required attributes. These values usually point to the mismatch.

Verify The Trust Chain

Confirm the certificate used to validate the signature matches what the IdP is using right now. Rotations are a classic “it worked yesterday” cause.

Retest With A Single Change

Make one change, then retest. If you’re in a team, note what changed and why. It keeps the next person from repeating the same cycle.

What SAML SSO Does Well And Where It Can Feel Clunky

SAML is a strong fit for enterprise web apps because it’s widely supported, mature, and built around strong assertion validation rules.

It can feel heavier for modern app patterns that rely on APIs and mobile clients. In those cases, teams often reach for OAuth 2.0 and OpenID Connect.

Still, SAML remains a workhorse in many stacks. If you’re integrating a SaaS tool with a corporate IdP and the app offers SAML, you’ll likely run into it.

A Safe Setup Checklist Before You Roll SAML Into Production

Before broad rollout, a few quick checks save a lot of tickets.

• Confirm the IdP signing certificate chain and rotation plan.
• Lock in exact entity IDs and ACS URLs for each app environment.
• Decide NameID format and stick to it across apps where you can.
• Document required attributes and group/role mapping rules.
• Validate time sync on IdP and SP servers.
• Test SP-initiated and IdP-initiated flows if you plan to support both.
• Run a small pilot group first, then expand.

Recap: The One Sentence Mental Model

SAML SSO is a trust contract: the IdP authenticates the user, signs an assertion, and the app validates it to start a session without re-asking for credentials.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback