Federated Identity

Federated Identity delegates user authentication to a trusted external identity provider (IdP). Applications no longer store passwords or run their own login; instead they trust security tokens issued by the IdP after it authenticates the user.

The problem is that managing credentials in every application is costly and risky, and users dislike maintaining separate accounts. Federation centralizes authentication and enables single sign-on (SSO) across many applications and organizations.

How It Works

When a user accesses an application (the relying party), it redirects them to the IdP. The IdP authenticates the user, possibly with multi-factor authentication, and issues a signed token containing claims about the user's identity and attributes. The application validates the token's signature and claims and grants access accordingly. Standards such as OpenID Connect, OAuth 2.0, and SAML define these flows.

The IdP can be a corporate directory (Microsoft Entra ID, Okta), a consumer provider (Google, Apple), or a customer-identity service. A single sign-on session at the IdP lets the user access many applications without re-entering credentials.

When to Use It

Use it for SSO across multiple applications, to accept external or social logins, to integrate with partner and customer directories, and to centralize security controls like MFA and conditional access. It is the default for modern multi-application and B2B/B2C systems.

Avoid building bespoke authentication when a standards-based IdP will serve; rolling your own credential store is rarely justified.

Trade-offs

The application depends on the IdP's availability; an IdP outage blocks logins. Trust configuration (token validation, key rotation, audience and issuer checks) must be correct or it becomes a security hole. Mapping external claims to internal authorization adds work, and account lifecycle across federated sources needs governance.

Despite this, federation reduces credential sprawl and the attack surface compared with per-app password stores.

Related Patterns

It underpins Gatekeeper and Valet Key by establishing who the caller is before authorization. Configuration such as issuer URLs and client secrets is typically kept in an External Configuration Store or a secrets manager.

Example

A company's internal apps redirect unauthenticated users to Microsoft Entra ID. The user signs in once with MFA; Entra returns an OpenID Connect ID token and an access token. Each app validates the token's signature against the IdP's published keys and reads the user's group claims to authorize actions. A new internal tool gains SSO simply by registering as a relying party, with no password handling of its own.