Identity federation
Trusting another organization to authenticate its people, so they can use your app with accounts controlled by their own IT.
See it
What it is
Identity federation is a trust agreement between administrative domains. Your app does not authenticate an enterprise employee directly; it trusts a signed SAML assertion or OpenID Connect ID token from the employee's identity provider, then maps that external identity to a local account and permissions.
Reach for it when customers need their own Okta, Microsoft Entra ID, Google Workspace, or another IdP to control who can sign in. It is the foundation under enterprise SSO and cross-organization login, letting the customer's IT team enforce MFA and disable access at their end. Universities have run this shape for two decades through Shibboleth and the InCommon federation, which is why a campus login often bounces you to a page branded by your own school.
The gotcha is confusing authentication trust with account lifecycle. Federation proves an identity at login; it does not automatically provision, update, or remove local memberships, and logout may not propagate to every relying app. Validate issuer, audience, signature, expiry, and nonce, key OIDC identities on issuer plus subject, and never accept an email domain alone as proof of federation.
Ask AI for it
Add per-organization identity federation over OpenID Connect. Let an admin configure the issuer URL, client ID, client secret, allowed email domains, and exact redirect URI; load discovery from /.well-known/openid-configuration and use Authorization Code Flow with PKCE, state, and nonce. On callback verify the ID token signature against JWKS plus iss, aud, exp, and nonce, then key the external identity on issuer plus sub rather than email. Route users to the right connection from a verified organization domain, support several issuers per organization, create local membership only under an explicit just-in-time provisioning rule, and audit configuration, login, linking, and denial events.