Federation vs SSO: Where One Login Ends and Cross-Domain Trust Begins

Teams use "SSO" and "federation" as if they were the same thing, and that confusion hides where the real trust, and the real risk, sits. Single sign-on is a user experience: one authentication event gives access to many applications. Federation is a trust arrangement: one party (the identity provider) vouches for a user to another party (the relying party) that never checks the user's authenticators itself. Most modern SSO is delivered through federation, but SSO can exist without federation and federation can exist without anything a user would call SSO, including workloads that federate with no human present. This guide separates the two, gives each its own threat model, failure modes and controls, and ends with decision criteria and worked scenarios. It is for identity architects, IAM engineers and security reviewers who sign off application onboarding, partner access and cloud trust. Facts were checked against NIST, OASIS, OpenID Foundation and vendor documentation on 14 November 2026.

Key takeaways

• SSO is the outcome, federation is the mechanism. NIST defines SSO as one account and its authenticators reaching multiple applications, generally implemented with a federation protocol; federation is the process in which a relying party trusts an assertion instead of verifying authenticators.
• The risk moves with the trust boundary. In SSO inside one domain the main risk is a stolen session or a weak login. Across a federation boundary the main risk is the signing key and the trust configuration, because whoever holds them can mint any user.
• Golden SAML is a federation attack, not an SSO attack. A forged assertion signed with a stolen token-signing key (ATT&CK T1606.002) bypasses MFA at every relying party that trusts that key, however good the login experience looks.
• Workloads federate too. Workload identity federation uses the same idea, an external token exchanged for local access, with no SSO experience at all; its attribute conditions are the trust boundary.
• Govern them separately. Measure SSO by coverage and session hygiene; measure federation by trust inventory, key protection, assertion validation and change alerting.

The short answer: two different questions

The NIST SP 800-63-4 glossary defines single sign-on as an authentication process in which one account and its authenticators can be used to access multiple applications seamlessly, and notes it is generally implemented with a federation protocol. NIST SP 800-63C-4 defines federation as the process of authenticating a subscriber to a relying party (RP) where the RP does not directly verify the subscriber's authenticators; instead the identity provider (IdP) sends an assertion triggered by an authentication event. SP 800-63C-4 adds that this process is sometimes known as single sign-on, which is where much of the confusion comes from.

A useful way to keep them apart is to ask two questions:

• SSO question: how many times does the person have to authenticate to reach the applications they need? If the answer is "once per session", you have SSO.
• Federation question: does any system accept identity statements signed by a different security domain, organisation or tenant, without checking the credential itself? If yes, you have federation, and a trust agreement whether or not anyone wrote it down.

The OASIS SAML 2.0 Technical Overview keeps the same split. It treats multi-domain web single sign-on as the most important SAML use case, and separately describes identity federation as an agreement between providers on how to refer to a user, reached through account linking, persistent pseudonyms, transient pseudonyms or shared attributes. One is about logging in; the other is about what partners agree to believe.

Side-by-side comparison

SSO without federation, and federation without SSO

SSO without federation

• Kerberos inside one Active Directory forest: a user signs in to Windows once and reaches file shares, intranet sites and SQL Server through tickets. There is one security domain and no assertion crosses an organisational boundary. Risks are ticket theft and delegation abuse; see the Kerberos Delegation Security Guide.
• First-party session sharing: several applications under one company domain read the same session from a central login service. Again, one owner, one domain.

Federation without SSO

• Workload identity federation: a CI job or a workload in another cloud presents a token from its own issuer and receives short-lived cloud credentials. Google Cloud documents this as exchanging an external credential with its Security Token Service, following the OAuth 2.0 token exchange model, with no service account key. Nobody "signs on". See the Workload Identity Federation Guide.
• Partner access with step-up: a partner's IdP vouches for its staff, but the RP still demands its own fresh authentication for a sensitive action. Federation is present; the seamless experience is not.

SSO: threat model, failure modes and controls

Threat model. SSO concentrates authentication into one event and one session. That is its benefit (one strong login, one place to enforce MFA and conditional access, one place to revoke) and its risk (one phish or one stolen cookie reaches everything). The attacker's targets are the primary login, the account recovery path, and the session artefacts the IdP issues after login.

Architecture in words. The user authenticates to the IdP, which sets its own session. Each application redirects the browser to the IdP, receives a token or assertion, and creates a local application session. There are therefore at least two session layers, the IdP session and each application session, with separate lifetimes and separate logout behaviour. The direction of the flow also matters: in the OASIS overview, SP-initiated SSO (the user starts at the application) is the most common pattern, while IdP-initiated SSO sends an unsolicited assertion; see IdP-Initiated vs SP-Initiated SSO.

Failure modes.

• Partial coverage: applications that still allow local passwords sit outside the IdP's MFA and offboarding. NIST SP 800-63C-4 notes that an RP may allow direct authentication, in which case no federation transaction occurs and no FAL applies. The SSO Coverage Guide covers measurement.
• Session theft: a stolen IdP session cookie or refresh token gives the attacker the same single sign-on the user had.
• Weak recovery: a strong login paired with a help-desk reset that bypasses it.

