Identity Federation Explained: The 2026 Foundational Guide

Identity federation is a trust relationship between two or more separate identity providers that lets an identity authenticated in one domain be accepted in another. Instead of every application and organization maintaining its own accounts and passwords, one system vouches for who a user is, and another system agrees to trust that vouching. The practical result is that a single login works across domains, organizations, and clouds that no single directory controls: a user signs in once with their home identity provider and reaches resources owned by a different party, without ever creating a new account there. Federation is the mechanism that makes cross-organization single sign-on possible, and it is built entirely on trust that was established in advance.

That last point is what separates federation from a password that happens to be reused in two places. Nothing about a federated login copies a credential from one system to another. What moves between the two sides is a signed statement — an assertion — that says "this identity provider authenticated this user, and here is what we know about them." The receiving side accepts it because it verified the signature against a key it agreed, ahead of time, to trust. This guide is the foundational reference on what identity federation is, how it differs from the single sign-on people often confuse it with, how a federated login actually works, the protocols that carry it, and the boundary of what federation does and does not do.

What identity federation actually is

Federation is a trust agreement between identity domains. A domain here is any boundary within which identities are managed as a unit — a company's directory, a cloud tenant, a customer's own identity system, a SaaS vendor's account store. Ordinarily, each of those domains is an island: to use a resource inside one, you need an account inside that one. Federation builds a bridge between islands so that an identity proven on one side is honored on the other, without the second side ever issuing the user a credential of its own.

The bridge is not metaphorical. Before any user ever logs in, the two parties exchange configuration: the network endpoints where authentication messages are sent, the certificates and public keys used to sign and verify those messages, and the rules for what a valid assertion looks like. This exchange — usually a metadata document — is what turns two unrelated systems into a federation. From then on, one side can produce a signed assertion and the other can verify it came from a partner it trusts. Remove the pre-established trust and there is no federation; there is just two systems that cannot vouch for each other.

Federation is a pre-established trust link between two separate identity domains — one proves who the user is, the other agrees to accept that proof, and no credential is ever copied across.

The reason enterprises reach for federation is that the modern estate is made of islands by default. Employees, contractors, and partners belong to different organizations. Applications live in different clouds run by different vendors. Mergers leave two directories that must interoperate long before they can be consolidated. Federation is how all of that connects without the impossible alternative of giving every person a fresh account, and a fresh password, in every system they will ever touch.

Federation versus single sign-on

Federation and single sign-on are constantly used as synonyms, and they are not the same thing. Single sign-on is a user experience: you authenticate once and then reach many applications during that session without being asked to log in again. Federation is a trust mechanism: it lets that single login be honored across a boundary that no single identity provider owns. The two often appear together, which is why they blur — but they answer different questions. SSO answers "how many times must the user log in?" Federation answers "whose identity provider gets to vouch for the user, and who agreed to trust it?"

You can have single sign-on with no federation at all. If every application a company uses sits behind one identity provider inside that one company, users get SSO across all of them without any cross-organization trust — it is all one domain. Federation becomes necessary the moment the applications, or the users, belong to a different party: an external SaaS vendor, a partner organization, a customer bringing their own corporate login. At that point a trust relationship has to be established between two identity domains, and that relationship is federation. Most enterprise SSO that reaches outside the company's own walls is federated underneath, even when nobody calls it that.

SSO is one login reaching many apps inside a single domain; federation is the cross-domain trust that lets that login be accepted by systems a different organization controls.

The distinction matters in practice because it changes what you have to build and secure. SSO inside one domain is largely a convenience and a consolidation problem. Federation across domains is a trust and risk problem: you are deciding which external identity providers your systems will believe, and which of your resources you will expose to identities you did not authenticate yourself. Treating federation as "just SSO" is how organizations end up trusting identity providers they never properly evaluated.

How a federated login works

