Not every project needs user authentication. But the moment you need gated content, saved user preferences, a dashboard, or any kind of SaaS functionality, you need auth. Supabase makes this straightforward without building it from scratch or paying for Auth0 at scale.
This post covers when you actually need Supabase OAuth, when you do not, and the exact steps to set it up with Google, GitHub, and email/password providers.
What Supabase Is
Supabase is an open-source alternative to Firebase. It gives you a Postgres database, authentication, real-time subscriptions, edge functions, and file storage — all through a single dashboard and API. The key difference from Firebase is that your data lives in a real Postgres database, not a proprietary document store. You can write SQL. You can use joins. You can migrate away if you need to.
The free tier includes 50,000 monthly active users for auth, 500 MB database storage, and 1 GB file storage. For most side projects, that is more than enough.
When You Need OAuth
You need authentication when your application has any of these requirements:
User accounts. If people need to log in, save data, or have a personalized experience, you need auth. This includes dashboards, member areas, course platforms, and SaaS products.
Gated content. If some content is free and some requires a login or payment, you need auth to control access. This is common for premium blog content, exclusive tools, or community features.
Multi-user data. If users create data that only they should see — saved reports, custom settings, project files — you need auth combined with Row-Level Security to keep each user's data private.
API access control. If you are building an API that third parties consume, OAuth provides the token-based authentication flow that developers expect.
E-commerce personalization. Wishlists, order history, saved payment methods, and account management all require authentication.
When You Do NOT Need OAuth
This is just as important. Do not add auth complexity if you do not need it.
Static sites and blogs. If your site is informational content with no user interaction, skip auth entirely. A static site generated with Eleventy or Hugo does not need a database or login system.
Simple landing pages. A page that collects email addresses via a form does not need auth. Use a form handler like Netlify Forms or Formspree.
Public tools. If your tool works the same for everyone and does not save user data, skip auth. The tools on this site are a good example — they run in the browser with no login required.
Contact forms and newsletters. These are write-only operations. The user submits data but does not need to log in to do it.
Adding auth when you do not need it slows down development, adds maintenance burden, and creates friction for users. Only add it when the product requires it.
Step-by-Step OAuth Setup
1. Create a Supabase Project
Go to supabase.com and create a new project. Choose a region close to your users. Save the project URL and anon key — you will need both.
Project URL: https://yourproject.supabase.co
Anon Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
2. Set Up Google OAuth
In the Supabase dashboard, go to Authentication > Providers > Google and enable it. You need a Google Cloud OAuth client ID:
- Go to Google Cloud Console
- Create a new project or select an existing one
- Navigate to APIs & Services > Credentials
- Click Create Credentials > OAuth client ID
- Set the application type to Web application
- Add your authorized redirect URI:
https://yourproject.supabase.co/auth/v1/callback - Copy the Client ID and Client Secret into the Supabase provider settings
3. Set Up GitHub OAuth
Go to Authentication > Providers > GitHub in Supabase. Then create a GitHub OAuth App:
- Go to GitHub Settings > Developer Settings > OAuth Apps
- Click New OAuth App
- Set the authorization callback URL to:
https://yourproject.supabase.co/auth/v1/callback - Copy the Client ID and Client Secret into Supabase
4. Enable Email/Password
Email/password is enabled by default in Supabase. In Authentication > Providers > Email, you can configure:
- Whether to require email confirmation
- Minimum password length
- Whether to allow new signups
For development, I recommend disabling email confirmation so you can test quickly. Enable it before going to production.
5. Implement Login in Your Frontend
Here is the JavaScript client setup:
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
'https://yourproject.supabase.co',
'your-anon-key'
);
// Google OAuth login
async function signInWithGoogle() {
const { data, error } = await supabase.auth.signInWithOAuth({
provider: 'google',
options: {
redirectTo: 'https://yoursite.com/dashboard'
}
});
}
// GitHub OAuth login
async function signInWithGitHub() {
const { data, error } = await supabase.auth.signInWithOAuth({
provider: 'github'
});
}
// Email/password login
async function signInWithEmail(email, password) {
const { data, error } = await supabase.auth.signInWithPassword({
email,
password
});
}
// Sign out
async function signOut() {
await supabase.auth.signOut();
}
// Get current user
const { data: { user } } = await supabase.auth.getUser();
Row-Level Security Basics
Authentication tells you who the user is. Row-Level Security (RLS) controls what data they can access. Without RLS, any authenticated user can read any row in your database. With RLS, each user only sees their own data.
Enable RLS on any table that contains user-specific data:
-- Enable RLS on the table
ALTER TABLE user_projects ENABLE ROW LEVEL SECURITY;
-- Users can only read their own rows
CREATE POLICY "Users read own data"
ON user_projects
FOR SELECT
USING (auth.uid() = user_id);
-- Users can only insert rows with their own user_id
CREATE POLICY "Users insert own data"
ON user_projects
FOR INSERT
WITH CHECK (auth.uid() = user_id);
-- Users can only update their own rows
CREATE POLICY "Users update own data"
ON user_projects
FOR UPDATE
USING (auth.uid() = user_id);
The auth.uid() function returns the ID of the currently authenticated user. Every query is automatically filtered so users never see data that does not belong to them.
Integrating with Static Sites
Eleventy
Eleventy generates static HTML. For auth, add the Supabase JavaScript client to your pages and handle login/logout on the client side. Protected content can be hidden with JavaScript until the user authenticates, or you can use Netlify Functions as a middleware layer that checks the Supabase JWT before returning content.
Next.js
Next.js has first-class Supabase support via @supabase/ssr. Use middleware to protect routes:
// middleware.js
import { createServerClient } from '@supabase/ssr';
import { NextResponse } from 'next/server';
export async function middleware(req) {
const res = NextResponse.next();
const supabase = createServerClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
{ cookies: { get: (name) => req.cookies.get(name)?.value } }
);
const { data: { session } } = await supabase.auth.getSession();
if (!session && req.nextUrl.pathname.startsWith('/dashboard')) {
return NextResponse.redirect(new URL('/login', req.url));
}
return res;
}
Astro
Astro supports Supabase through its SSR mode. Use the Supabase client in your Astro components or API routes. The pattern is similar to Next.js — check the session in middleware and redirect unauthenticated users.
Cost Comparison
| Feature | Free Tier | Pro ($25/month) |
|---|---|---|
| MAU (auth) | 50,000 | 100,000 |
| Database | 500 MB | 8 GB |
| File storage | 1 GB | 100 GB |
| Edge functions | 500K invocations | 2M invocations |
| Bandwidth | 5 GB | 250 GB |
The free tier handles most side projects and early-stage products. You will not need Pro until you have real traction — and at that point, $25/month is trivial compared to the alternatives.
Real Use Cases from the Digital Empire Methodology
In The $97 Launch, the Digital Empire methodology emphasizes building assets you own. Supabase fits this model because your data lives in a Postgres database you control, not a proprietary platform.
Specific use cases where Supabase auth makes sense:
- Premium tool access. Free tools are public, premium tools require login
- Course platforms. Track lesson progress per user
- SaaS dashboards. Save reports, settings, and generated content
- Community features. User profiles, comments, and messaging
If your project does not fall into these categories, keep it simple. Build a static site, use the free tools approach, and add auth only when revenue or product requirements demand it.
Get Started
Create a free Supabase project at supabase.com, enable Google or GitHub OAuth in the provider settings, and add the JavaScript client to your frontend. You can have working authentication in under an hour. If your project does not need auth yet, bookmark this post and come back when it does.