Don't Panic: Federated Identity

Federated identity lets one service accept another party's authentication result. A subject signs in at an identity provider. The relying party receives verifiable evidence, validates it, creates a local session, and decides what the subject may do. This is not trust falling from the sky. It is trust arriving with paperwork and a strict reading list.

Keep the boundary clear. The identity provider, or IdP, authenticates the subject. The relying party, or RP, owns the application and its local authorization decision. A signed assertion can say who authenticated and under which conditions. It does not grant universal permission to rummage through the application like a raccoon with a badge.

Two protocol families dominate. SAML uses XML assertions and metadata, and remains common in enterprise single sign-on. OpenID Connect is an identity layer on OAuth 2.0, using an ID Token for authentication claims. OAuth access tokens are for delegated access to protected resources. They may look similar to ID Tokens in some deployments, but similar packaging is not similar purpose.

Validation is the real work. Check the trusted issuer, audience, signature, accepted algorithm, lifetime, redirect URI, state, nonce when used, and the token or assertion's intended context. A valid signature only says the evidence was not forged under that key. It does not say the evidence was meant for this RP, this transaction, or this resource.

Account mapping deserves suspicion. Store issuer plus subject identifier as the federated identifier. Email is an attribute, not a universal identity key. It can change, be reassigned, or mean different things at different providers. Claims and groups are inputs to local policy, so map them deliberately and deny malformed surprises.

Use the Practice Reference for the validation and lifecycle checklist. Do the Exercise to design an RP integration without collapsing sign-in, provisioning, sessions, and authorization into one optimistic blob. The Cheatsheet is the compact reminder: IdP authenticates, RP validates, RP authorizes, and every boundary needs configuration, observability, and a tested failure path.