Controls. Phishing-resistant MFA on the single login, session lifetimes set per sensitivity, token binding or device binding where the platform supports it, a disabled local login path at each application,. IdP hardening in depth is in the Identity Provider and SSO Security Guide; this page does not repeat it.

Federation: threat model, failure modes and controls

Threat model. In federation the RP accepts a signed statement and stops there. NIST SP 800-63C-4 is explicit that the RP does not act as the verifier for the subscriber's authenticators. The security of every federated login therefore rests on three things the RP cannot see: the IdP's signing key, the IdP's own login and administration, and the accuracy of the RP's trust configuration. The trusting side carries the risk.

Architecture in words. A trust agreement (NIST uses "pre-established" for one set up before transactions and "subscriber-driven" for one set up during a transaction, allowed only at FAL1) names the IdP, its keys and the attributes it may assert. The RP retrieves the IdP's metadata (SAML) or discovery document and JWKS (OIDC), validates each assertion's signature, issuer, audience, validity window and replay protection, then maps the asserted identifier to a local account, created in advance or at first login.

Failure modes.

• Signing key theft (Golden SAML): an attacker with administrative access to the federation server extracts the token-signing key and forges assertions for any user, with any claims, including a claim that MFA was performed. ATT&CK tracks this as T1606.002 SAML Tokens, with key theft under T1552.004 Private Keys. The SolarWinds SUNBURST and Golden SAML breach is the reference case: the stolen certificate let attackers sign in as any user to federated services without a password or MFA prompt.
• Rogue trust: an attacker with tenant administrator rights adds a new federated domain or IdP they control, tracked as T1484.002 Trust Modification. No key theft is needed; the RP simply now trusts a second issuer.
• Weak assertion validation: the RP accepts unsigned assertions, does not check audience, ignores expiry or replay, or accepts tokens from an issuer it did not intend. OpenID Connect Core section 3.1.3.7 requires the issuer to match exactly, the audience to contain the client_id, and tokens with untrusted extra audiences to be rejected.
• Stale trust: partner trusts left in place after a contract ends, and metadata that is never refreshed, so a rotated or revoked key is still accepted or a legitimate rotation breaks sign-in.
• Over-broad identifier mapping: mapping on a user-editable attribute such as email lets a user at the IdP claim another person's RP account.

Controls.

• Treat the signing key as tier 0: hardware-backed storage, minimal administrators, and backups of the federation configuration held at the same tier. The Golden SAML Defence Guide covers key protection and detection in depth.
• Raise the FAL where it matters: SP 800-63C-4 requires signed assertions at FAL1, adds injection protection, single-RP audience and pre-established trust at FAL2, and requires holder-of-key assertions or bound authenticators at FAL3, so a forged or stolen bearer assertion alone is not enough. See the NIST SP 800-63C-4 Federation Assurance Levels Guide.
• Validate every claim: signature, issuer, audience, expiry, replay identifier, and an immutable subject identifier for account mapping.
• Alert on trust changes: any new IdP, federated domain, signing certificate or claims rule is a change to tier-0 configuration and should page someone.
• Rehearse emergency rotation: Microsoft's emergency AD FS guidance says to rotate the token-signing certificate twice because Entra ID retains the previous certificate, to revoke users' refresh tokens afterwards, and to send the new public key to partners that cannot consume metadata. The same discipline (rotate, flush cached keys, revoke sessions, notify partners) applies to any IdP.

Workload federation: the same trust, no login screen

Workload identity federation is federation in its purest form: an external issuer (a CI platform, another cloud, a Kubernetes cluster) signs a token, and the cloud accepts it in place of a long-lived key. Google Cloud's documentation describes attribute mapping (for example google.subject=assertion.sub) and attribute conditions, CEL expressions that accept or reject each credential. It warns that granting access to every identity in a pool "can incur risk", that conditions are especially important with a public IdP, and recommends a separate pool for each environment such as development, staging and production.

A pool with no attribute condition trusts every token the issuer signs, just as an RP that ignores audience trusts every assertion an IdP signs. The Workload Identity Federation vs Static Cloud Keys page covers the migration, and the Workload Identity Federation Trust Review Checklist covers review.

Where each attack lands

Decision guidance

• All users and applications are yours, in one directory: you need SSO. SAML or OIDC still reach SaaS, so inventory each SaaS RP as a trust.
• Partners, subsidiaries or customers bring their own identities: you need federation. Decide which side is the IdP, which attributes you will believe, and whether you require your own step-up for sensitive actions.
• Workloads outside your cloud need access: federate the workload's own token; do not issue keys. Write attribute conditions before granting any role.
• High-value applications (finance, admin consoles, production): aim for FAL2 or higher, and consider re-authentication at the RP for privileged actions so a forged assertion alone does not reach them.
• Small organisations: one cloud IdP with SSO to every SaaS application, local logins disabled, and alerts on federation changes covers most of the risk. Avoid running your own federation servers unless a requirement forces it.
• Large or regulated organisations: separate SSO governance (coverage, sessions, recovery) from federation governance (trust register, key custody, partner reviews), with named owners for each. Hybrid estates should also weigh Identity Federation vs Identity Synchronisation, since moving from on-premises federation to cloud authentication removes a whole class of key-theft risk.

