Identity federation: how it works, and the platforms that do it

Identity federation is a trust agreement between two systems: one system authenticates the user, and the other accepts that authentication without seeing the password. The user signs in once at an identity provider (IdP) and gets access to an application, the service provider (SP) or relying party, because the application trusts the IdP's statement about who the user is.

That sounds like single sign-on, and the two are related, but they are not the same thing. Federation is the cross-domain trust; SSO is the experience of not signing in again.

The pieces of a federation

• Identity provider (IdP). Authenticates users and issues assertions or tokens. It owns the user directory, the login policy and the MFA.
• Service provider (SP) or relying party (RP). The application that trusts the IdP. It does not store the user's password.
• Trust material. SAML metadata and certificates, or an OIDC discovery document and signing keys. This is what makes the trust verifiable.
• A protocol. SAML 2.0 or OpenID Connect for the sign-in, and often SCIM for provisioning.
• Attribute mapping. The IdP sends email, name, groups or roles; the SP maps them to its own user fields and permissions.

Federation vs SSO

You can have SSO without federation: several apps behind one session cookie on the same domain. You can also have federation without SSO: each app starts its own login at the same external IdP. Most enterprise systems have both.

The protocols

SAML 2.0 is the enterprise standard. The IdP and SP exchange XML metadata, and the IdP sends a signed assertion through the browser. It is verbose and certificate-heavy, but it is what most enterprise procurement teams expect.

OpenID Connect (OIDC) is the modern option. It builds on OAuth 2.0, uses JSON and JWTs, and has a discovery document that tells clients where to find the endpoints and keys. It is the better fit for new applications, mobile apps and APIs.

WS-Federation is older and mostly found in Microsoft environments. New integrations should use SAML or OIDC instead.

CAS is a single sign-on protocol, not a federation protocol in the SAML/OIDC sense, but many universities and older applications still use it. Some identity providers, including Casdoor, serve it alongside SAML and OIDC.

SCIM does not sign users in. It creates, updates and deprovisions accounts. Federation without SCIM means users are created on first login but may not be removed when they leave; that gap is why enterprise buyers ask for both.

The common federation patterns

• Workforce SSO. Employees sign in to SaaS tools through the company's IdP (Entra ID, Okta, Google Workspace).
• B2B customer SSO. Each customer connects its own IdP to your SaaS product, so its users sign in with their corporate account. This is the pattern that requires multi-tenant federation: one application, many IdP connections.
• Social login. The IdP is Google, GitHub, Apple or another consumer provider.
• Partner federation. Two organizations trust each other's identities for a joint service, often with strict attribute and audience rules.

The platforms

Casdoor

Casdoor is an open-source identity provider that can act as the federation hub in both directions. It is a SAML 2.0 IdP and an OIDC provider for the applications you run, and it can also accept upstream SAML and OIDC providers so users can sign in through Entra ID, Okta, Google Workspace or a customer's IdP.

For B2B federation, the organization model gives each customer its own users, roles and administrators, and each application can have its own redirect URLs, token format and attribute mapping. Casdoor also speaks CAS, LDAP, RADIUS and SCIM, which matters when the federation has to include older applications and network devices. Casdoor Cloud starts at $6.67/month billed yearly for a dedicated instance with no per-user or per-connection fees.

Keycloak

Keycloak is the most established open-source identity server and a CNCF incubating project. Its identity brokering is mature: it can federate to SAML and OIDC providers, connect to LDAP and Active Directory, and expose OIDC or SAML to the applications behind it.

The trade-off is operational weight. It is a Java service that takes planning to upgrade, and the project does not offer a managed service.

Microsoft Entra ID

Microsoft Entra ID is the default workforce IdP for Microsoft-centric organizations. It supports SAML and OIDC federation, external identities and conditional access. It is a strong choice when the organization already lives in Microsoft 365.

Okta

Okta is a large proprietary identity platform with a deep connector catalog. It is common in enterprises that need workforce SSO across many SaaS applications and a mature administration model.

Auth0

Auth0 is a developer-focused proprietary identity platform. It supports OIDC and SAML connections, social login and enterprise connections, with a per-MAU pricing model.

Zitadel

Zitadel is an open-source identity platform built around multi-tenancy: organizations, projects and delegated administration. It is a good fit for B2B SaaS that needs each customer to have its own identity space, but its AGPL-3.0 license is a consideration for some legal teams.

What to check before choosing a federation platform

1. Protocols in both directions. Can it be the IdP for your apps and the SP for your customers' IdPs?
2. Multi-tenant connections. Does each customer get its own metadata, certificate and attribute mapping?
3. Provisioning. Does it support SCIM, or at least JIT provisioning with a clear deprovisioning story?
4. Attribute mapping. Can you map groups and roles per application without writing code?
5. Logout. Does single logout work across the applications that participated in the session?
6. Certificate lifecycle. How do you rotate SAML certificates without breaking every connection?
7. Audit and support. Can you see who signed in through which connection, and who answers when a customer's federation breaks?

FAQ

Is federation the same as SSO? No. SSO is a user experience; federation is a trust relationship between domains. Federation often enables SSO, but the terms describe different things.

Is federation only SAML? No. OIDC is widely used for federation, especially for new applications and consumer identities. SAML remains common in enterprise and government procurement.

Do I need SCIM for federation? For sign-in, no. For account lifecycle, yes. Without SCIM or another provisioning mechanism, users may be created on first login but never updated or removed.

Can one application federate with many identity providers? Yes. That is the B2B pattern: one application, one connection per customer, each with its own metadata and attribute mapping. The platform has to support multi-tenant connections, not just a single IdP.

If you want to try a federation hub that speaks SAML, OIDC, CAS, LDAP and SCIM, start a Casdoor Cloud trial or self-host Casdoor in a few minutes. For the protocol-level details, see SAML vs OIDC and identity provider vs service provider.