What is Supabase Auth?

Updated

Supabase's hosted authentication service — handles email/password, magic links, OAuth (Google / GitHub / Apple / many more), phone-OTP, and SAML SSO. Issues JWTs that work seamlessly with Supabase's RLS policies.

Full explanation

Supabase Auth is one of three pillars of the Supabase platform (alongside Postgres + Storage). It runs the GoTrue auth server, issuing JWT tokens after successful authentication. The JWT contains the user's `sub` (subject) claim that RLS policies reference via `auth.uid()`, plus `role` (typically `authenticated` for logged-in users), and any custom claims you add via Auth Hooks. Common bugs: missing email verification, weak password policies, missing CAPTCHA on signup (bot attacks), failing to set `email_confirm` requirement, and auth callbacks that don't validate the OAuth state parameter.

Example

Default Supabase Auth setup with Google OAuth: signup is open, email verification is on by default, JWT claims include `sub` (user UUID) and `role: authenticated`. RLS policy `using (auth.uid() = user_id)` filters rows by the JWT's `sub`. A common bug pattern: developer disables email verification 'for testing' and forgets to re-enable, allowing unverified-email account takeovers.

Related

FAQ

Should I use Supabase Auth or Clerk / NextAuth?

Supabase Auth is the right choice when your data layer is Supabase Postgres — the JWT integration with RLS is seamless. Clerk and NextAuth are richer for complex auth flows (multi-tenant orgs, SAML at low scale, custom session shapes) but require manual integration with your RLS policies. For most vibe-coded apps, Supabase Auth is the simpler and faster choice.

What auth attack surfaces does Supabase Auth NOT cover?

It covers authentication (proving who you are). It does not cover authorization (proving what you can do) — that's RLS + your application's permission checks. It does not cover credential-stuffing protection beyond default rate limits — bring your own anti-bot if you face material attack volume. It does not cover account-recovery flows beyond defaults — review your password-reset and email-change flows for token-expiry and single-use enforcement.