Identity federation
Also known as: federated identity
An agreement between organisations to trust each other's logins, so a person proven at home is let in elsewhere.
Draft - this entry has not been reviewed yet.
Formal
A trust arrangement in which one or more services accept signed statements about a user from an identity provider run by another organisation, instead of keeping their own accounts and passwords for that user.
In plain English
Like countries that accept each other's passports - the border guard does not issue you a new one, but trusts the country that did.
In practice
A researcher at a Danish university opens a data portal run by another university and is sent to her own university's login page; after she signs in there, the portal lets her in without a new account.
Why it matters
Fewer separate accounts means fewer passwords to steal and forget, and when someone leaves, closing one home account shuts every linked door at once.
Technical deep dive
A federation has three roles: the identity provider (IdP, or OpenID Provider in OIDC) that authenticates the subscriber, the relying party (RP, or service provider in SAML) that consumes assertions, and the subscriber in between. Trust is technical before it is contractual: parties exchange metadata listing entity identifiers, endpoints and signing certificates, as SAML metadata XML or as an OIDC discovery document with a JWKS URI. In bilateral federation each pair configures the other by hand. In multilateral federation an operator vets members and publishes signed aggregate metadata; the Danish research federation WAYF, in operation since 2008, works as a hub that also imports services from the global eduGAIN interfederation. In the Danish public sector, NemLog-in acts as an identity broker between MitID and service providers, using the OIOSAML profiles.
NIST SP 800-63C-4 grades federation assurance. At FAL1, bearer assertions may target more than one RP and injection protection is recommended; FAL2 requires audience restriction to a single RP, strong protection against assertion injection and a trust agreement established before the transaction; FAL3 additionally requires the RP to verify that the subscriber controls an authenticator, through a holder-of-key assertion or a bound authenticator, so a stolen assertion is useless on its own. A typical assertion carries issuer, subject identifier, audience, issue and expiry times, authentication time and context, and attributes. Pairwise pseudonymous identifiers, such as OIDC's pairwise subject type or a SAML persistent NameID, stop colluding RPs from correlating a user.
Protocol choice follows the client: SAML 2.0 for browser-based enterprise apps, OpenID Connect for web, mobile and API scenarios, and WS-Federation mainly in legacy Microsoft estates. Federation covers authentication only; account creation downstream is handled either just-in-time from assertion attributes or by separate provisioning via SCIM. Single logout across federated RPs is notoriously unreliable.
The main risk is concentration. Whoever holds the IdP's token-signing key can mint valid assertions for every RP: the "Golden SAML" technique, described by CyberArk in 2017, was used in the SolarWinds campaign, and in 2023 Storm-0558 forged tokens for Exchange Online accounts with a stolen Microsoft consumer signing key because of a validation flaw, which the US Cyber Safety Review Board judged preventable in its April 2024 report. Mitigations are HSM-protected signing keys, rotation, and RPs that pin the expected issuer and key. RPs must also choose which attributes to trust: using a mutable or unverified email claim as the account key has enabled account takeover. Federation differs from single sign-on in that it crosses organisational trust boundaries, whereas SSO can exist inside one organisation.
What to learn first
Everything this builds on, foundations first.
- Digital identity
- →Credential
- →Authentication
- →Identity provider
- →Identity federation
Relationships
- Requires
- Identity provider
- Implemented by
- OpenID Connect (OIDC)SAML
- Used with
- Single sign-on (SSO)
Sources & further reading
Standards & official texts
- NIST SP 800-63C - Digital Identity Guidelines, Federation and Assertions · NIST
- NIST SP 800-63C-4 - Federation and Assertions (Federation Assurance Levels) · NIST
Official documentation
- CSRB - Review of the Summer 2023 Microsoft Exchange Online Intrusion · Cyber Safety Review Board (CISA)
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…