What is Federated SSO (Single Sign-On)?

Federated single sign-on is the mechanism that lets a user log in once at one organization and access services run by another, without creating a second account or re-entering credentials. It is the plumbing behind "Sign in with Google" for third-party apps, behind enterprise SSO into SaaS vendors, and behind cross-brand login flows for media conglomerates.

Understanding the difference between regular SSO and federated SSO matters when you are designing an authentication strategy that spans more than one organization or brand.

SSO vs. federated SSO

Plain SSO operates inside a single trust boundary. One company runs both the identity store and the applications. Users authenticate once and gain access to every app in that boundary.

Federated SSO crosses trust boundaries. Two (or more) organizations agree to trust each other's authentication assertions. User identity lives at the identity provider (IdP); the service provider (SP) accepts a signed assertion from that IdP as proof that the user is who they claim to be. No password ever crosses the boundary.

How federated SSO works

The basic flow:

• User tries to access a resource at the service provider (SP).
• SP redirects the user to the identity provider (IdP), including an authentication request.
• If the user is not already authenticated at the IdP, the IdP authenticates them (password, MFA, passkey, whatever the IdP enforces).
• IdP issues a signed token, assertion, or authorization code and redirects the user back to the SP.
• SP verifies the signature against the IdP's public key, extracts the user identity and any claims, and starts a session.

The user experiences one redirect and one login screen. Behind the scenes, two organizations have exchanged cryptographically signed evidence of identity.

The protocols that actually implement it

• SAML 2.0. XML-based, mature, still dominant in enterprise SSO into SaaS apps. Most B2B vendors support it.
• OpenID Connect (OIDC). Built on OAuth 2.0, JSON/JWT-based, the modern default for new integrations. Easier to implement on mobile and SPAs than SAML.
• OAuth 2.0. Technically an authorization protocol, but the implicit and authorization code flows are commonly used for federated identity in social-login scenarios.
• WS-Federation. Microsoft-flavored, still found in older Active Directory Federation Services deployments.

For new builds in 2026, OIDC is the right default. SAML stays around because enterprise procurement still demands it.

Who needs federated SSO?

• SaaS vendors selling to enterprises. Enterprise IT will not provision users individually in your app; they will federate from their corporate IdP (Okta, Entra ID, Ping, etc.).
• Media and content groups with multiple brands. One identity should work across every property in the portfolio.
• Consumer apps offering social login. "Sign in with Apple/Google/Microsoft" is federated SSO underneath.
• Partner ecosystems. When customers, suppliers, or partners need access to portals you run, federation lets them use their own credentials, though internal admin accounts with elevated rights still belong under privileged access management rather than customer-facing federation.

What to look for in a CIAM platform that supports federated SSO

Whether you are evaluating Auth0, Okta CIC, ForgeRock, Ping, or a similar CIAM platform, the federation feature checklist is roughly the same:

• Multi-protocol support. SAML, OIDC, OAuth 2.0, and ideally WS-Federation for legacy.
• Acting as both SP and IdP. Your product probably needs both: accept federated logins from enterprise IdPs (SP role) and issue identity to downstream apps (IdP role), a split that tracks the broader IAM vs. CIAM distinction between workforce identity and customer identity.
• Just-in-time provisioning. Create the local user account on first federated login, with attribute mapping from the IdP's claims.
• SCIM for ongoing user lifecycle. Federation handles login; SCIM handles provisioning, updates, and deprovisioning.
• Per-tenant IdP configuration. Each enterprise customer plugs in their own IdP without touching shared config.
• Strong key management. Certificate rotation for SAML, JWKS rotation for OIDC, no manual outages.
• Audit logging. Every assertion, every login, retrievable for compliance.
• Scale and uptime. Federation sits in front of every user session. Five-nines uptime and the ability to handle login spikes are non-negotiable for B2C scale.
• Global data residency. If you serve customers under GDPR, CCPA, or other regional laws, choose where identity data lives.

Frequently Asked Questions

What is federated SSO?

Federated SSO is the mechanism that lets a user log in once at one organization and access services run by another, without creating a second account or re-entering credentials. A service provider trusts a signed identity assertion issued by an identity provider, so no password crosses the boundary between organizations.

How is federated SSO different from regular SSO?

Regular SSO operates inside a single trust boundary, where one company runs both the identity store and the applications. Federated SSO crosses trust boundaries: two or more organizations agree to trust each other's authentication assertions, with the identity provider authenticating the user and the service provider accepting a signed assertion as proof.

What protocols implement federated SSO?

The main protocols are SAML 2.0, OpenID Connect (OIDC), OAuth 2.0, and WS-Federation. SAML remains dominant in enterprise SSO into SaaS apps, OIDC is the modern default for new integrations, and WS-Federation still shows up in older Active Directory Federation Services deployments.

Does a password ever leave the identity provider in federated SSO?

No. The identity provider issues a signed token, assertion, or authorization code to prove who the user is, and the service provider verifies that signature against the identity provider's public key. The user's password itself never crosses the boundary between organizations.

Who typically needs federated SSO?

SaaS vendors selling to enterprises, media groups running multiple brands, consumer apps offering social login, and partner ecosystems that give customers or suppliers portal access all rely on federated SSO so users can authenticate with credentials they already hold elsewhere.

In conclusion

Federated SSO is no longer a nice-to-have. For enterprise SaaS it is procurement table stakes. For consumer products it is a conversion lever and a security boundary. Pick OIDC for new integrations, keep SAML in the toolkit for enterprise deals, and make sure whichever CIAM platform you build on treats federation as a first-class feature rather than a bolt-on.