asa install auth-basic

Auth that works on day one. Secure by default.

Not a TODO skeleton. A fully functional auth flow — register, login, logout, reset-password — with server-side security verification, RLS templates, and lint-enforced guardrails.

See What You Get →
$ asa install auth-basic

Auto-installs dependencies: db-basic (auto-installed)

What You Get

Fully functional slices — not TODO skeletons.

R

register

Email + password registration with profile creation, input validation, and error handling. Server-side verified.

L

login

Secure login with HttpOnly cookie-based session. Uses getUser() — not getSession() — for verified auth.

L

logout

Clean session termination. Clears auth cookies, redirects to login.

R

reset-password

Full password reset flow — request email, verify token, set new password.

Generated File Map

Every file is real, functional code you own.

domains/auth/register/
domains/auth/login/
domains/auth/logout/
domains/auth/reset-password/
shared/auth/middleware.ts
shared/auth/session.ts
shared/auth/guards.ts
shared/auth/server-user.ts
shared/auth/hooks.ts
shared/auth/types.ts
shared/db/migrations/001_profiles.sql

Security Guarantees

Built-in protection — not an afterthought.

getUser() enforcement

Server-side auth checks use getUser() which verifies the JWT with Supabase. getSession() reads unverified cookies — blocked by lint rule SEC-002.

HttpOnly cookie-based sessions

No tokens in localStorage. Session is managed via HttpOnly cookies that cannot be accessed by JavaScript.

Server-side handler verification

Every route handler re-verifies auth server-side. Middleware is defense-in-depth, not the only check.

RLS templates

Row Level Security policies for user-owned data. Tables have RLS enabled by default — blocked by SEC-006 if missing.

Client/server boundary separation

Admin/service-role client is restricted to server-side code. Lint rule SEC-001 blocks service_role key in browser-capable files.

Email enumeration prevention

Register and reset-password return generic errors. No information leakage about existing accounts.

What This Prevents in Production

Real problems this module eliminates before they cost you customers.

Token theft via localStorage

AI-generated auth stores tokens in localStorage by default. One XSS vulnerability exposes every user session.

Unverified session trust

Using getSession() reads unverified cookies. Attackers can forge session data. Only getUser() verifies the JWT server-side.

Account enumeration on register

Typical AI output returns 'email already exists' — letting attackers harvest valid accounts for credential stuffing.

Missing RLS on user data

Without Row Level Security, any authenticated user can read other users' data via direct Supabase queries.

Client-side-only auth checks

AI tools often protect routes only in the browser. Server-side handlers remain wide open to direct API calls.

service_role key in browser code

Leaking the admin key to the client gives any user full database access — bypassing all security policies.

Extension Points

Your code. Your rules. Extend when ready.

  • Add social auth providers (Google, GitHub) by extending the login handler
  • Add MFA/2FA by extending the login flow with a verification step
  • Add profile fields by extending the profiles migration and register schema
  • Add email verification by extending the register handler with a confirmation flow
  • Add session management (active sessions, device list) by extending shared/auth

Protected by 22 Lint Rules

Every module is enforced by ASA CLI's tiered lint engine. 8 blockers catch critical security issues. 8 warnings flag architectural risks. 6 info rules guide best practices.

8
Blockers
8
Warnings
6
Info

Run asa lint anytime. Runs in CI too.

Auth that AI tools get wrong by default. Fixed from install.

Server-verified sessions, RLS templates, and 22 lint rules — production-grade auth in one command.

New app? Start with Build Right. Existing app? Start with a Quick Scan before stabilization.

View All Foundation Modules →