Supabase Auth in Next.js: 5 reasons users get logged out (and how to fix each)

Chris Boulionis — Thu, 29 Oct 2026 13:00:00 +0000

Auth bugs in Next.js with Supabase are rarely random. These are five causes that come up again and again.

1. The session is never refreshed

With @supabase/ssr the session cookie has to be refreshed on the server. Add middleware that calls supabase.auth.getUser() on each request and writes the updated cookies back to the response. Without it, users get logged out when the access token expires.

2. Trusting getSession() on the server

getSession() reads the cookie without verifying it. For anything that decides access, call getUser(), which asks the Auth server to validate the token.

3. Email links that expire immediately

Some email security scanners open the link before the user does and use up the one-time token. A common fix is to send the user to a page of your own that asks for a click, and only then call verifyOtp with the token hash.

4. OAuth only works on localhost

Check the Site URL and the Redirect URLs allow-list in the Supabase dashboard. If your production URL is not listed, sign-in falls back or fails after deploy.

5. Cached routes that read cookies

A route handler or page that reads auth cookies must be dynamic. If it gets cached, one user's state can show up for another or go stale.

More fixes

I wrote a guide that covers 26 common sign-in, session, email-link and OAuth bugs, each with the symptom, the real cause and a fix: https://getcodenest.com/products/fix-supabase-auth-next-js

3 Supabase RLS mistakes I keep seeing in real projects (and the fix for each)

Chris Boulionis — Wed, 28 Oct 2026 19:38:42 +0000

Row Level Security (RLS) is what stands between your users and each other's data in Supabase. These are three mistakes that show up again and again, with the fix for each.

1. RLS was never enabled

A table created with plain SQL has RLS switched off. Turn it on and add a policy:

alter table notes enable row level security;

create policy "owner can read" on notes
  for select using (auth.uid() = user_id);

2. Views skip RLS

A view runs with its owner's rights unless you create it with security_invoker = true (Postgres 15 and newer). Without it, a view can expose rows the current user should not see.

create view my_notes with (security_invoker = true) as
  select * from notes;

3. Trusting user_metadata in a policy

Users can edit their own user_metadata, so never use it to decide roles or permissions. Use app_metadata or a roles table that only your server can write to.

Want more patterns?

I put 31 copy-paste RLS patterns (ownership, teams, roles, sharing, invites, soft delete and testing) into one guide: https://getcodenest.com/products/supabase-rls-policy-cookbook

DEV Community: Chris Boulionis