Learning outcomes
- Bind each sign-in response to the selected issuer, client, request, and redirect.
- Keep issuer-scoped subject identifiers distinct across providers and tenants.
- Design explicit account linking, unlinking, migration, and recovery.
- Test routing, mix-up, collision, takeover, and deprovisioning paths.
System and boundaries
The system includes user discovery or provider choice, several issuers, separate client registrations, redirects, request-correlation state, subject namespaces, local accounts, link records, lifecycle feeds, administrators, and recovery. Provider selection is security state, not presentation only.
Request and decision flow
- Select an issuer from trusted tenant or user context.
- Use the client and redirect registered for that issuer.
- Bind state, nonce, PKCE, issuer, client, redirect, and browser session.
- Validate the response under that issuer's metadata, keys, and claims.
- Key the local subject by issuer plus stable subject identifier.
- Link accounts only after explicit proof and policy approval.
- Propagate lifecycle, unlink, and recovery changes to every linked authority.
Failure domains
An attacker can substitute an issuer, return a response to the wrong client, collide on email, claim an unverified domain, link an attacker-controlled account, recover through a weaker provider, or retain access after one source deprovisions the user. Home-realm discovery can leak identifiers and route users to a deceptive provider.
Design tradeoffs and residual risk
Automatic linking improves convenience and turns mutable attributes into security keys. Manual linking reduces collision and adds support and recovery risk. One canonical identity simplifies policy and can hide source-specific assurance and lifecycle.
Residual risk includes compromised issuers, administrator links, stale lifecycle data, and applications that key accounts by email after the gateway preserves issuer identity.
Pomerium boundary
Pomerium can integrate with configured identity providers and route authentication according to supported deployment features. Operators and applications own provider selection, registration isolation, local account keys, linking policy, lifecycle reconciliation, and recovery. Pomerium cannot prove that two issuer accounts belong to one person from a matching email alone.
Exercise
Configure two test issuers with the same email and different subject identifiers. Test correct sign-in, wrong issuer response, stale state, wrong nonce, issuer mix-up, duplicate email, explicit linking, unlinking, deprovisioning, and recovery through each provider.
Evaluation checklist
- Is issuer selection bound to the request and verified in the response?
- Are clients, redirects, metadata, keys, and subject namespaces isolated by issuer?
- Can no mutable display attribute link accounts automatically?
- Do unlinking, deprovisioning, and recovery remove all derived authority?
- Does the application retain issuer-scoped identity after the gateway?
Next learning unit
Identifier, Account, Record, and Person
Separate a label, system account, directory record, and real person before joining identity across systems.
