Auth Setup

Authentication is the question every app must answer before it can do anything else: who is this person, and should I let them in?

Building authentication from scratch is genuinely hard. You need to hash passwords securely, issue tokens, manage sessions, handle password resets, prevent brute-force attacks, and comply with security standards. Done badly, your users' accounts are at risk. Done well, it takes weeks.

Supabase Authentication does all of this for you, correctly, from the first project you create.

---

Why First

Think about the login system at your CA firm. When a new staff member joins, IT creates them a username and a password. They log in with those credentials and can access only what their role allows — a junior can see their assigned clients but not the firm's billing records. A partner can see everything.

When they forget their password, they click "Forgot password" and get an email with a reset link. When they leave the firm, IT disables their account — immediately, with one click.

Supabase Auth is this system, built for your app. It handles the credential storage, the session management, the password reset emails, and the account lifecycle. You configure the rules. Supabase enforces them.

---

Navigating to Auth

Click "Authentication" in the left sidebar. You see a tabbed interface with several sections:

---

Understanding Auth Out of the Box

When you create a Supabase project, email authentication is enabled by default. Users can sign up with an email and password immediately — no configuration required.

By default:

• Email confirmation is enabled — after signing up, users receive a confirmation email and must click the link before they can log in
• Password minimum length: 6 characters (you can change this)
• Secure password storage: Supabase hashes passwords using bcrypt — you never see the actual password, even in the Users tab

---

Exploring the Users Tab

Click "Users" in the Authentication section. The table shows all registered users with:

The Users tab — every registered user, their provider, last sign-in, and confirmation status.

• Email address — their login identifier
• Provider — how they signed up (email, Google, GitHub)
• Created — when their account was created
• Last sign in — the most recent login
• Status — whether the account is confirmed

What you can do from here:

• View a user's details: click on any row to see their full profile, including their unique user ID (uuid) — the same ID that appears in your database tables linking records to that user
• Delete a user: click the three-dot menu on a user's row. Use this carefully — deleting a user does not automatically delete their data in your other tables
• Invite a user: the "Invite user" button sends an invitation email — useful for admin portals where you control who gets access

---

Configuring Providers

Click "Providers" in the Authentication sidebar.

You see a list of available sign-in providers. Each can be toggled on or off:

For training projects, Email is sufficient. For production apps, adding Google Sign-In significantly reduces sign-up friction — most users prefer clicking a button to filling in a form.

Email provider settings (click on "Email" in the providers list):

• Confirm email: Toggle this off during development so you don't have to confirm every test account you create. Toggle it on for any production app — unconfirmed email addresses mean users can sign up with someone else's email.
• Secure email change: On by default — requires confirming both old and new email when changing address. Leave this on.
• Minimum password length: Default is 6. For production apps, increase this to at least 8.

---

Email Templates

Click "Email Templates" in the Authentication sidebar.

Supabase sends emails automatically for these events:

Each template has a default version that works immediately. You can customise the subject line, the HTML body, and the text body.

For training projects, the defaults are fine. For client apps, you customise these to match the client's brand — their logo, their colour scheme, their voice. This is a significant detail that separates professional apps from amateur ones.

---

URL Configuration

Click "URL Configuration" in the Authentication sidebar.

When a user clicks a confirmation link in their email, Supabase redirects them to your app. You configure where:

• Site URL: The base URL of your app — https://your-app.vercel.app for production, http://localhost:5173 for local development
• Redirect URLs: A list of allowed redirect destinations — your app can send users to specific pages after confirmation (e.g., /auth/callback). Supabase only accepts redirects to URLs in this list — anything not listed is rejected for security.

For local development, add http://localhost:5173/** to the Redirect URLs list. The ** wildcard allows any path on that origin.

---

The profiles Table Pattern

Supabase Auth stores the minimum — email, encrypted password, user ID. It does not store names, roles, avatars, or any business data. That is intentional — you store business-specific user data in your own profiles table.

The standard pattern (used in every project in this training) is:

1. A profiles table with a user_id column that references the Supabase auth user
2. A database trigger that automatically creates a profile row when a new user signs up
3. RLS on profiles so each user can read their own profile, admins can read all

You will build this in Project 2. For now, understanding that Auth and the profiles table work together is the key conceptual step.

---

Creating a Test User

Before testing your app's login functionality, create a test user directly from the dashboard:

---

Summary

Supabase Auth handles all six. You configure the rules. You build the UI. Supabase does the security-critical work.