Walk through a single federated login and the machinery becomes clear. There are two roles. The identity provider (IdP) is the side that authenticates the user and vouches for them. The service provider (SP), or relying party, is the side that hosts the resource and consumes the IdP's assertion to grant access. The IdP holds the account, the credentials, and the authentication policy; the SP holds no password for the user at all.

The flow runs like this. The user tries to reach a resource at the service provider. The service provider does not know the user directly, so instead of asking for a password it redirects the user's browser to their identity provider. The identity provider authenticates the user with whatever factors it enforces — password plus MFA, a passkey, a certificate — and then issues a cryptographically signed assertion stating who the user is and, usually, which attributes or groups they hold. The user's browser carries that assertion back to the service provider. The service provider verifies the signature against the public key it trusts for that IdP, reads the claims, and grants access. The user's password never leaves the identity provider, and the service provider trusts the identity for one reason only: the signature proves the assertion came from a partner it agreed in advance to trust.

Two properties fall out of this design and are worth naming. First, the relying party is stateless about credentials — it never stores or checks a password, which removes an entire category of breach exposure from every downstream application. Second, the identity provider becomes the single point where authentication strength is enforced. Turn on phishing-resistant MFA at the IdP and every federated application inherits it at once, with no change on their side. That leverage is the upside of concentration; the corresponding risk of concentration is the subject of the closing section.

The protocols that carry federation

Federation is a pattern, and several standards implement it. Four matter in the enterprise, and a real environment usually runs more than one at the same time.

SAML 2.0 is the long-standing standard for enterprise web single sign-on. It exchanges XML assertions between an identity provider and a service provider and has been the default for workforce SaaS integrations for well over a decade. It is mature, widely supported, and still the connector most enterprise applications expose first. Whether it is the right choice for a new build is a live debate; whether you will encounter it is not. For that judgment call, is SAML 2.0 still relevant in 2026 works through where the standard still fits and where newer options have overtaken it.

OpenID Connect (OIDC) is the modern federation standard for web, mobile, and API access. Built as an identity layer on top of OAuth 2.0, it carries identity in compact JSON tokens instead of XML and fits single-page apps, mobile clients, and API-driven architectures far more naturally than SAML does. It is what most new applications adopt. Because OIDC and OAuth are closely related but do different jobs — one proves identity, the other delegates authorization — they are easy to conflate; OAuth 2.0 versus OpenID Connect separates the two cleanly for enterprise use.

SCIM (System for Cross-domain Identity Management) is the provisioning companion to federation. Federation authenticates a user at login, but something has to create the account they federate into, keep its attributes current, and deactivate it when they leave. That is SCIM: a standard for pushing create, update, and deactivate operations from an authoritative source into every connected application. Federation without provisioning logs users into accounts that may be stale or missing; the SCIM provisioning standard covers how the two halves fit together.

WS-Federation is an older standard still present in Microsoft-centric and legacy estates, frequently alongside SAML. You are unlikely to build new integrations on it, but you will meet it during consolidation and migration work, particularly where older Active Directory Federation Services deployments are involved.

Federation is one pattern with several standards: SAML and OIDC authenticate the login, SCIM provisions the accounts it logs into, and WS-Federation lingers in older Microsoft estates — most enterprises run several at once.

The takeaway is that "which federation protocol" is rarely a single answer. Enterprises run SAML and OIDC side by side for authentication, SCIM underneath for lifecycle, and WS-Federation wherever legacy demands it. The competence that matters is not picking one standard but operating the mix coherently.

Where federation fits in a hybrid enterprise

Federation earns its place most visibly in the hybrid, multi-organization reality nearly every enterprise now lives in. The workforce is a blend of employees, contractors, and partners who do not all belong to the same directory. The application estate spans on-premises systems, private cloud, and dozens of external SaaS tools. And the identity infrastructure itself is often split — an on-premises Active Directory alongside a cloud identity tenant — which is a federation problem before it is anything else. Running that split cleanly is its own discipline; hybrid Active Directory and Entra identity covers the pattern in depth.

