Supabase Authentication: Complete Setup Guide
Every auth method, the full Next.js App Router integration, Row Level Security wiring, and the production security checklist 4Byte uses on every SaaS build.
How Supabase Auth Works
Supabase Auth is a fully managed authentication service built on GoTrue — an open-source auth server. When a user signs in, Supabase issues a JWT (JSON Web Token) stored in the browser. Every database request includes this token, which Supabase uses to enforce Row Level Security policies — automatically scoping data to the authenticated user without any application-layer filtering.
The key difference from most auth libraries: Supabase Auth is wired directly into the database. The auth.uid() function is available inside every PostgreSQL RLS policy, creating a seamless, secure bridge between who is logged in and what data they can access.
▸ Auth Methods
Every Authentication Method Supabase Supports
Six auth methods covering every use case — from simple email/password to enterprise SSO.
Email & Password
The standard auth method — users register with an email and password, which Supabase stores as a bcrypt hash. Email confirmation can be required before access is granted.
- bcrypt password hashing
- Email confirmation flow
- Password reset via email link
- Custom SMTP support
Magic Links
Passwordless authentication — users enter their email and receive a one-time sign-in link. No password to remember, no password to leak. Ideal for low-friction onboarding.
- One-time use sign-in links
- Expires after configured time
- Works alongside email/password
- Custom email templates
OAuth Providers
Social login via third-party providers — Google, GitHub, Apple, Twitter, Facebook, LinkedIn, and more. Uses PKCE flow for secure token exchange without exposing secrets.
- Google, GitHub, Apple & 15+ providers
- PKCE flow — secure by default
- Automatic profile data capture
- Custom OAuth scopes supported
Phone OTP
SMS-based one-time password authentication — users enter their phone number and receive a 6-digit OTP via SMS. Requires a Twilio or equivalent SMS provider integration.
- SMS OTP via Twilio / MessageBird
- 6-digit one-time code
- Works for login and verification
- Rate limited to prevent abuse
SAML 2.0 / Enterprise SSO
Enterprise Single Sign-On via SAML 2.0 — allows organisations to authenticate users through their existing identity provider (Okta, Azure AD, Auth0) rather than Supabase credentials.
- Okta, Azure AD, Auth0 support
- Domain-based SSO routing
- Available on Pro plan and above
- Custom attribute mapping
Multi-Factor Authentication
TOTP-based MFA adds a second verification step — users must enter a time-based one-time password from an authenticator app (Google Authenticator, Authy) after their primary login.
- TOTP (RFC 6238 standard)
- Works with Google Authenticator & Authy
- Enforced or optional per user
- Recovery codes provided on setup
▸ Setup Guide
Supabase Auth in Next.js — 6-Step Implementation
The exact process 4Byte follows to set up production-grade Supabase auth on every Next.js project.
Install Supabase packages
Add @supabase/supabase-js for the core client and @supabase/ssr for Next.js server-side auth support. These two packages cover everything needed for both client and server components.
npm install @supabase/supabase-js @supabase/ssrDo not use the older @supabase/auth-helpers-nextjs package — it's deprecated. The @supabase/ssr package is the current standard for Next.js App Router projects.
Create Supabase client utilities
Create two client helpers — a browser client for Client Components and a server client for Server Components, Route Handlers, and Server Actions. Both read environment variables for the project URL and anon key.
// utils/supabase/client.ts
import { createBrowserClient } from '@supabase/ssr'
export const createClient = () =>
createBrowserClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)Never expose the service role key in environment variables prefixed with NEXT_PUBLIC_ — it bypasses all RLS policies and gives full database access.
Set up middleware for session refresh
Add a Next.js middleware file that refreshes the Supabase auth session on every request — ensuring the JWT is always fresh and Server Components always have access to the current user.
// middleware.ts
import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'
export async function middleware(request: NextRequest) {
let response = NextResponse.next({ request })
const supabase = createServerClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
{ cookies: { /* cookie handlers */ } }
)
await supabase.auth.getUser()
return response
}getSession() is not safe to use server-side for auth — it reads from the cookie without re-validating the JWT. Always use getUser() in middleware and Server Components.
Enable auth providers in dashboard
Enable the auth providers you need in the Supabase dashboard under Authentication → Providers. For OAuth providers, add the client ID and secret from the provider's developer console.
// Dashboard: Authentication → Providers
// Enable: Email, Google, GitHub
// Add redirect URL: https://yourdomain.com/auth/callbackAlways add your production domain to the allowed redirect URLs list before go-live. Forgetting this causes OAuth callbacks to fail silently in production.
Write RLS policies tied to auth
For every table that contains user data, enable RLS and write policies that reference auth.uid() to scope access to the authenticated user's own records only.
-- Enable RLS
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
-- Users can only see their own posts
CREATE POLICY "Users see own posts"
ON posts FOR SELECT
USING (auth.uid() = user_id);
-- Users can only insert their own posts
CREATE POLICY "Users insert own posts"
ON posts FOR INSERT
WITH CHECK (auth.uid() = user_id);A table with RLS enabled but no policies returns zero rows for all queries — not an error. Always test new tables with both an authenticated and unauthenticated request.
Protect routes with middleware guards
Add route protection logic to the middleware — redirect unauthenticated users away from protected routes to the login page, and redirect authenticated users away from auth pages to the dashboard.
// In middleware.ts — after session refresh
const { data: { user } } = await supabase.auth.getUser()
const isProtectedRoute = request.nextUrl.pathname.startsWith('/dashboard')
const isAuthRoute = request.nextUrl.pathname.startsWith('/login')
if (isProtectedRoute && !user) {
return NextResponse.redirect(new URL('/login', request.url))
}
if (isAuthRoute && user) {
return NextResponse.redirect(new URL('/dashboard', request.url))
}Client-side route guards are not sufficient — a determined user can bypass JavaScript checks. Always enforce auth at the middleware or server level.
▸ RLS Patterns
4 Row Level Security Patterns Used in Production
Copy-paste RLS policies for the most common data access scenarios in SaaS applications.
User owns record
Personal data — a user's own profile, notes, or settings
USING (auth.uid() = user_id)Organisation membership
Multi-tenant SaaS — users access data belonging to their org
USING (organisation_id IN (SELECT org_id FROM members WHERE user_id = auth.uid()))Public read, owner write
Public content — anyone can read, only authors can write
FOR SELECT USING (true)
FOR INSERT WITH CHECK (auth.uid() = author_id)Role-based access
Admin panels — only users with admin role can access certain tables
USING (auth.uid() IN (SELECT user_id FROM roles WHERE role = 'admin'))▸ Security Checklist
Supabase Auth Production Security Checklist
Every item 4Byte verifies before shipping a Supabase auth implementation to production.
▸ Why 4Byte
Auth Done Right — From Day One
4Byte treats authentication as a non-negotiable foundation — not an afterthought. Every SaaS we build ships with RLS on every table, getUser() in middleware, and every item on the security checklist verified before launch.
If you're building a SaaS product and want auth set up correctly the first time, our free strategy call is where we start.
Currently accepting new SaaS projects
Free strategy call · Response in ≤ 4 hours · No obligation
▸ FAQ
Supabase Authentication — Common Questions
How does Supabase authentication work?+
Supabase Auth is a fully managed authentication service built on top of GoTrue — an open-source auth server. When a user signs in, Supabase issues a JWT (JSON Web Token) that is stored in the browser. Every subsequent database request includes this token, which Supabase uses to enforce Row Level Security policies — automatically scoping data access to the authenticated user.
What authentication methods does Supabase support?+
Supabase supports email and password, magic links (passwordless email), OAuth providers (Google, GitHub, Apple, Twitter, Facebook, LinkedIn, Spotify and more), phone OTP via SMS, SAML 2.0 for enterprise SSO, and anonymous sign-ins. Multi-factor authentication (TOTP) is also supported for additional security.
How do I integrate Supabase auth with Next.js App Router?+
Use the @supabase/ssr package, which provides createServerClient and createBrowserClient helpers designed for Next.js App Router. The server client reads the auth cookie server-side for use in Server Components and API routes, while the browser client manages the session in Client Components. Middleware is used to refresh the session on every request.
How does Supabase auth integrate with Row Level Security?+
Supabase automatically makes the authenticated user's ID available as auth.uid() inside PostgreSQL RLS policies. This means you can write policies like "users can only SELECT rows where user_id = auth.uid()" — enforcing data isolation at the database level without any application-layer filtering logic.
Is Supabase auth secure enough for a production SaaS?+
Yes, when configured correctly. Supabase Auth uses industry-standard JWT tokens, PKCE flow for OAuth, bcrypt password hashing, and supports MFA. The critical security requirements are: enabling RLS on every table, using the anon key client-side (never the service role key), configuring allowed redirect URLs, and enabling email confirmation for new accounts.
Can Supabase handle multi-tenant authentication?+
Yes. Supabase Auth combined with PostgreSQL Row Level Security is the standard pattern for multi-tenant SaaS applications. Each user belongs to an organisation, and RLS policies use auth.uid() to enforce that users can only access data belonging to their organisation — without complex application-layer logic.
▸ Continue Learning
Related Technology Stack Resources
Let's Build Your Authentication System Right the First Time.
Book a free 30-minute call with 4Byte. We'll review your auth requirements and set up a secure, production-ready Supabase auth system — no pressure, no obligation.
Auth Expert
RLS configured right
28-Day MVP
Avg. delivery time
No Obligation
Zero pressure call