Federated identity lets a user sign in once with an identity provider that vouches for them to separate services run by other parties. The services trust the provider's signed statement instead of keeping their own passwords. Common protocols are SAML and OpenID Connect.
How does NIST describe it?
NIST SP 800-63C, part of the digital identity guidelines, says federation allows a given credential service provider to provide authentication attributes, and optionally subscriber attributes, to a number of separately administered relying parties. It also notes that relying parties may use more than one credential service provider. Assertions are the messages that carry the result.
The OASIS SAML technical overview puts the benefit in administrative terms: partner services agree on a shared name identifier for a user, so they do not each need to collect and maintain passwords and identity attributes separately.
Who are the parties?
Three roles recur. The user, who wants access. The identity provider, which authenticates the user and issues a signed assertion or token. The relying party or service provider, which accepts that assertion and decides what the user may do.
Authentication and authorization stay distinct. The provider says who the user is, and possibly passes attributes such as group membership. The service still enforces what that person can do inside it.
How do SAML and OpenID Connect differ?
SAML is an XML-based standard from OASIS widely used for enterprise single sign-on to web applications. OpenID Connect 1.0 is, in the words of its specification, a simple identity layer on top of OAuth 2.0 that lets clients verify the end-user's identity based on authentication performed by an authorization server, and obtain basic profile information in an interoperable way.
In short: SAML is older and common in business software. OpenID Connect uses JSON and fits modern web and mobile apps. Many organizations run both.
What does it look like in practice?
A constructed example. A company of 150 uses 40 cloud services. Without federation, each service has its own password and its own account list. When someone leaves, IT must remove them from 40 places, and they usually miss two.
With federation, all 40 services trust the company's identity provider. Multi-factor authentication is enforced once, at the provider. Disabling the person's account at the provider cuts new sign-ins everywhere at once. Sessions already open at each service may last longer, so shortening session lifetimes and revoking tokens still matters.
What are the risks?
Concentration. The identity provider becomes the most valuable target. If an attacker controls it, or steals the keys it uses to sign assertions, they can impersonate any user to every connected service. Protect it with strong multi-factor authentication, tight administrator access and careful logging.
Validation mistakes at the relying party. Services must verify signatures, the issuer, the intended audience, expiry and, where used, a one-time value to prevent replay. Accepting an unsigned or wrongly scoped assertion defeats the design.
Over-trust. A relying party that grants access based only on an email attribute, or accepts assertions from many unrelated providers, can be tricked into mapping an outsider to an insider.
Account lifecycle gaps. Federation handles sign-in. Provisioning and removal of accounts inside each service still needs a process, which is why identity lifecycle work and federation go together.
How to check or apply this
- List services and mark which support SAML or OpenID Connect. Prioritize those holding sensitive data.
- Choose one identity provider as the authority and enforce multi-factor authentication there.
- For each service, verify configuration: signature checking, expected issuer, audience restrictions, short assertion lifetimes.
- Keep break-glass admin accounts outside federation, with strong protection and monitoring, so an outage does not lock you out.
- Pass the minimum attributes needed. Do not send group lists or personal data a service does not use.
- Plan automated provisioning and deprovisioning for each service, so removal does not depend on someone remembering.
- Rotate signing certificates on a schedule and test before expiry. Expired certificates are a common cause of sign-in outages.
- Log sign-ins centrally and alert on unusual locations or sudden spikes.
- Review the list of trusted providers and relying parties each year.
Quick check
Is federated identity the same as single sign-on?
Related but not identical. Single sign-on describes the user experience of signing in once. Federation is the trust arrangement across separately run services that makes it work across organizational boundaries.
Does federation remove the need for passwords?
It reduces how many places hold them. Users still authenticate at the identity provider, so strong, preferably phishing-resistant, methods matter there.
Sources
- NIST SP 800-63C-3: Federation and Assertions
- OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
- OpenID Connect Core 1.0
Last reviewed: 18 October 2026.
