IDSync — identity software buyer platform
Run Stack Finder

Architecture

Identity Federation

Identity federation is the practice of letting one organization's identity provider authenticate users into another organization's applications — enabling B2B SSO, customer SSO into partner apps, and cross-domain single sign-on without duplicating accounts.

Last reviewed 5/30/2026

Key points

  • Federation is what makes 'Sign in with your work account' possible across organizations.
  • Protocols: SAML 2.0 (dominant for enterprise federation), OIDC (modern web/mobile), WS-Federation (legacy Microsoft), SCIM (for user lifecycle alongside SSO).
  • B2B SSO is the most common modern use case — your customer's IT team configures their IdP to sign their employees into your SaaS app.
  • Federated trust is one-way: the SP trusts the IdP's signature, not the other way around.
  • Just-in-time (JIT) provisioning creates the user account on first federated sign-in; SCIM keeps it in sync afterward.

What is identity federation?

Identity federation is the trust pattern that lets users authenticate with their home organization's IdP (Okta, Entra ID, Google Workspace) to access another organization's applications — without that second organization having to manage their passwords, MFA, or lifecycle.

The IdP signs an assertion ("yes, alice@acme.com authenticated with MFA at 09:14 from a managed device"), the receiving application validates the signature against a pre-shared trust (SAML metadata or OIDC discovery), and the user gets in. Federation is what makes multi-organization SSO possible at internet scale.

Common federation patterns

  • Workforce → SaaS — Acme's employees sign into Salesforce, Slack, GitHub using Acme's Okta. Each SaaS app is configured as a Service Provider in Okta.
  • B2B SSO — Acme is a SaaS vendor; their customer "Globex" wants their employees to sign in with Globex's IdP. Acme implements multi-tenant federation, often via WorkOS, Auth0, Frontegg, or Stytch.
  • Cross-cloud federation — AWS, Azure, and GCP all support OIDC federation so workloads (CI runners, Kubernetes pods) can assume roles without long-lived secrets.
  • Government / supply chain — InCommon (US higher ed), EduGAIN (academia), FICAM (US federal), eIDAS (EU).

Protocols

| Protocol | Where it dominates | | --- | --- | | SAML 2.0 | Enterprise SaaS, government, legacy on-prem apps | | OIDC | Modern web/mobile apps, B2C, workload federation | | WS-Federation | Legacy Microsoft (SharePoint on-prem, ADFS) | | OAuth 2.0 (alone) | Authorization, not authentication — but often paired |

When buyers care

  • B2B SaaS revenue gate — every enterprise customer will require SAML/OIDC SSO and most will require SCIM.
  • M&A integration — federating identities across the parent and acquired company is faster than directory migration.
  • Contractor / partner access — federate instead of creating guest accounts.
  • Reducing the credential blast radius — no separate password for the partner app means no extra phishing target.

Common misconceptions

  • "Federation = SSO." SSO is the user experience; federation is the trust model that makes cross-org SSO possible.
  • "Federation provisions users." It usually doesn't on its own — federation handles authentication; SCIM (or JIT) handles provisioning.
  • "More federation = more secure." Only if the upstream IdPs are well-secured. Federating with a partner whose IdP has no MFA imports their risk.

Editorial note

When buying a B2B SaaS product, "SSO + SCIM with your IdP" should be table stakes, not an enterprise add-on. The "SSO tax" debate exists because too many vendors paywall security.