Where it started
An authentication provider can tell an app who signed in. The harder question is how the app keeps ownership, organizations, and access consistent when providers or sessions change.
The boundary that matters
Keep the business identity separate from the provider identity. Products can connect to a stable identity and explicit access contract, while authentication remains a replaceable part of the system.
- 01Sign inEmail OTP / provider
- 02IdentityStable business subject
- 03AccessExplicit product grants
- 04ProductsSessions and logout
What I worked on
- An internal Auth service with email OTP, an OIDC issuer, and centrally managed clients.
- A private SDK with a defined compatibility surface and explicit organization and access boundaries.
- Session and logout behavior across protocol clients, plus migration rehearsals with controlled data.
What was verified
Production acceptance on 27 September 2026 verified real email sign-in, initial administrator authorization, OIDC SSO across two temporary protocol clients, and central logout. Provider migration was rehearsed using a reference consumer.
Based on the project’s dated acceptance records. Diagrams show the design; they are not a live demo.
The next questions
The two protocol clients establish issuer behavior. They do not establish that every product has migrated. The SDK has a bounded compatibility surface; it is not a complete replacement for every provider API.
What I take from it
Recovery is part of the interface. Separating identities makes it possible to change a provider without silently changing who owns the data.