The common thread is that federation lets an organization keep one authoritative identity per person while extending that identity everywhere it is needed. A contractor authenticates with their own employer's identity provider and reaches a client's system through a trust relationship, with no client-issued account to provision, forget, and later fail to remove. An employee carries one corporate identity across every SaaS application the company uses, and when they leave, disabling that one identity cuts access everywhere at once. Without federation, each of those relationships would require a separate account, a separate password, and a separate offboarding step — the exact conditions under which orphaned access accumulates.

Federation is also the connective tissue for a zero-trust posture, because zero trust makes identity, rather than network location, the primary thing you verify. If identity is the control plane, that plane has to reach across every organization and cloud in scope, and federation is what extends it there. The architecture that depends on this is laid out in the zero-trust identity architecture guide; federation is one of the foundations it assumes is already in place.

What Avatier ships toward this pattern

Avatier's role in federation is to be a well-behaved participant in it and to govern what sits on top of it. Identity Anywhere connects to enterprise identity providers and directories through standards-based federation and single sign-on, so a user's authoritative login is honored across the applications and domains the platform governs, rather than fragmenting into another set of accounts. It supports the standards that carry federation in the enterprise and provisions the accounts those logins depend on through SCIM-based lifecycle automation, so authentication and provisioning stay aligned instead of drifting apart.

Where Avatier concentrates is on the governance layer that federation cannot provide by itself. A federated login proves who a user is; it does not decide what that user should be able to reach, keep that access least-privilege over time, or produce the evidence an auditor asks for. Identity Anywhere adds access request, certification, and lifecycle governance over the federated foundation, so the identities flowing across trust relationships are the right identities with the right access, granted and revoked reliably.

That posture is backed by an audited compliance program. Avatier is SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, and CSA STAR Level 1, with a platform aligned to NIST 800-53 Rev. 5, built FedRAMP-aligned, delivered as a signatory of CISA's Secure-by-Design Pledge, and FIDO2-compatible for phishing-resistant authentication at the identity provider. You can review the current attestations and status at trust.avatier.com. Federation is only as trustworthy as the identity provider anchoring it, which is why the governance and assurance around that anchor matter as much as the protocols themselves.

What federation does not solve

Federation is a foundational layer, and like every foundation it is defined as much by what it does not carry as by what it does. Naming those boundaries honestly is the difference between using federation well and over-trusting it.

Federation does not decide who should have access. It proves who a user is and hands that proof to the far side; whether that user should reach a given resource is authorization and access governance, which run on top of a federated login, not inside it. A perfectly executed federation will faithfully log a user into access they should never have had.

Federation does not clean up hygiene. It logs a user into whatever the far side already granted them, so stale accounts, orphaned entitlements, and accumulated access survive federation untouched — and are arguably easier to overlook, because the smooth single login hides how much sits behind it. That cleanup is lifecycle and certification work, not federation.

Federation does not provision or deprovision by itself. Creating, updating, and deactivating the accounts a user federates into is SCIM and lifecycle automation — a companion to federation that federation depends on but does not include. A trust relationship with no provisioning behind it federates users into accounts that are missing, stale, or never removed.

And federation does not contain a compromised identity provider. The same concentration that makes federation powerful — everything trusts the IdP — makes the IdP a single point of catastrophic failure. If it is breached, or its signing keys are stolen, or a trust relationship is misconfigured, the blast radius is everything that trusts it. Federation assumes the identity provider is sound; it does nothing to detect or contain it when it is not. That is why federation belongs inside a program that includes strong authentication at the IdP, disciplined key and trust management, least-privilege authorization on the far side, and continuous monitoring — not as a substitute for any of them. Federation connects identity across boundaries elegantly. Keeping that connection safe, current, and correctly governed is the work it leaves to everything around it.