Glossary
Identity federation is an arrangement in which multiple systems or organizations agree to trust a shared identity provider, so a user can access resources across different domains with a single identity. It’s the trust framework that makes single sign-on work beyond the boundaries of one application or company.
Where SSO is the experience (log in once, reach many apps) federation is the underlying agreement about whose authentication everyone will trust, and how that trust is proven.
Federation runs on open standards that define how a trusted claim about a user passes between an identity provider and a relying party:
In each case, the relying party accepts a signed token from a provider it trusts, rather than maintaining its own account and credential for the user. The signature is what makes the claim trustworthy without a live database lookup.
Three common patterns: a customer using social login to access a service (consumer federation); an employee reaching a SaaS app through their corporate IdP (workforce federation); and two businesses granting each other’s users access to shared systems (B2B federation). All three rest on the same principle: authenticate once, with a trusted provider, and carry that trust across domains.
Federation means fewer credentials, less duplicated account data, and a cleaner security model where authentication happens in one governed place. The caveat is inherent: a federated relationship is only as strong as the identity provider behind it and the authentication it performs. If the IdP is weakly protected, every relying party inherits that weakness. Strong, phishing-resistant authentication at the IdP is therefore a shared concern across everyone in the federation, which is one reason organizations care so much about who their identity provider is and how it authenticates.
The everyday shapes of federation are worth recognizing. In workforce settings, an employee reaches dozens of SaaS applications through the corporate identity provider, one account, centrally governed, deprovisioned in one place when they leave. In consumer settings, "continue with" buttons federate identity from a large social provider to a smaller service. In B2B, two organizations establish trust so partners can access shared systems without maintaining separate accounts. Each pattern trades local account management for trust in a central provider.
That trade brings real benefits (fewer credentials, less duplicated data, centralized policy) and one concentrated dependency. If the identity provider is unavailable, everything that federates to it is affected; if it’s compromised, that compromise propagates to every relying party. This is why mature federation pairs standards-based trust with strong authentication at the IdP and clear contingency planning. Federation doesn’t remove risk so much as concentrate and centralize it, which is an advantage only if the center is well protected.
What standards enable identity federation?
Primarily SAML, OAuth 2.0, and OpenID Connect (OIDC).
What’s the difference between federation and SSO?
Federation is the trust relationship between systems; SSO is the user-facing experience that federation makes possible.
Is social login a form of federation?
Yes. It federates identity from a consumer provider to the service the user is accessing.
What’s the risk in federation?
The whole federation inherits the strength (or weakness) of the identity provider’s authentication.
Related: Single Sign-On (SSO) · Identity Provider (IdP) · SAML · OpenID Connect (OIDC) · OAuth 2.0
