System and boundaries
Identity federation lets a relying party consume an authentication or identity result from an identity provider. The parties establish trust in issuers, keys, protocols, claims, assurance, and lifecycle behavior. Federation reduces repeated authentication integration. It does not make the two systems one security boundary.
Request and decision flow
The relying party sends or participates in an authentication request. The identity provider authenticates the subscriber and issues an assertion or token. The relying party validates it and creates local session state. Account mapping and authorization follow as separate steps.
Trust configuration
Validate issuer, audience, signature, time, nonce or request binding, redirect targets, and required protocol fields. Select only needed claims. Define how issuer and subject identifiers map to the local account. Record provider changes, key rotation, assurance, and termination behavior.
Failure domains and residual risk
A compromised or misconfigured identity provider can issue valid results for the wrong subject. Account linking can merge unrelated identities. Stale claims can preserve old group data. Single sign-on can expand impact when many relying parties depend on one provider.
Pomerium boundary
Pomerium acts as a relying party to a configured OpenID Connect identity provider. It validates the provider result and creates a Pomerium session. The operator owns provider selection, client configuration, claim release, account mapping, and the assurance of provider enrollment and recovery.
Evaluation checklist
- Which issuer and subject pair identifies the account?
- Are audience, signature, time, request binding, and redirect targets validated?
- How are claims mapped, refreshed, and removed?
- Can account linking join identities from different issuers incorrectly?
- What happens when the provider, its keys, or its directory is unavailable?
