Authentication and Google sign-in

Included authentication methods

The starter supports email/password signup and login, magic links, password recovery, logout and Google OAuth when configured. Supabase Auth owns identities and sessions. Next.js server code verifies the current user before protected work. Ordinary signup creates a profile, workspace and owner membership; an invited signup follows a different guarded bootstrap path.

The UI is in components/auth, page routes are in app/(auth), actions are in app/actions/auth.ts, and verified access helpers are in lib/auth.ts. Auth confirmation/callback routes complete provider redirects. Avoid putting a provider credential directly in an auth component.

Email and password

Install the hosted schema, Auth settings and signed email hook through kickstart. Sign up at the application's configured origin. With verification off, Supabase confirms new email/password accounts according to the configured setting; protected server code still requires a confirmed user.

Login checks should include a wrong password, a signed-out dashboard visit and a valid account after reload. Never treat the presence of a browser cookie or an unverified getSession() payload as sufficient server authorization. requireUser() uses the verified user flow and redirects missing sessions to login.

Email verification

Change the existing root setting:

AUTH_EMAIL_VERIFICATION=true

Then run the appropriate kickstart check and provisioning/reconciliation for the current active origin. Restart/redeploy runtime configuration as needed. Editing the variable without updating hosted Auth leaves the app and provider inconsistent.

With verification enabled, a new email/password account must complete its emailed confirmation before entering protected UI. Test the actual received link, expiry, replay and recovery behavior with an authorized recipient. Generated confirmation links and mocked mail do not prove inbox delivery. Email delivery explains the signed hook.

Magic links and recovery

Choose the email-link method on login/signup and use the exact address you intend to authenticate. Supabase sends through the managed magic-link template. Follow the fresh link at the active app origin. A link may be one-use or expire; repeatedly opening an old message is not a valid retry strategy.

Password recovery is a separate flow. Google or magic-link users can establish a password using Set a password by email in Security before password-confirmed account changes or deletion. Existing current-password and confirmation guards remain in force.

Logout clears the application session. Test the next protected request rather than relying only on a menu changing appearance. Sessions, callback state and redirects should never be dumped into public diagnostics.

Set up Google sign-in

Google is optional. Follow Google OAuth client to prepare your Google Cloud project, create a web OAuth client and save its client ID and secret in Supabase. The guide also covers callback URLs, test users and the first sign-in check.

Kickstart manages the app's callback allowlist and reports Google provider status. It doesn't create or save Google credentials for you. Keep those credentials in Supabase's Google provider settings, outside root .env, Vercel variables and browser code.

Invited signups and server permissions

Invitation acceptance validates the secret, recipient identity and current invitation state. A valid new invite joins only the invited workspace. An existing user's other workspaces remain intact. Untrusted signup metadata cannot create an owner role or forge invited status.

Active invitations use their validated email flow; do not redirect an invited user through an unrelated social flow that loses the invitation context. An invalid invitation must not silently become ordinary signup with a new personal workspace. See workspace invitations.

The dashboard layout and requireUser() are navigation/session boundaries. Database RLS and role-aware RPCs remain necessary for record access. Every sensitive operation rechecks current permissions; a hidden button or cached role is not sufficient.

Callback errors and verification

Verify ordinary signup, verification-on signup, magic-link completion, recovery, logout and Google separately. Include real invitation inbox acceptance and a second buyer installation. Local compilation or a generated-link test does not close those provider checks.