SAML and SSO: How They Differ and How to Implement SAML SSO in a SaaS App

Jul 12, 2023 | Last Updated: Oct 11, 2026 |

Aviad Mizrachi

| 11  min read |

Share

Share on LinkedInShare on FacebookShare on TwitterShare on Email

Single sign-on (SSO) is the experience of signing in once and reaching several applications. SAML is one protocol that delivers it. A customer’s identity provider (IdP), such as Okta or Microsoft Entra ID, sends a signed XML response to your application. Your application acts as the service provider (SP), validates it, and signs the user in. OpenID Connect (OIDC) is the other common SSO protocol, so “SSO” doesn’t always mean SAML.

For a B2B SaaS product, SAML SSO usually arrives as a customer requirement: a buyer’s IT team wants its employees to log in with the company IdP. This guide covers the difference first, then the setup, tests and troubleshooting needed to run SAML connections for many customers.

In this article:

What Is Single Sign-On?

Single sign-on is an arrangement where a user authenticates once with a trusted identity provider and then reaches multiple applications without entering credentials again. Each application relies on the IdP’s statement that the user has authenticated, instead of keeping its own password.

In B2B SaaS, the IdP usually belongs to the customer, so your application holds one or more SSO connections per customer organization. The customer’s IT team controls authentication at their IdP and can enforce policies such as MFA there. Disabling a user at the IdP can stop future SSO sign-ins. Removing that person’s membership in your application, and ending sessions already issued, needs its own deprovisioning and session design. For SSO types and protocols, see our single sign-on guide.

What Is SAML?

Security Assertion Markup Language (SAML) 2.0 is an OASIS standard for exchanging authentication and attribute statements between an identity provider and a service provider. The IdP authenticates the user and returns a response containing an assertion: who the user is, when and how they authenticated, and optional attributes such as email or groups. The SP validates it and creates its own session.

Two practical terms recur in setup. The Assertion Consumer Service (ACS) URL is the SP endpoint where the IdP posts responses. Metadata is the XML each side publishes, with entity IDs, endpoints and signing certificates. For message anatomy, see our SAML protocol guide.

How Are SAML and SSO Related?

SSO is the goal and SAML is one way to deliver it. SAML defines the messages and validation rules that let an IdP vouch for a user to an SP. SSO is the resulting user experience. You can deliver SSO without SAML, most often with OpenID Connect.

How Does SAML Work?

In SP-initiated SSO, the most common flow, the user starts at your application:

1. The user identifies their organization, for example by entering a work email or using an organization-specific login link. Your app selects that customer’s connection.
2. Your app redirects the browser to the customer’s IdP with an authentication request that carries a unique ID.
3. The IdP authenticates the user under its own policy, for example a password plus MFA, or an existing IdP session.
4. The IdP posts a signed response to your ACS URL through the browser.
5. Your app validates the response, maps the user to the right customer account, and creates its own session.

In IdP-initiated SSO, the user starts from the IdP’s app dashboard and the IdP sends a response that no request preceded. The SAML profiles allow this, but your app can’t correlate it with a login it started, which removes one protection. Test it separately if you support it.

A valid SAML response proves who the user is. It doesn’t decide what they can access in your app. The application still has to check that every resource belongs to the user’s active customer account.

Before you configure a SAML connection: the setup checklist

Agree on owners first. You control your application and SSO environment. The customer controls its IdP application and who is assigned to it. Agree which customer account the connection serves, and how you’ll test one permitted user and one user who must be denied.

Exchange these values:

• From you (SP): the ACS URL, SP entity ID, and any other values your integration asks the customer to register. Use your environment’s real values, not example URLs.
• From the customer’s IdP: issuer/entity ID, SSO endpoint, signing certificate or metadata (a metadata URL where possible), the NameID format, and which attributes it sends. Confirm whether it sends group names, group IDs or no groups.
• From your application team:
  • the intended customer account and its admin owner
  • the approved email domains and routing behavior
  • the default role
  • what happens to a person who authenticates but has no membership yet

A matching email domain is a routing clue, not proof that someone may access every account on that domain.

Settle your production domain before customers configure their IdPs. Changing the ACS or redirect URL later means every customer must update their side. Decide who will watch IdP certificate expiry dates.

