Auth
A shared authentication foundation for password and OAuth entry, recovery, MFA, connected providers, safe return paths, and explicit logout across the application family.
- 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
I built a standalone Auth and account-security application plus a shared authentication package for browser and server clients, versioned session behavior, safe returns, and explicit logout scopes. Auth owns sign-in, recovery, MFA, profile, providers, and logout. Studio and Admin send those flows to Auth. Compatibility callbacks may finish an already-issued link; they are not a second login UI.
How the system fits together
Supabase Auth is the identity provider. Auth-web owns entry, recovery, MFA, and account security. Shared cookie and return contracts let Studio and Admin consume the session without owning credentials.
The calls that shaped the build
- 01
Share mechanics, keep authorization local
Session and redirect contracts are reusable, but Portfolio, Studio, Admin, and Auth still decide which routes are public, authenticated, role-gated, or require an assurance-level step-up.
- 02
Validate every return destination
Callbacks, recovery, entry, and logout accept only safe paths or configured application origins, so a convenient return parameter cannot become an open redirect.
- 03
Keep Auth the only sign-in UI
Versioned session modes remain for rollback, but Studio and Admin send people to Auth for entry, recovery, and MFA. Compatibility callbacks may finish an already-issued link; they are not a second login screen.
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
A shared identity layer reduces long-term duplication but requires coordinated cookies, callbacks, and deploys. Product authorization still stays in each app, so Auth is not a catch-all permission system.
Why the work matters
The platform has a dedicated account-security surface and reusable session contracts. Auth is the interactive entry owner. Studio and Admin decide which routes are public, signed-in, or role-gated.
What I would improve next
Keep tightening recovery, MFA, and logout checks as the apps add routes, without growing a second authentication UI outside Auth.