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.