Does Supabase auth need cookie consent?

The short answer

Usually no. The Supabase session that keeps a user signed in is storage the user asked for by logging in, and that is the textbook case of the strictly necessary exemption in Article 5(3) of the ePrivacy Directive and § 25(2) of the German TDDDG. You do not need to ask for consent before writing it, and it does not belong in an Accept or Reject category of your banner.

There is one documented caveat. The EU's Article 29 Working Party, in its opinion on the consent exemption, said that login cookies which keep people signed in across browser sessions are not exempt on their own and suggested a checkbox instead. Supabase keeps sessions across browser restarts by default. If you want to follow that reading to the letter, add a "keep me signed in" choice. The code is below.

Everything else your app loads, analytics, pixels, embedded videos, still needs consent, login or not.

What Supabase Auth stores in the browser

What you find in DevTools depends on which client your app uses.

	supabase-js in the browser	@supabase/ssr
Typical in	Vite apps from Lovable and Bolt	Next.js apps, including most v0 projects
Where	Local storage	Cookies
Name	`sb-<project-ref>-auth-token`	`sb-<project-ref>-auth-token`, split into `.0`, `.1` when large
Contents	Access token, refresh token, user object	Same, readable by the server
Lifetime	Until sign-out or cleared storage	Default cookie max-age of 400 days, SameSite Lax
Written when	After sign-in	After sign-in, plus a code verifier during the PKCE login flow

The project reference is the first part of your Supabase URL. Lovable Cloud is built on Supabase and behaves like the left column.

The default storage key comes straight from supabase-js: sb-${hostname.split('.')[0]}-auth-token. The SSR package splits values over 3,180 characters into numbered chunk cookies and sets them with path /, SameSite Lax and a max-age of 400 days unless you configure otherwise. Supabase itself does not set advertising or analytics cookies in your visitors' browsers.

The rule: storage the user asked for

The cookie rule is not about cookies as such. Article 5(3) of the ePrivacy Directive covers storing or reading anything on a device, local storage included, as the EDPB confirmed in its 2023 guidelines. Consent is needed unless the storage is strictly necessary to provide a service the user explicitly requested.

Logging in is that request. Without a stored token, the user would have to type the password on every page. The Article 29 Working Party said exactly this in 2012: authentication cookies are an essential part of the service the user asked for and are exempt. It added a limit: the login must not become a reason to use the same storage for tracking or advertising without consent.

The catch: staying signed in after the browser closes

The same opinion draws a line that most apps never notice. In the Working Party's words, "persistent login cookies which store an authentication token across browser sessions are not exempted". The reason given is that users may not realise that closing the browser leaves them signed in. The opinion names the fix itself: the commonly seen checkbox is an appropriate way to get consent.

Supabase sessions persist by default, in local storage or in a 400-day cookie. So under the strictest reading, a silent "always stay signed in" is outside the exemption, and a "keep me signed in" checkbox brings it back inside.

How much weight to give this is a judgement call. The opinion is from 2012, regulators have not made persistent logins an enforcement focus, and most large sites keep you signed in without asking. But the fix costs ten minutes and removes the question, so for apps that handle anything sensitive we recommend it.

Adding a "keep me signed in" switch

With supabase-js in the browser, the session store is configurable. Session storage is cleared when the browser closes, local storage is not. A small storage adapter picks one based on the user's choice at the moment the session is saved:

src/lib/supabase.ts

import { createClient } from "@supabase/supabase-js";

const store = () =>
  localStorage.getItem("keep-signed-in") === "1" ? localStorage : sessionStorage;

const authStorage = {
  getItem: (key: string) => localStorage.getItem(key) ?? sessionStorage.getItem(key),
  setItem: (key: string, value: string) => store().setItem(key, value),
  removeItem: (key: string) => {
    localStorage.removeItem(key);
    sessionStorage.removeItem(key);
  },
};

export const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY,
  { auth: { storage: authStorage } }
);

