IAM building block · 3 min read
What is identity federation?
Short answer
Identity federation is an arrangement in which an application (relying party or service provider) accepts sign-ins performed by an external identity provider, based on exchanged metadata and keys, so users authenticate once with their home organization and reach many applications without separate passwords.
Key takeaways
- Federation rests on metadata: entity IDs, endpoints and signing keys exchanged in advance.
- Validate every assertion fully: signature, issuer, audience, recipient, time window and InResponseTo.
- Plan certificate rollover; expired signing certificates are among the most common causes of SSO outages.
Federation is what makes single sign-on work across organizational and technical boundaries. Your employees sign in to dozens of SaaS products with their company account; your customers sign in with Google or Apple; a university researcher uses their home institution's login at a partner's lab. In each case, an application trusts a sign-in performed somewhere else.
Who are the parties?
An identity provider that authenticates users, and relying parties (service providers) that trust it.
| Role | SAML name | OpenID Connect name |
|---|---|---|
| Authenticates users, issues statements | Identity Provider (IdP) | OpenID Provider (OP) |
| Consumes statements, grants access | Service Provider (SP) | Relying Party (RP) / client |
| Statement | Assertion (XML) | ID token (JWT) |
| Configuration exchange | Metadata XML | Discovery document + client registration |
How is trust established?
By exchanging metadata in advance: identifiers, endpoints and public keys.
In SAML, both sides exchange metadata documents with the entity ID, endpoints (SSO, ACS, SLO) and signing and encryption certificates. In OpenID Connect, the provider publishes /.well-known/openid-configuration and a JWKS with its signing keys; the client registers its redirect URIs and receives a client ID. Either way, trust rests on the keys: whoever holds the IdP's signing key can sign in as anyone at every relying party. Protect it accordingly.
What happens during a federated sign-in?
The relying party redirects to the identity provider, the user authenticates, and a signed statement comes back for validation.
- User opens the application.
- Application sends an authentication request: a SAML
AuthnRequestor an OIDC authorization request. - IdP authenticates the user (or reuses an existing session).
- IdP returns a signed assertion or an authorization code exchanged for an ID token.
- Application validates it and creates its own session.
Decode real messages with the SAML Decoder to see each field.
What must the relying party check?
Signature, issuer, audience, destination or recipient, the validity window, and that the response answers a request it made.
For SAML: the XML signature over the assertion or response, using the IdP's certificate from metadata; Issuer; Audience equals your entity ID; Recipient and Destination equal your ACS URL; NotBefore and NotOnOrAfter with small clock skew; InResponseTo matches your request ID; and exactly one assertion. Libraries handle this, but configuration errors (accepting any certificate, ignoring audience) are common. For OIDC, see the checks in the OpenID Connect article.
Which attributes should be released?
Only those the application needs, with a stable, non-reassignable identifier.
Email addresses change and get reused. Prefer a persistent or pairwise identifier, and send email, name and groups as attributes. Be careful with group claims: sending every group a user belongs to bloats assertions and leaks your structure. Many IdPs can filter groups per application.
What causes federation outages?
Expired or rotated certificates, clock skew and changed endpoints.
Keep an inventory of every federation partner with certificate expiry dates. Publish metadata at a stable URL so partners can refresh automatically. Use overlapping certificates during rollover. Monitor clock synchronization on IdP and SP servers. For hardening of the IdP itself, see locking down a federation server.
Questions
Should I use SAML or OpenID Connect?
Use what the application supports well. For enterprise SaaS, SAML 2.0 is still the most widely supported. For new applications, mobile apps and APIs, OpenID Connect is simpler to implement and fits OAuth-based APIs.
What is a federation like eduGAIN or InCommon?
Multi-party federations aggregate metadata from many identity providers and service providers, mostly in research and education, so members can trust each other through one agreement and one metadata feed.
What is WS-Federation?
An older Microsoft-led protocol used by AD FS and Windows Identity Foundation for browser sign-in. It is still supported in Microsoft products, but new integrations usually use SAML 2.0 or OpenID Connect.