How to implement SAML SSO in your SaaS app, step by step

1. Enable SAML for your environment, separately from any customer connection

Turning on SAML as a protocol for your application is a different task from adding one customer’s connection. Set your SP entity ID and ACS URL in a test environment first. If your own code implements the SP rather than a managed identity platform, it also owns:

• trusted-key management
• response validation
• request correlation
• identity mapping
• session creation

Use a maintained SAML library and a security review, never a hand-written XML parser.

2. Create the customer’s connection

The customer’s IdP admin creates a SAML application with your SP values. You attach the returned IdP values to the intended account’s connection, or let the customer’s admin do it through a self-service setup screen. Import metadata where possible, then verify the parsed endpoint and certificate. A successful upload doesn’t prove you attached it to the right account. Decide who may change a live connection and who approves IdP or certificate changes.

3. Decide how users are routed and identified

• Routing: email-domain lookup, an organization-specific login URL, or an organization picker. Email-domain routing needs proof of domain ownership, typically a DNS TXT record. If two customer accounts can share a domain, define in advance whether to block, choose a default, or require an explicit account hint.
• Identity: if you implement the SP yourself, key SSO users by the connection plus a stable identifier from the IdP, for example a persistent NameID when configured, or another immutable identifier. Don’t key them by email alone. NameID formats include email, persistent and transient values, so not every NameID is stable.

4. Define membership and role mapping

Decide whether SSO can create a user on first login (just-in-time provisioning) and what happens to someone without approved membership. Choose a default role, optional IdP-group-to-role mapping, and whether mapping is evaluated only at first login or on every login. Keep three things separate: the external identity, the customer-account membership, and the application permissions. JIT provisioning can’t tell you when someone leaves. Use SCIM or another directory sync for that (what SCIM is, deprovisioning).

5. Validate every response before signing anyone in

If you implement the SP yourself, or want to check your provider’s guarantees, reject the login unless all of these pass:

• Status: the top-level StatusCode is Success (the value ending in status:Success).
• Signature: a valid signature from the certificate you hold for that customer’s IdP covers the identity data you consume. Under the OASIS SAML 2.0 errata (E26), the signature over a response delivered by HTTP POST can be on the Response or on each Assertion. Don’t trust a certificate supplied inside the message (KeyInfo), and reject weak algorithms such as SHA-1.
• Signed content is the content you use: read the subject and attributes only from the signed element. This is the main defense against signature-wrapping attacks.
• Issuer matches the IdP entity ID configured for that connection.
• Audience contains your SP entity ID.
• Destination and Recipient match your ACS URL exactly, including scheme and path.
• Timing: NotBefore and NotOnOrAfter are honored with only a small clock-skew allowance. The spec doesn’t set one, so keep it to minutes.
• InResponseTo matches an outstanding request your app issued (SP-initiated flows).
• Replay: keep accepted assertion IDs until they expire and reject repeats, as the SAML profiles require for bearer assertions.

6. Handle RelayState and IdP-initiated login safely

If RelayState carries a URL, validate it against an allowlist of your own paths so it can’t be used as an open redirect. If you support IdP-initiated login, enforce the replay checks and short validity windows, and send users to a fixed default page.

7. Run the rejection tests, not only the happy path

Test a normal SP-initiated login end to end: correct IdP, correct ACS, correct account context, and access only to that account’s resources. Then run the cases that must fail:

1. Wrong connection: a login for Customer A must not be satisfied by a response from Customer B’s IdP.
2. Wrong response values: reject each of these:
   • a non-success status
   • the wrong issuer
   • the wrong audience
   • the wrong destination or recipient
   • an expired response
   • an invalid signature or tampered attribute
   • a replayed response
   • an unmatched InResponseTo
3. No membership: a successful authentication must not become access unless your onboarding rules allow it.
4. Cross-tenant resource: after a valid Customer A login, try to read a Customer B object or list. Nothing should leak: no rows, counts or exports.
5. Changed group or certificate: change an IdP group or rotate a test signing certificate. Record when new logins reflect it and whether the old configuration is still trusted.

Record results separately for SAML validation, account routing, membership and resource access. A successful login doesn’t cover the cross-tenant checks.

