Auth Platform
OAuth sign-in, multi-factor authentication, account recovery, and session management through Supabase Auth and Supabase SSR.
- Supabase Auth
- OAuth and PKCE
- SSR session contracts
- MFA and safe redirects
The product tension
Portfolio, Studio, Admin, and Auth need coherent identity behavior without each inventing its own cookie handling, callback rules, return URLs, recovery logic, MFA checks, provider controls, and logout semantics.
What I built
The account journey starts in a dedicated application: sign-in, recovery, MFA, profile and provider management, then a validated return to the requesting product. I integrated Supabase Auth and built the shared SSR session, safe-return and logout contracts consumed by Studio and Admin.
How the system fits together
Supabase Auth provides identities, sessions, and provider operations. Auth owns the interactive sign-in, recovery, MFA, profile, and connected-provider screens. Shared SSR cookie and return-destination contracts connect it to Studio and Admin.
Application profile reads and writes use Drizzle. A verified first app request provisions a missing IAM profile and Auth membership through conflict-safe inserts; it does not overwrite existing records or reactivate revoked access.
The calls that shaped the build
- 01
Keep one interactive entry owner
Studio and Admin redirect to Auth for sign-in, recovery, and MFA. Compatibility callbacks can finish an existing link without becoming another login implementation.
- 02
Validate return destinations
Return paths and configured application origins are checked so callback and logout convenience cannot become an open redirect.
- 03
Separate a session from product access
The shared session establishes identity. Each product still enforces live membership, capability, and resource checks.
Trust boundaries
PKCE OAuth, SSR session cookies, allowlisted return origins, MFA assurance checks, provider controls, explicit logout scopes, and database row-level security keep authentication and authorization boundaries separate and reviewable.
What I chose—and accepted
Shared cookies and callbacks require coordination across hosts. Provisioning on first verified app use removes the custom signup trigger, but dashboard-created accounts do not acquire application records until that first request.
Why the work matters
The products have one account-entry and recovery destination while retaining their own authorization rules. Supabase remains the identity provider; Drizzle owns application profile data and provisioning transactions. The migration article explains how those responsibilities were separated.
What I would improve next
Continue regression coverage for recovery, MFA, logout, revoked access, and first-request provisioning, and measure sign-in latency separately from destination-page rendering.