SSO vs Federation: One Login Across Apps, or One Identity Across Domains

Key takeaways

• SSO is a UX outcome — one login, many apps. Federation is the trust mechanism that lets one identity provider vouch for a user to another system.
• Internal SSO (same organization's app suite, single IdP) doesn't require federation. Cross-organization SSO almost always does.
• SAML and OIDC are federation protocols that produce SSO experiences; OAuth on its own is neither.
• B2B SaaS 'SSO' almost always means federated SSO — your customer's IdP federates into your app, per-Organization.

The clean distinction

The asymmetry: every federation deployment results in an SSO experience for the user; not every SSO experience requires federation. The internal app suite of a single organization (a custom HR app and a custom payroll app behind the same employee portal) can deliver SSO via shared session cookies, no SAML or OIDC required. The moment those apps need to accept identities from a different organization's IdP — or the moment one IdP serves users to many different applications it doesn't control — federation is the mechanism that scales.

	SSO	Federation
What it is	A user experience: one login, many apps	A trust mechanism: assert identity across systems
What you see	The user signs in once and uses several apps	The user is redirected to an IdP, then back with a signed assertion
Required protocol	None inherent — could be session cookies	SAML, OIDC, or similar
Crosses organization boundaries	Sometimes	Usually
Implies trust agreement	Implicit (internal)	Explicit (metadata exchange, signing keys)

When SSO doesn't need federation

A single organization running a suite of internal applications behind a shared session cookie achieves SSO without federation. The pattern:

• One identity provider (the company's central directory or a custom app login).
• All applications share a session-cookie domain (.example.com); the cookie identifies the user.
• No protocol exchange between IdP and apps — the cookie itself is the SSO mechanism.

This works as long as the apps live under one domain and one trust boundary. It breaks the moment the apps span domains (cross-site cookie restrictions in modern browsers), the moment external IdPs need to send users in, or the moment external apps need to consume users out. At any of those points, federation becomes the right tool.

When federation doesn't produce SSO

Less common but worth naming: federation can also deliver one-shot identity assertions without producing a durable SSO session. The pattern:

• A government identity service issues a verifiable credential to a citizen for a single tax-filing event.
• A B2B integration receives a one-time SAML assertion to bootstrap an API client identity.

Here the federation protocol carries the identity; the relying party uses it for the single interaction and may not create an ongoing session. The user has been federated but is not in an SSO state.

B2B SaaS: 'SSO' means federated SSO

In B2B SaaS the words are interchangeable in practice. When a customer's security questionnaire asks "do you support SSO?", the question means:

• Can the customer's IdP (Okta, Microsoft Entra, Google Workspace, Ping, JumpCloud, OneLogin, the customer's own) act as the identity provider for our application?
• Can the customer's employees sign in via that IdP, with the IdP carrying their identity into our application via SAML or OIDC?
• Can the customer configure this per-Organization, without involving our engineering?

That is federated SSO. The federation protocol is SAML or OIDC; the SSO experience is the user clicking "sign in with my company's IdP" and being redirected back to the app, authenticated.

The architecture that scales B2B SSO is per-Organization configuration (Enterprise SSO: SAML vs OIDC covers it in detail). Each customer's Organization has its own SAML or OIDC connection, its own IdP metadata, its own claim mapping. Without per-Organization configuration, B2B SSO breaks past the first few customers.

The CIAM platforms that ship per-Organization federated SSO as a primitive: WorkOS, Auth0 (Enterprise Connections), Frontegg, MojoAuth, SSOJet, Scalekit, Microsoft Entra External ID, plus self-hosted Keycloak and Ory.

The mechanics: redirect, assert, trust

A federated SSO login looks like this from the application's perspective:

1. User clicks "Sign in with [my company]".
2. Application redirects the user to the IdP (the federation URL: SAML SSO endpoint, or OIDC authorization endpoint).
3. IdP authenticates the user (password + MFA, passkey, whatever the IdP requires — the relying party doesn't care about the mechanism).
4. IdP redirects the user back to the application with a signed assertion (SAML Response, or OIDC authorization code → ID Token).
5. Application validates the signature against the IdP's prior-agreed signing key, validates the assertion timing, audience, and any other constraints, extracts the user's identity from the assertion, and creates a local session.

The trust establishment happened earlier: the application's administrator (or, ideally, the customer's IT admin via self-service UI) uploaded the IdP's metadata XML (SAML) or pasted the issuer URL (OIDC). That bound the application to trust assertions signed by that specific IdP for that specific connection. The runtime exchange just rides on top of that pre-established trust.

Implementation guidance

1. In B2B SaaS, treat 'SSO' as a synonym for 'federated SSO'. The customer means SAML or OIDC; ship both per-Organization, with self-service IdP setup.
2. In an internal-only app suite, plain session cookies may suffice if everything lives under one domain. Adopt federation when the boundaries grow.
3. Use a CIAM platform that handles per-Organization federation as a primitive. Building it on top of a generic SAML / OIDC library is a meaningful engineering project; the CIAM market exists to solve it.
4. Pair SSO with SCIM for lifecycle management. SSO authenticates; SCIM provisions and deprovisions. See SCIM vs SAML for the split.
5. Document the supported federation protocols. Customer procurement teams ask in writing; the answer they want is 'both SAML 2.0 and OIDC, per-Organization, with self-service IdP setup'.