8. Plan certificate changes as an operation

IdP signing certificates expire and customers rotate them on their own schedule. When a customer plans a rotation, get the new metadata and the cutover time. Test a login with the new certificate, confirm which certificate the connection currently trusts, and keep a rollback contact. If you build the SP yourself, allowing two trusted certificates for an agreed overlap window avoids a hard cutover. With a managed platform, verify how it handles replacement rather than assuming zero-downtime rotation.

9. Decide on logout and session length

SAML defines a Single Logout (SLO) profile for ending sessions across participants. In practice, logout behavior depends on the IdP, SP, binding and browser flow, and the protocol can’t guarantee completion across every participant. If you implement SLO, test it with each IdP you support and define what happens to your application’s local session when the wider logout fails.

SAML SSO troubleshooting: common errors and causes

Start from the stage that failed, not a guess about the IdP.

Treat SAML responses as sensitive. They can contain names, emails and group memberships. Inspect them with an approved local tool, redact before sharing, and don’t paste a production SAMLResponse into a third-party online decoder. For what a decoder does and when it’s safe to use, see SAML decoder methods and best practices.

Build it yourself or use a CIAM platform?

Building SAML SSO yourself gives you full control. It also makes you responsible for everything above: strict validation, per-customer connections, domain verification, certificate changes, admin self-service, IdP-specific quirks and ongoing patching. If identity isn’t a core product capability, compare the engineering and operating cost of maintaining SAML yourself with the cost and dependency of a managed CIAM or SSO service. The answer changes with:

• customer count
• federation requirements
• compliance constraints
• how much self-service administration you need

How to evaluate SSO providers covers selection criteria.

SAML SSO with Frontegg

Frontegg supports SAML and OIDC for customer SSO, with SSO configured per customer account. (SSO overview)

• Environment vs connection. SAML is enabled for the environment, where you set the ACS URL, SP entity ID and redirect configuration. Each customer’s IdP connection is then managed on that account, in the Frontegg portal or through the API. Request signing is optional, and you configure it separately. (environment SAML setup)
• Self-service setup. You can expose an SSO page in Frontegg’s admin portal so a customer’s admin adds their own SAML connection, with IdP guides for Okta, Google, Microsoft Entra ID, OneLogin, PingIdentity, JumpCloud, Rippling and custom SAML 2.0 IdPs. (self-service SAML)
• Domains and routing. Customers claim email domains and verify them with a DNS TXT record. Users are routed to SSO by email domain. If accounts share a domain, the optional cross-tenant domain sharing setting lets you block the login or use the first-created configuration, and a tenantId login parameter routes to a specific account’s SSO. The hint selects a login route; it doesn’t authorize access to that account’s data. (self-service SAML, multi-tenant SSO)
• IdP-initiated login. Users can also start from their IdP. When their domain maps to SSO configurations in more than one account, they’re sent to the account where the connection they logged in through is applied. (multi-tenant SSO)
• Roles. Every user who signs in through an SSO configuration gets that configuration’s default role. Users in IdP groups you’ve mapped to other roles get those roles in addition. By default, roles are assigned on the user’s first SSO login; re-checking groups on every login is enabled per environment on request. (environment SAML setup, self-service SAML)
• Troubleshooting. Failed logins appear as Tenant SSO Failed events with error and reason fields. Frontegg’s guide checks the response’s nameId (expected to carry the user’s email), Destination, Audience and certificate against the connection. (SSO troubleshooting)
• Provisioning. Pair SSO with SCIM so customers can deprovision users from their IdP. See SSO + SCIM.

To see SAML SSO set up with your own IdP, book a demo.

FAQ

Is SAML the same as SSO?

No. SSO is the experience of signing in once to reach several apps. SAML is one protocol that delivers it, and OIDC is another.

Should a B2B SaaS app support SAML, OIDC or both?

It depends on what your customers’ IdPs and IT teams require. Many B2B apps support both and let the customer choose. See OIDC vs SAML.

Does SAML provision or deprovision users?

SAML authenticates users at sign-in and can carry attributes that support just-in-time creation. It doesn’t tell your app when someone is removed. Use SCIM or directory sync for that.