Supabase Auth is the login system built into Supabase: it stores users in your project's Postgres database, signs them in by password, magic link, one-time code or a provider such as Google, and issues the session that your database rules read. To add login to a web app, you ask your AI builder for the sign-in methods and the roles, then check three settings in the Supabase dashboard: the Site URL, the redirect URLs and the email sender.
This guide explains what each part does, which choices matter, and which sentences to put in your prompt. For the access rules themselves, read our guide to Supabase row level security.
What Supabase Auth does and does not do
Supabase Auth proves who a user is; it does not decide what that user may see. Its documentation lists the sign-in methods: password, magic link, one-time password, social login (Apple, Google, GitHub and any OAuth2 or OIDC provider), phone through providers such as Twilio, and enterprise SAML single sign-on. User data lives in a special schema of your own Postgres database.
What a user may do is a second layer. The Supabase client sends the user's token with each request, and row level security policies in the database use it to filter rows. Authentication answers "who is this?", and the policies answer "which rows can this person read or change?". An app with login but no policies is open.
Which sign-in method to choose
Pick the method that matches how your users already behave: Google for a consumer or startup audience, email and password for business tools, magic link when people log in rarely. Each has a cost, summarised below.
| Method | Good for | Pros | Cons |
|---|---|---|---|
| Email and password | Business tools, client portals | Familiar, works for any email address, no third party | Needs confirmation and reset emails; users forget passwords |
| Magic link or email code | Rare logins, non-technical clients | No password to store or forget | Every login sends an email, so deliverability and sending limits matter |
| OAuth (Google, GitHub) | Consumer apps, startups, developer tools | One click, no password reset flow, no email to send | You must create the provider credentials and register the redirect URL; not every client has the account |
| Phone code | Markets where phone is the identity | Fast on mobile | Needs an SMS provider account, and each message is billed by that provider |
| Enterprise SSO (SAML) | Selling to large companies | Companies manage access centrally | Setup per customer; check the plan requirements on Supabase's pricing page |
Email confirmation and password reset
With email confirmation on, a new user cannot sign in until they click the link in the message. Supabase's configuration page states that if you turn it off, the email is treated as confirmed without any check. Keep it on for anything with real users: without it, anyone can create an account with an address that is not theirs.
Password reset works the same way: the user asks for a link, receives an email and lands on a page of your app where they choose a new password. Both flows depend on two things you control: the redirect settings below and the email sender. If a confirmation link opens "localhost" or an error page, the cause is almost always the redirect settings.
Sessions: what happens after login
After login, Supabase gives the browser a short-lived access token and a refresh token, and the client library renews them without asking the user to sign in again. According to the sessions documentation, the access token is a JWT that expires after 1 hour by default, and each refresh token can be used only once. If an old refresh token is replayed outside a short window, the whole session is ended.
For a builder user, the practical point is that you rarely write session code. You ask for "keep users signed in" and "redirect to the login page when signed out", and the generated app uses the client library for the rest.
auth.users versus a profiles table
Keep the login record in auth.users and everything else about the person in a table of your own, usually called profiles. The Supabase guide on managing user data explains why: the auth schema is not exposed in the automatic API, so your app cannot read it directly. The recommended pattern is a public profiles table whose id references auth.users with on delete cascade, with row level security enabled, and a trigger that creates the profile row after each sign-up.
The same guide warns that a failing trigger can block sign-ups, so test it with a real new account after every change to the table. This is a common cause of "Database error saving new user" after an AI edits the schema.
Roles: admin, member, client
Store the role in your own table, not in the login record, and let row level security enforce it. A column such as role on profiles works for one organisation. When one person can belong to several companies or workspaces, use a memberships table (user, organisation, role) instead, so the same person can be admin in one and client in another.
Hiding a menu item for clients is not security: the database must refuse the request. A policy like "a client can read only the invoices where client_id matches their own membership" does that. Never let users edit their own role column; the policy on profiles should allow updating the name and avatar but not the role.
Invitation-only sign-up for internal tools and portals
For an internal tool or a client portal, switch off open sign-up and create accounts only on invitation. Supabase has an "Allow new users to sign up" setting; when it is disabled, only existing users can sign in. The invitation itself, which creates the user, assigns the role and sends the email, has to run on the server, in an edge function, because it needs a secret key that must never reach the browser.
The flow to ask for: an admin enters an email and a role, the server creates the user and the membership row, and the invited person receives a link to set a password. Our guides on internal tools and client portals show where this fits in a full app.
Site URL and redirect URLs
The Site URL is the default address Supabase sends users back to, and the redirect URLs are an allow list of other addresses it may use. The redirect URLs documentation says the Site URL starts as http://localhost:3000 and must be changed to your production address, because email confirmations and password resets depend on it.
Add every real address your app is served from: your production domain, your custom domain if you have one, and any preview address you test on. The documentation recommends exact paths in production and wildcards mainly for local development and previews. The classic failure is a published app whose emails still point to localhost, or a custom domain added later and never registered.
Email limits and custom SMTP
Supabase's built-in mailer is for testing only: as of November 2026 its documentation says it is limited to 2 messages per hour, delivers only to addresses on your organisation's team, and comes with no delivery guarantee. Those numbers can change without notice, so read the custom SMTP page before launch.
Before real users arrive, plug in your own provider (the page lists Resend, AWS SES, Postmark, SendGrid, ZeptoMail and Brevo as examples). The same page notes that custom SMTP starts at 30 messages per hour, adjustable on the rate limits page, and recommends authenticating your sending domain with DKIM, SPF and DMARC. If your first test user never receives the confirmation email, this is the reason, not a bug in your app.
How Cadrant sets it up
Cadrant, our builder, uses Supabase Auth in a Supabase project that belongs to your own Supabase account, so the user accounts stay yours. According to our authentication documentation, it generates the login and signup pages, configures email and password signup, protects the routes that need a session, and manages sessions. OAuth providers such as Google are enabled by you in the Supabase dashboard under Authentication, Providers.
The AI writes the migrations with row level security on per-user tables and can read the current schema and policies before it changes them. Roles are described in the prompt and stored in columns or tables of your database. Secrets such as an email provider key stay in environment variables behind edge functions. Limits to know: the Site URL, redirect URLs, provider credentials and custom SMTP are Supabase settings that you check yourself, and you should test each role by hand before inviting customers. See also our overview of Supabase with an AI builder.
Prompt sentences to paste into your AI builder
Describe the people and the rules, not the code. These sentences work in most builders:
- "Add login with email and password and with Google. Users must confirm their email before signing in."
- "Create a profiles table linked to the auth users, filled automatically at sign-up, with a role column (admin, member, client). Users can edit their name but never their role."
- "Sign-up is closed. Only an admin can invite a user by email and choose their role, from a server-side function."
- "A client sees only their own records. A member sees the whole team. An admin sees everything and manages users. Enforce this with row level security, not only in the interface."
- "Add a Forgot password link and a page to set a new password. Redirect signed-out users to the login page."