Supabase Auth

You are a Supabase backend developer. The user wants to set up Supabase authentication with social providers (Google, GitHub) and implement Row-Level Security (RLS) policies.

What to check first

• Run supabase status to verify your local Supabase instance is running
• Check your .env.local file contains SUPABASE_URL and SUPABASE_ANON_KEY
• Visit your Supabase dashboard → Authentication → Providers to see which providers are available

Steps

1. Enable social providers in the Supabase dashboard: go to Authentication → Providers, toggle Google and GitHub to "Enabled", and copy your OAuth credentials (Client ID and Secret) from Google Cloud Console and GitHub Settings
2. Create a users table with create table public.users (id uuid primary key references auth.users(id), email text, full_name text, created_at timestamp default now())
3. Enable RLS on the users table with alter table public.users enable row level security
4. Create a policy allowing users to read only their own row: create policy "Users can read own record" on public.users for select using (auth.uid() = id)
5. Create a policy allowing users to update only their own row: create policy "Users can update own record" on public.users for update using (auth.uid() = id) with check (auth.uid() = id)
6. Set up an auth trigger to create a user record automatically: in Database → Functions, create a function that runs on auth.users insert event and inserts a matching row into public.users
7. Test authentication by signing up with Google/GitHub and verifying a row appears in the users table
8. Verify RLS is working by querying from another user's session and confirming no data leaks

Code

-- Create users table
create table public.users (
  id uuid primary key references auth.users(id) on delete cascade,
  email text unique,
  full_name text,
  avatar_url text,
  created_at timestamp with time zone default now(),
  updated_at timestamp with time zone default now()
);

-- Enable RLS
alter table public.users enable row level security;

-- Policy: Users can read their own record
create policy "Users can read own record"
on public.users
for select
using (auth.uid() = id);

-- Policy: Users can update their own record
create policy "Users can update own record"
on public.users
for update
using (auth.uid() = id)
with check (auth.uid() = id);

-- Policy: Users can insert their own record (for signup)
create policy "Users can insert own record"
on public.users
for insert
with check (auth.uid() = id);

-- Function to handle new user creation
create or replace function public.handle_new_user()
returns trigger as $$
begin
  insert into public.users (id, email, full_name, avatar_url)
  values (
    new.id

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change