Worked scenarios

Scenario 1: "We have SSO, so we are covered." A mid-sized company federates its workforce IdP with 140 SaaS applications. An audit finds 22 still accept local passwords, and former contractors still sign in to two of them. SSO was configured, not enforced. The fix is SSO work: disable local login per application and track coverage.

Scenario 2: the partner portal. A manufacturer lets a logistics partner's staff reach a shipment portal through the partner's IdP. The trust was set up on email address as the identifier, with no review date. The partner's IdP is compromised and an attacker sets an email attribute matching a manufacturer administrator. The fix is federation work: map on an immutable, partner-scoped identifier, restrict the trust to the portal audience, require local step-up for administrative functions, and give the trust an owner and an expiry.

Scenario 3: the on-premises federation server. An attacker who reached domain administrator rights extracts the token-signing key from a self-hosted federation farm. Every cloud sign-in that follows passes MFA checks because the forged assertion says it did. Detection comes from correlating cloud sign-ins against the federation server's own issuance logs: an assertion with no matching issuance event is forged. Recovery follows the rotation steps above.

Scenario 4: the CI pipeline. A platform team federates CI jobs into a cloud account using the CI provider's OIDC tokens but leaves the attribute condition empty. Any repository on the same CI platform can now obtain credentials. No user ever "signed on", yet this is a federation failure. The fix is a condition that pins the repository, branch and environment; see How to Scope CI OIDC Trust to Branch and Environment.

How to implement: separating the two in practice

1. Build two inventories. An SSO inventory of every application and whether it is IdP-only, IdP plus local login, or local only. A federation trust register of every IdP you trust, every RP that trusts you, every workload pool, and each one's signing keys, metadata source, owner and review date.
2. Fix SSO coverage first. It is the cheaper, larger risk reduction. Pilot disabling local login on a small group of applications, keep a break-glass local account under vault control, and roll back per application if sign-in fails.
3. Harden assertion validation. Test each RP with expired, wrong-audience and unsigned assertions in a non-production tenant; any that accept them get fixed before new trusts are added.
4. Move signing keys to hardware and minimise federation administrators. Schedule a rehearsal of emergency rotation, including partner notification, before you need it.
5. Turn on change alerting for new IdPs, federated domains, signing certificates and claims rules, and confirm the alert fires by making a controlled change.
6. Review partner and workload trusts quarterly, removing any without an owner or recent use.

Detection and measurement

• Log sources: IdP sign-in and session logs, federation server issuance logs, RP sign-in logs, cloud audit logs for changes to federation settings and workload identity pools.
• Key detection: RP sign-ins that claim a federated authentication with no matching IdP issuance event, which is the clearest Golden SAML signal.

Common failure patterns

• Calling a federation project "SSO" and governing it as a convenience feature, so the trust register, key custody and partner reviews never get an owner.
• Trusting the MFA claim in an assertion as proof that MFA happened. A forged assertion can say anything, which is what made the SolarWinds Golden SAML access so effective.
• Leaving local login enabled behind SSO, which keeps password attacks and orphaned accounts alive at the applications.
• Rotating a signing key once and stopping, while the RP still accepts the previous certificate.
• Federating workloads without conditions, trusting every token a shared CI or cloud issuer signs.

Framework mapping

Practitioner checklist

• Use "SSO" for the login experience and "federation" for cross-domain trust in designs, risk registers and audit scopes.
• Keep a federation trust register with owner, keys, metadata source and review date for every IdP, RP and workload pool.
• Disable local login at every SSO application, with a vaulted break-glass account where needed.
• Store IdP signing keys in hardware-backed storage and treat federation servers and their backups as tier 0.
• Validate signature, issuer, audience, expiry, replay and an immutable subject identifier at every RP.
• Require FAL2 or higher, or local step-up, for administrative and financial applications.
• Alert on every new IdP, federated domain, signing certificate or claims rule change.
• Rehearse emergency key rotation, including double rotation, session revocation and partner notification.
• Pin workload federation with attribute conditions and separate pools per environment.

Standards and references

• NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
• NIST: Glossary, single sign-on
• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• OpenID Foundation: OpenID Connect Core 1.0
• MITRE ATT&CK: Forge Web Credentials, SAML Tokens
• MITRE ATT&CK: Domain or Tenant Policy Modification, Trust Modification
• Microsoft Learn: Emergency rotation of the AD FS certificates
• Google Cloud: Workload Identity Federation

Related NHI Mgmt Group resources: Federation and Trust Relationships Guide, SAML vs OIDC Guide, Identity Federation Failure Modes, OpenID Federation and Trust Chains Guide.