Authentication and Admin

Synced with starter commit 7d452a6.

Sushi SaaS uses Better Auth for email/password, verified email, password recovery, sessions, optional Google OAuth, and two-factor authentication. Every new user receives a personal organization; teams are a shipped capability, not a future placeholder.

Set BETTER_AUTH_SECRET, BETTER_AUTH_URL, NEXT_PUBLIC_AUTH_BASE_URL, and the public web URL. Google OAuth is optional. Production sign-up and sensitive auth flows also require Redis-backed rate limiting and Turnstile. Resend delivers verification and recovery messages; local development can safely log links when no provider is configured or AUTH_DEV_EMAIL_LINKS=true. That flag is rejected in production.

Identity and Authorization

• Better Auth's string user ID is the authentication identity; the application's user.uuid is its public domain identity.
• Email plus provider is unique, but email is never an authorization key.
• Organization roles (owner, admin, member) decide actions; plan entitlements decide features and limits.
• Server routes authenticate before data access. Client error copy is resolved from stable error codes, never raw server messages.

Separate Admin Application

Run pnpm dev:admin on port 3001. Deploy apps/admin independently and give it its own origin and auth base URL. Promote operators with pnpm admin:promote; admin_ro may inspect while admin_rw may mutate. Admin access requires MFA, and write operations produce audit records. Do not repurpose organization roles as platform-admin roles.

Before launch, test sign-up, verification, sign-in, recovery, Google callback if enabled, session revocation, MFA enrollment, and both admin permission levels. Follow the dedicated Admin Console Setup and Access guide for deployment and operator onboarding.