Authentication and users

Layout generates auth with Supabase Auth. You describe who should sign in and what they can see; Layout writes the UI, the session wiring, and the access rules. This guide covers what each flow looks like and how to prompt for it.

Prerequisites

• A project with Supabase connected (Layout connects it automatically on new projects)
• A rough idea of your user types and what each can do

Ask for auth with a clear scope

The best auth prompt names three things: the flows you want, the user types, and what a signed-in user can do.

Add authentication. Users sign in with email and password.
I need two user types: admin and member. Only admins can open /settings.
Everyone else sees the home page after signing in.

What Layout generates

For a standard email-and-password setup, expect:

• A profiles table keyed to auth.users for first name, last name, avatar
• A sign-up page and a sign-in page using the Supabase Auth UI
• A session provider that wraps the app and listens for auth state changes
• Redirects: signed-in users land on the main page, signed-out users land on sign-in
• Row-level security policies that scope data to the signed-in user

The flows

Sign-up

A form with email, password, and any profile fields you asked for. On submit, Supabase creates the user and a database trigger inserts a row in profiles. If email confirmation is enabled on your Supabase project, users see a "check your inbox" screen.

Sign-in

Email and password by default. Errors surface under the form — invalid credentials, unconfirmed email, locked account. Layout handles the common cases.

Sign-out

A button (in a menu, header, or profile page — pick where) that calls supabase.auth.signOut() and redirects to the public home page.

Password reset

A "forgot password" link from the sign-in page. The user enters their email, Supabase sends a reset link, and the link opens a page in your app where they set a new password.

Add a "forgot password" flow. Link from the sign-in page,
email-based reset, and a page for setting the new password.

Social providers

Not enabled by default. Ask for them explicitly — "add Google sign-in" or "support GitHub OAuth." You configure the provider credentials in the Supabase dashboard; Layout wires up the button and callback.

Protected routes

Layout decides protection from your prompts. Tell it which pages need a user and what happens to anonymous visitors.

Protect /dashboard and /projects. Anonymous users are sent to /sign-in.

Under the hood, each protected page checks the session on mount. If no session exists, it redirects. If the user's role is wrong, the page shows a 403.

Roles

Roles are fields on the user — typically a role column on profiles. Common patterns:

• admin and member — admins see extra pages or actions
• owner, editor, viewer — granular access to shared resources

Describe the rules in plain English:

Add a role column to profiles with values admin, editor, or viewer.
Only admins can delete projects. Editors can rename. Viewers are read-only.

Layout encodes those rules both in the UI (hide buttons) and in RLS policies (block writes at the database). Both layers matter — the UI keeps users from being confused, RLS keeps the data safe.

User profiles

Profile fields you named in the prompt end up on the profiles table. Common fields:

• first_name, last_name
• avatar_url (with an image upload backed by Supabase Storage)
• role
• bio or anything app-specific

A database trigger copies the new user's ID into profiles on sign-up, so the row exists before the user lands on their first page.

Sessions, in one paragraph

Layout wraps the app in a session provider that listens to supabase.auth.onAuthStateChange. Sign-in, sign-out, and token refresh propagate to every component without a page reload. You do not need to manage tokens yourself — the Supabase client handles storage and refresh.

Common pitfalls

Next steps