SAML SSO: what it is, how the login flow works, and how to set it up

SAML SSO means single sign-on built on SAML 2.0: the user signs in once at an identity provider (IdP), and every application that trusts that IdP accepts the signed XML assertion it sends. The user stops typing passwords into each app; the app stops storing them.

SAML is the protocol behind most enterprise SSO. When a buyer asks "do you support SAML SSO?", they mean: can our employees sign in to your product with our Entra ID, Okta or Ping identity without a separate account and password?

The three parties

The IdP and SP do not trust each other by default. They exchange metadata: the IdP publishes its endpoints and signing certificate, and the SP publishes its entity ID and assertion consumer service (ACS) URL.

How a SAML SSO login works

This is the SP-initiated flow, the standard one:

1. The user opens the application. The application has no session for them.
2. The SP builds an AuthnRequest and redirects the browser to the IdP's single sign-on endpoint.
3. The IdP checks whether the user already has a session. If not, it shows its sign-in page: password, passkey, MFA, social login, whatever the organization requires.
4. The IdP builds a SAML response containing a signed assertion and returns it to the SP. The response is usually delivered by an auto-submitting HTML form that POSTs to the SP's ACS URL.
5. The SP validates the signature, the issuer, the audience, the recipient and the time window. It maps the assertion's NameID and attributes to a local account and starts its own session.

Everything travels through the browser. The SP never needs a network path to the IdP, which is why SAML still works for on-premises applications behind a firewall.

There is also IdP-initiated SSO: the user starts at the IdP portal and clicks an app tile, which sends an unsolicited response to the SP. It is convenient for employee portals, but it removes the request ID check and needs stricter replay protection. See SP-initiated vs IdP-initiated SSO.

What is inside a SAML assertion

An assertion is XML. The parts that cause most integration bugs:

• NameID: the user identifier. Formats include emailAddress, persistent, transient and unspecified. Apps differ in what they accept; an email address is the common default, a persistent opaque ID is the better privacy choice.
• Attributes: email, display name, groups, roles, department. The SP reads them by name, so the names must match exactly.
• Conditions: audience (the SP's entity ID), NotBefore and NotOnOrAfter.
• Signature: normally on the assertion, sometimes on the response, sometimes both. The SP must verify the one it expects.

Metadata and certificates

SAML has no discovery document. Configuration is a manual exchange:

• From the IdP to the SP: the IdP's metadata XML contains its entity ID, SSO URL, SLO URL and signing certificate.
• From the SP to the IdP: the SP's entity ID, ACS URL, and optionally a signing certificate and logout URL.

Certificates are the most common cause of sudden outages: the IdP rotates its signing certificate, the SP still has the old one, and every login fails with a signature error. Run the two certificates in overlap and refresh metadata before the expiry date. See SAML certificate renewal.

Setting it up: a checklist

On the application (SP) side:

1. Expose an ACS endpoint that accepts an HTTP POST and validates the response.
2. Declare an entity ID and give it to the IdP.
3. Import the IdP metadata or paste its SSO URL and certificate.
4. Decide the NameID format and the attributes you need.
5. Decide whether you accept IdP-initiated responses. If yes, validate issuer, audience, recipient and replay cache strictly.
6. Test with a real account, then test an expired certificate and a wrong audience.

On the IdP side, in Casdoor for example:

1. Create or edit the application as a SAML application.
2. Set the Redirect URLs to the SP's ACS URL and the SAML reply URL to the same ACS URL; the reply URL is required for IdP-initiated login.
3. Set the entity ID if the SP requires one.
4. Configure attribute mapping and the NameID format.
5. Download the IdP metadata or certificate for the SP.
6. Assign users or groups.

Casdoor shows the metadata link and the IdP-initiated launch URL on the application's SAML tab. The SAML IdP setup guide walks through the fields.

Errors you will actually see

Most of these are configuration, not protocol bugs. Compare the exact strings on both sides before changing code.

SAML or OIDC?

Use OIDC for applications you build: it is JSON-based, has discovery, and works well on mobile and single-page apps. Support SAML because enterprise SaaS, procurement checklists and existing applications still require it. Most identity providers, including Casdoor, serve both, so one user directory can sign users in to old SAML apps and new OIDC apps. See SAML vs OIDC and OAuth vs SAML vs OIDC.

FAQ

What does SAML SSO mean? SAML SSO is single sign-on where the identity provider sends a signed SAML assertion to each application, so the user signs in once and the applications trust that one login.

Is SAML SSO secure? Yes, when the SP validates the signature, issuer, audience, recipient and time window correctly. Most SAML vulnerabilities come from applications that accept unsigned assertions or parse XML carelessly, not from the protocol itself.

Does SAML support MFA? Yes. MFA happens at the identity provider, before the assertion is issued. The application does not see which factors were used unless the IdP sends that as an attribute.

What is the difference between SAML SSO and LDAP? LDAP is a directory protocol: each application binds with a username and password and still shows its own login form. SAML is a federation protocol: the user signs in at the IdP and the application receives an assertion. LDAP is not single sign-on by itself.

How long does SAML SSO take to set up? A single connection is usually an hour of configuration plus testing. The long part is agreeing on attributes, NameID format, certificate rotation and who owns the IdP metadata.

Casdoor is an open-source identity provider with built-in SAML 2.0 support, including metadata, signed assertions, single logout and IdP-initiated login. Self-host it for free, or use the managed cloud from $9 per month with no per-user fees. Related reading: SAML assertions, SAML metadata and how to test SAML SSO.