← All terms
Identity Federation

What is Identity Federation?

Identity federation lets separate organizations or systems trust one identity provider, so users sign in once and access resources across domain boundaries.

Last updated: 14 July 2026

How identity federation works

Federation establishes a trust relationship between two parties: an identity provider (IdP) that authenticates users, and a service provider (SP) that hosts the application or resource. The trust is anchored in cryptography. The SP holds the IdP's public signing certificate, and the IdP knows the SP's metadata, endpoints, and expected audience values.

When a user tries to access the service, the SP redirects them to the IdP. The IdP authenticates the user against its own directory and policies, then sends back a signed assertion or token containing the user's identity and attributes. The SP validates the signature and starts a session without ever seeing the user's password. SAML 2.0, OpenID Connect, and WS-Federation are the standard protocols that carry this exchange.

Why identity federation matters

Without federation, every application maintains its own user store and password database, and every partnership or acquisition means duplicating accounts. Federation keeps identity in one authoritative place while letting any number of applications, business partners, and cloud platforms consume it. Users get one login; security teams get one place to enforce MFA, session policies, and offboarding.

Federation is also what makes B2B and multi-organization scenarios workable. A supplier's employees can access your portal using their own corporate credentials, and when their employer disables an account, access to your systems ends with it. Responsibility for authentication stays with the organization that actually knows the user.

Identity federation in practice

A federation project starts by deciding which side of the trust you are on. If you run the workforce directory, you act as the IdP and connect SaaS and internal applications as SPs. If you host an application that partners or customers log into, you act as the SP and accept assertions from their IdPs. Many organizations play both roles at once.

The practical work is exchanging metadata, mapping attributes such as email, groups, and roles into the claims each application expects, and testing signature validation and session lifetimes. Monosign can act as both a SAML 2.0 service provider and identity provider, and also federates over OIDC and OAuth 2.0 with PKCE as well as WS-Fed, which covers both sides of these trust relationships.

Frequently asked questions

What is the difference between federation and SSO?
Single sign-on is the user experience: authenticate once, access many applications. Federation is the trust architecture that makes SSO possible across different security domains, organizations, or vendors. SSO inside one company can work without federation, but SSO that spans company or platform boundaries always relies on federated trust.
Which protocol should I use for federation: SAML or OIDC?
Use what your applications support. Established enterprise software usually offers SAML 2.0, while modern web and mobile applications favor OpenID Connect. There is no need to choose one platform-wide; a capable identity provider speaks both and presents a single policy to users either way.
Is federation secure if the identity provider is compromised?
Federation concentrates authentication at the IdP, which makes protecting it critical. Strong MFA, short assertion lifetimes, signing key rotation, and monitoring of the IdP reduce that risk. The trade-off usually favors federation, because one well-defended IdP is easier to secure than hundreds of application password databases.