Identity federation is an arrangement in which separate organizations agree to trust each other’s sign-in decisions, so a person verified by one can use services run by another. Instead of every website keeping its own password for you, one trusted party vouches for you and the others accept that statement.
This article looks at federation as a trust relationship: who agrees to what, how that agreement is expressed in technical terms, and what happens when it breaks. Operational management, single sign-on mechanics and individual protocols such as SAML and OpenID Connect are covered in separate guides.
Why Organizations Agree to Trust a Stranger’s Login
Picture a university researcher who needs access to a partner lab’s data portal. Without federation, the lab must create, verify and later delete an account for every visiting researcher. With federation, the lab accepts the university’s statement that this person is a current, verified staff member.
The appeal is a division of labor. The home organization already knows the person, checked their identity when hiring them and will disable their account when they leave. The partner organization avoids duplicating that work and the risk of forgotten accounts that never get removed.
For the person, the benefit is fewer passwords and one familiar sign-in page. For both organizations, the benefit is that identity information stays with the party best placed to keep it accurate. That simple idea sits behind workplace cloud apps, research networks and many government login schemes.
The Three Roles in Every Federation
Every federation involves three roles. The user, sometimes called the subject, is the person trying to reach a service. The identity provider, or IdP, is the system that authenticates the user, meaning it checks that they are who they claim to be.
The relying party, or RP, is the application or service that relies on the identity provider’s answer instead of checking credentials itself. In SAML terminology the relying party is called a service provider, but the role is the same: it consumes a statement about the user and decides whether to grant access.
The statement passed between them is called an assertion in SAML or a token in OpenID Connect. It typically says who the user is, when and how they signed in, and which attributes, such as name or department, the provider is willing to share. The relying party then applies its own access rules.
Keeping these roles separate matters. The identity provider answers who the person is; the relying party alone decides what that person may do inside its service. Mixing the two leads to confusing ownership when access must be granted, changed or revoked.
How Trust Is Expressed in Technical Terms
Trust in a federation is not a handshake; it is configuration. Each side publishes information about itself, usually called metadata, and the other side imports it. Metadata tells a partner where to send users and which cryptographic keys to expect.
- Entity identifiers: unique names that tell each party exactly which partner it is dealing with.
- Endpoints: the web addresses where sign-in requests and responses must be sent.
- Signing keys or certificates: public keys used to verify that an assertion really came from the expected provider.
- Attribute agreements: the list of user details the provider releases and the relying party expects.
- Policy references: statements about assurance level, logging and acceptable use that both sides accept.
Digital signatures are the core of this trust. When an identity provider signs an assertion with its private key, any relying party holding the matching public key can confirm the assertion was not forged or altered in transit. If the keys or endpoints are wrong, federation either fails or becomes unsafe.
Federation Models and How Partners Connect
Federations differ in how many parties take part and who coordinates them. The model chosen shapes how quickly new partners can join, who carries responsibility for mistakes and how much each organization must configure on its own.
Bilateral Federation
In a bilateral arrangement, two organizations configure trust directly with each other. A company might connect its workforce identity provider to a single payroll service. This is simple to reason about and easy to audit, but it scales poorly. Fifty partners mean fifty separate configurations, each with its own keys, attribute mappings and contract terms to maintain.
Hub-and-Spoke Federation
Here a central broker sits between many identity providers and many relying parties. Each member connects once to the hub, which translates and forwards assertions. This reduces configuration work and allows protocol translation, such as SAML in and OpenID Connect out. The trade-off is that the hub becomes a high-value target and a single point of failure.
Multilateral Federation
Research and education networks often use a multilateral model. A federation operator publishes signed metadata for all members, and each member agrees to shared rules. Members trust each other through the operator’s vetting rather than individual contracts. This works well for large communities, though members must still decide which attributes they release to which services.
Assurance: How Much a Relying Party Can Believe
Federation only moves trust around; it does not create it. If the identity provider verified a person weakly, every relying party inherits that weakness. Relying parties therefore need to know how carefully the user was identified and how strongly they signed in.
NIST SP 800-63, the US digital identity guidelines, separates these questions. Identity assurance level (IAL) describes how thoroughly a person’s real-world identity was proven. Authenticator assurance level (AAL) describes the strength of the sign-in method. Federation assurance level (FAL) describes how securely the assertion itself is protected and delivered.
A sensible relying party asks for the levels it actually needs. A discussion forum may accept a low-assurance login, while a service that releases medical records should require stronger proofing and phishing-resistant authentication. Assurance information can travel inside the assertion, so the relying party can refuse access when the level is too low.
Other countries use their own frameworks, such as eIDAS levels in the European Union, so check which scheme applies to your partners.
What Users Gain and What They Give Up
For individuals, federation reduces the number of passwords to manage and the number of databases holding their credentials. A breach at a relying party cannot leak a password it never stored, which limits the damage from a poorly secured site.
The cost is concentration. If the identity provider account is taken over, the attacker may reach every connected service at once. The provider can also observe which services a person visits and when, which is a privacy concern even when the provider is trustworthy.
Users should therefore treat any account used for federated sign-in as their most important login. Protect it with a unique passphrase and a strong second factor, review the list of connected services occasionally, and remove connections to services no longer in use. These habits keep the benefits while shrinking the downside.
Privacy Patterns Inside Federated Systems
Well-designed federations release only the attributes a service genuinely needs. A library database may only need to know that someone is a current student, not their name or student number. Sharing a yes-or-no attribute rather than full identity details is a practical form of data minimization.
Another pattern is the pairwise identifier. Instead of sending the same user ID to every service, the identity provider generates a different, stable identifier for each relying party. Two services comparing their records cannot easily link the same person across them, which reduces tracking and correlation.
Consent screens help too, showing users which details will be shared before the first sign-in. These measures do not make a person anonymous, since the identity provider still knows who they are. They do reduce how much each relying party learns and how easily separate records can be combined.
Common Ways Federation Trust Breaks
Most federation failures come from configuration and key handling rather than flaws in the underlying standards. Understanding the typical failure points helps teams test for them and helps users recognize when something looks wrong during sign-in.
- Unverified signatures: a relying party that accepts assertions without checking the signature can be fed forged identities.
- Stale metadata: expired or replaced certificates left in configuration cause outages or, worse, trust in retired keys.
- Overly broad trust: accepting assertions from any member of a large federation when only one partner should qualify.
- Weak upstream accounts: a compromised identity provider account passes straight through to every connected service.
- Missing deprovisioning: local accounts or sessions at relying parties that survive after the home account is disabled.
Each of these is preventable with routine checks: strict signature validation, scheduled metadata refresh, explicit partner allow lists, strong authentication at the provider and session limits at relying parties.
Teams should rehearse each of these failure cases in a test environment, confirming that every one produces a clear rejection rather than a silent success.
Federation Compared With Shared Passwords and Directory Sync
Before federation became common, organizations connected systems by copying user directories or sharing password databases. Directory synchronization pushes user records, and sometimes password hashes, from one system to another so each can check credentials locally.
Federation differs in a crucial way: the relying party never sees the user’s password. It only receives a signed statement that authentication happened. That keeps credentials in one place, reduces exposure if a partner is breached, and lets the home organization change sign-in methods without touching every partner.
Synchronization still has a role. Some applications need a local user record before the first sign-in, for example to assign licenses or set up mailboxes. Many organizations combine both approaches, using provisioning standards such as SCIM to create accounts ahead of time and federation to handle the actual sign-in.
A Worked Scenario: Two Hospitals Sharing a Portal
Consider two hypothetical hospitals that share an imaging portal. Hospital A runs the portal; Hospital B’s radiologists need access. Rather than issuing portal passwords, the hospitals federate. Hospital B acts as identity provider, and the portal acts as relying party.
Before go-live, they exchange metadata, agree that only users with a radiology role attribute may enter, and require multifactor authentication at Hospital B. The portal checks the signature, the role attribute and the authentication context in each assertion before granting access.
When a radiologist leaves Hospital B, their account is disabled there, and the next sign-in attempt to the portal fails automatically. The portal also limits session length, so an already open session ends within hours. Both hospitals log federated sign-ins, so unusual access can be traced.
The arrangement is reviewed yearly, including key rotation and a check that the attribute list is still the minimum needed.
Practical Steps Before Joining or Building a Federation
For organizations, start by listing which partners genuinely need access and what each one must know about users. Write that down as an attribute release policy, and agree on required assurance levels, incident contacts and how quickly each side will report a compromise.
Technical teams should confirm that signature validation is enforced, that metadata refreshes automatically, and that certificate expiry dates are tracked. Test failure cases deliberately: a tampered assertion, an expired certificate and a disabled user should all be rejected. Keep logs that show which identity provider vouched for each session.
For individuals, the takeaway is simpler. Every time a site offers to sign you in through another account, you are joining a small federation. Choose a provider account you protect carefully, read what details will be shared, and disconnect services you no longer use.