On the sign-in form, add an unticked checkbox labelled "Keep me signed in on this device". Before you call signInWithPassword, set keep-signed-in to 1 if it is ticked and remove it if not. The flag itself is a setting the user chose, which is also strictly necessary.

In Lovable or Bolt you can ask for it in one prompt:

Prompt

Add an unticked "Keep me signed in on this device" checkbox to the login form.
Give the Supabase client a custom auth storage adapter: if the box was not
ticked, the session goes to window.sessionStorage, so the user is signed out when
the browser closes; if it was ticked, it goes to window.localStorage. Store the
choice under the key keep-signed-in before signing in.
Do not change anything else in the auth flow.

With @supabase/ssr, the session lives in cookies so the server can read it. There you control the lifetime through the cookie options of the client. A cookie without a max-age ends with the browser session.

Anonymous sign-ins

Supabase can also create anonymous users, for example to keep a basket or a draft before someone registers. That session is strictly necessary only while it serves something the visitor is actively doing. Creating an anonymous user on every first page view, just to recognise returning visitors, is tracking and needs consent. Sign visitors in anonymously when they take the first action that needs it, not on load.

What around auth does need consent

Analytics that identify users. Calling identify in PostHog, setting a GA4 user ID or sending the Supabase user ID to any analytics tool is not part of logging in.
Session replay on the login or account pages. Replay tools record what users type and see and need consent.
Social login buttons that load before the click. A button that loads a provider's script or iframe on page load contacts that provider before anyone chose it. A plain link that starts the OAuth flow on click does not.
reCAPTCHA or similar on the sign-up form. Whether these need consent is disputed and depends on the product. Check what the widget stores and sends.

A consent tool needs to block these until the visitor agrees, while leaving your own app code, including the Supabase client, running. See the Lovable cookie banner guide for the install.

What to write in your cookie list

Strictly necessary storage needs no consent, but it still needs to be disclosed. A line like this is enough:

Cookie list entry

Name:     sb-<project-ref>-auth-token (local storage or cookie)
Provider: this website, via Supabase
Purpose:  keeps you signed in after you log in
Category: strictly necessary
Duration: until you sign out; with "keep me signed in" unticked,
          until you close the browser

Supabase is also a processor for your user data. That part is about your contract and server region, not about the banner. Our German post Ist Supabase DSGVO-konform? covers the DPA, the regions and the transfer question, and the vibe coding GDPR checklist puts it in context.

FAQ

Does Supabase set cookies?

It depends on the client. supabase-js in a browser app stores the session in local storage under sb-<project-ref>-auth-token. The @supabase/ssr package used with Next.js and other server frameworks stores it in cookies with the same name. The cookie rules cover both.

Do I need consent for the Supabase login session?

No, in most cases. Keeping a user signed in after they logged in is strictly necessary for the service they requested. The only documented caveat concerns sessions that persist after the browser closes, which a "keep me signed in" checkbox solves.

Does a Supabase app with only a login need a cookie banner?

Usually not. If the app sets nothing except the auth session and functional preferences, there is nothing to ask consent for. You still need a privacy policy that lists the session. The moment you add analytics, pixels or embeds, you need a banner.

Should the auth token be in the Necessary category of my banner?

Yes. List it as strictly necessary, always on, and never block it. Blocking it would break sign-in for anyone who rejects cookies.

Are Supabase anonymous users strictly necessary?

Only while they serve something the visitor is doing, such as a basket. Creating one on every page view to recognise visitors is tracking and needs consent.

Is local storage safer than cookies for privacy law?

No. The rule covers any storage on the device. Local storage, session storage, IndexedDB and cookies are treated the same.

Sources

Written by the CookieCrumbs team, published 5 October 2026. Facts carry their dates; if one has moved on, tell us and we will correct it. This is not legal advice.

keep reading

See what your app stores before anyone logs in

The free scan reads your homepage and lists the trackers and third-party requests. No account, nothing stored.

Run a free scan Start free

Does Supabase auth need cookie consent? What it stores, and the one case that does