What Is Single Sign-On (SSO), and How Can You Add It to an Existing Login?

How SSO works, how SAML and OIDC compare, and the steps to add enterprise SSO to a product that already has password login.

5 min read

On this page

Single sign-on (SSO) lets users sign in to several applications with one identity, managed by an identity provider (IdP). Instead of creating a password for your product, users authenticate with an account they already have: their company's Okta or Microsoft Entra ID tenant, or a Google account.

For B2B SaaS, SSO often stops being optional once you sell to larger companies. Their IT teams want to control who can access which tools, and to remove access in one place when someone leaves.

This guide explains how SSO works and how to add it to a product that already has its own email-and-password login.

How SSO works#

Three parties are involved:

The user, who wants to sign in.
The identity provider, which holds the user's account and verifies their identity.
Your application (the service provider or relying party), which trusts the identity provider's assertion.

The flow:

The user tries to sign in to your application.
Your application redirects them to the identity provider.
The user authenticates there, possibly already signed in from earlier.
The identity provider sends your application a signed statement of who the user is.
Your application validates it, finds or creates the user, and starts its own session.

Your application trusts a verified identity from the identity provider, then manages its own session.

SSO protocols: SAML and OIDC#

Two protocols dominate.

SAML 2.0 is an XML-based standard widely used in enterprise environments. The identity provider sends a signed XML assertion to your application.

OpenID Connect (OIDC) is built on OAuth 2.0 and uses JSON and JWTs. The identity provider returns a signed ID token.

	SAML 2.0	OpenID Connect
Format	XML assertions	JSON / JWT ID tokens
Common in	Enterprise IdPs, older systems	Modern IdPs, consumer and enterprise
Mobile and SPA support	Awkward	Designed for it
Setup	Exchange metadata and certificates	Client ID, secret, discovery URL

Enterprise customers may ask for either. Many SaaS products support both.

"Sign in with Google" is a form of SSO, typically using OIDC. Anyone with an account can use it.

Enterprise SSO is different in one important way: it's configured per customer organization. Each customer connects their own identity provider, and users from that company's email domain are sent to it. You'll need to manage a separate SSO configuration for each customer that uses it.

1. Separate identities from users#

If your user table stores a password hash and nothing else, add a way to link external identities. A common approach is an identities table with the provider or connection, the issuer, and the subject identifier from the IdP, linked to your user record.

Use the IdP's stable subject identifier, scoped to its issuer, as the key. Don't rely on email alone; it can change.

2. Decide how users reach SSO#

Options include:

A "Sign in with SSO" button that asks for an email or company identifier.
Detecting the email domain on your login form and redirecting to the right IdP.
A per-customer login URL.

Domain detection is common, but verify that a customer owns a domain before routing its users to their IdP.

3. Handle existing accounts#

Some users at a customer already have password accounts when SSO is enabled. Decide how to link them. A safe pattern is to link on first SSO login when the verified email matches and the domain belongs to the customer, then let the customer's admin require SSO for everyone.

4. Enforce SSO when the customer requires it#

Once a customer enables mandatory SSO, users from their domain shouldn't be able to bypass it with an old password. Keep an exception path for your support team and for a designated admin account in case the IdP configuration breaks.

5. Provisioning and deprovisioning#

SSO controls sign-in, but users can still have active sessions after they're removed from the IdP. Consider:

Shorter session lifetimes for SSO users.
Just-in-time provisioning on first login.
SCIM, a standard for automatically creating, updating and deactivating users from the IdP. Large customers often ask for it alongside SSO.

6. Give customers a setup experience#

Customer admins need a way to configure SSO: upload IdP metadata or enter OIDC details, test the connection, and see errors. Without this, every setup becomes a support ticket.

Build or buy#

Implementing SAML and OIDC with good libraries is achievable, but the long-term work is in per-customer configuration, debugging IdP-specific quirks, admin tooling and SCIM. Many SaaS teams use an authentication platform that supports enterprise SSO rather than building it all.

Security checklist#

Validate every assertion or ID token: signature, issuer, audience, expiry.
Protect against replay with nonces or assertion IDs.
Verify domain ownership before routing a domain to a customer's IdP.
Don't link accounts on unverified email addresses.
Log SSO configuration changes.
Keep a break-glass admin path.

SSO is not the same as integrations#

SSO establishes who a user is when they sign in to your product. It doesn't give your product access to that user's data in other applications. If you want to read a user's calendar or CRM, you need delegated authorization via OAuth, typically with different scopes, a separate consent step and long-lived tokens.

Pathfix OAuth addresses that second need: connecting your users' third-party accounts so your application can call those providers' APIs. It handles the OAuth flow, token storage, refresh and authenticated API passthrough across 350+ providers. It isn't an SSO or login product. Learn more about Pathfix OAuth or read OAuth vs OpenID Connect.

Frequently asked questions#

Is SSO the same as OAuth?#

No. SSO is a sign-in pattern; SAML and OIDC are protocols for it. OAuth is an authorization framework for API access, though OIDC is built on it.

Do I need SAML if I already support OIDC?#

Enterprise customers sometimes require SAML. Ask your target customers which IdPs and protocols they use.

What's SCIM?#

A standard for provisioning and deprovisioning users from an identity provider into your application automatically.