Supabase access token: session JWT or personal access token, and what each can do

Which Supabase access token do you have?

Two credentials go by this name. Inside your app, the access token is the JWT (JSON Web Token: a signed string of JSON) that Supabase Auth issues to each user who signs in. The client library sends it with every request, and your row level security (RLS) policies read the user's ID from it through auth.uid(). Outside your app, the Supabase CLI, the Management API and the Supabase MCP server use a personal access token: a token starting with sbp_ that acts as you, on your Supabase account.

How to get the access token in Supabase

Most apps never handle it: the client library stores the session, refreshes it and attaches the access token to every query. You need the raw token only to call something that is not Supabase, such as your own API. In the browser, supabase.auth.getSession() returns it, with the refresh token and the expiry.

// Browser: send the signed-in user's token to your own API
const { data: { session } } = await supabase.auth.getSession()

if (session) {
  await fetch('/api/orders', {
    headers: { Authorization: `Bearer ${session.access_token}` },
  })
}

Without a client library, a request made as a user carries your publishable key (or the legacy anon key) in apikey and the user's access token in Authorization.

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/orders?select=id&limit=5" \
  -H "apikey: YOUR_PUBLISHABLE_KEY" \
  -H "Authorization: Bearer YOUR_TEST_USER_ACCESS_TOKEN"

On the server, verify the token before you trust it

Supabase's Next.js guide is blunt: never trust getSession() in server code. It reads the session out of the cookie without revalidating it, and anyone can forge a cookie. The three methods do not check the same thing.

// Server code: route handler, server action, proxy or middleware
const { data, error } = await supabase.auth.getClaims()
if (error || !data) {
  return new Response('Unauthorized', { status: 401 })
}
const userId = data.claims.sub // from a verified token

A backend that is not a Supabase client (an Express API, a Python worker) can verify the token with a JWT library and the public keys Supabase publishes at /auth/v1/.well-known/jwks.json:

import { createRemoteJWKSet, jwtVerify } from 'jose'

const JWKS = createRemoteJWKSet(
  new URL('https://YOUR_PROJECT_REF.supabase.co/auth/v1/.well-known/jwks.json')
)

export async function userIdFrom(req: Request) {
  const token = req.headers.get('authorization')?.replace(/^Bearer /, '')
  if (!token) return null
  // Throws if the signature, the issuer or the expiry is wrong
  const { payload } = await jwtVerify(token, JWKS, {
    issuer: 'https://YOUR_PROJECT_REF.supabase.co/auth/v1',
  })
  return payload.sub
}

Decoding is not verifying: jwt.decode() or jose's decodeJwt() return the claims of any token, even one written by hand. Keybrum tests this on your app's own API: it replays its test account's token with the signature removed. A route that still answers is not checking signatures.

Supabase access token expiry and refresh

Access tokens expire after 1 hour by default. You can change this under Auth settings > Sessions, but Supabase advises most apps to keep the default: more than an hour is discouraged for security reasons, and under 5 minutes causes clock skew errors and extra load on the Auth server.

The other half of the session is the refresh token: a random string with no expiry that works once, traded for a new pair before the access token runs out. A reuse within 10 seconds is tolerated, so server-side rendering can refresh on the server and then the client. Outside that window and one narrow retry case, a reuse ends the session: Supabase revokes all its refresh tokens, assuming one was copied.

So by default a session lasts until the user signs out or changes their password. On Pro plans and above, you can time-box sessions, add an inactivity timeout or keep one session per user; each limit is checked at the next refresh, so it takes effect up to one access token lifetime late.

Signing keys: the legacy JWT secret and asymmetric keys

Older projects sign access tokens with the legacy JWT secret, a shared HS256 secret that also signed the legacy anon and service_role keys. New projects use asymmetric JWT signing keys by default (Supabase recommends ES256): anyone can check a token with the published public keys, without being able to sign one.

To migrate, open the JWT Keys page in your project settings, click Migrate JWT secret, then Rotate keys: new tokens get the new key while issued ones stay valid. With a 1 hour expiry, Supabase says to wait at least 1 hour 15 minutes before revoking the legacy secret. First check that none of your code verifies tokens with the legacy secret directly, or it breaks.

Supabase personal access tokens: one token for your account

A personal access token authenticates you to the Management API and the tools built on it, the Supabase CLI and the MCP server. You create them on your account's Access Tokens page (supabase.com/dashboard/account/tokens). Tokens created there are scoped by default and start with sbp_fc: you pick the organizations, the projects, a permission level per resource (Database, Edge Functions, API Keys and so on) and an expiry up to one year out. A token never gets more than your own role allows, its scope cannot be changed later, and its value is shown once. The Read-only preset includes API key secrets, so Supabase suggests starting from No access.

Full-access tokens carry a Legacy badge, and supabase login in a browser creates one. They hold every permission on every organization and project you belong to, including ones you create or join later. Depending on its permissions, a token can read your projects' secret keys, change Auth settings, or pause and delete a project; a full-access token can do all of it, everywhere.

Using a personal access token in CI

1. 1

   One scoped token per job

   Scope it to the project the workflow deploys, with an expiry and only what its commands need: supabase link, for example, needs Project Settings, API Keys and API Key Secrets, all with Read access.

2. 2

   Store it as a CI secret

   Expose it to the job as SUPABASE_ACCESS_TOKEN, which the CLI reads before any saved token. Never write the value in the workflow file or print it.

3. 3

   Protect the database password too

   Commands that connect with your database password (SUPABASE_DB_PASSWORD) are not limited by the token's permissions, so a scoped token does not make a leaked password harmless.

Using it with the Supabase MCP server

The hosted MCP server at https://mcp.supabase.com/mcp signs you in through the browser by default. In CI it takes a personal token in the Authorization header and can only use the tools that token's permissions allow. Three URL parameters narrow what a coding agent can do: project_ref limits it to one project and turns off the account tools, read_only=true runs every query as a read-only Postgres user, and features enables only the tool groups you list. Supabase asks for all three, and a review of the prompt injection risk, before you connect a production project.

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true&features=database,docs",
      "headers": {
        "Authorization": "Bearer ${SUPABASE_ACCESS_TOKEN}"
      }
    }
  }
}

What to do if a Supabase access token leaks

A personal access token

1. 1

   Delete it now

   Delete it on your Access Tokens page. A token works until it expires or is deleted, so removing it from a repository, a chat or a CI log does nothing about copies already taken.

2. 2

   Replace it with a scoped token

   Create a new token for that job, scoped to one project with a short expiry, and update the CI secret or MCP config.

3. 3

   Read the audit log

   Your Account audit logs (supabase.com/dashboard/account/audit) list the actions taken with your account, with IP address, token type, action and target; on Team and Enterprise plans, the organization audit log covers every member. Look for actions and addresses that are not yours.

4. 4

   Assume what it could read was read

   If the token had full access or could read API key secrets, treat those projects' secret keys as leaked and follow the service role key guide. Revert any setting you did not change.

A user's session token

1. 1

   End the user's sessions

   signOut() uses the global scope by default and ends the user's sessions on every device. From your server, auth.admin.signOut() does the same with the leaked token and a client created with a secret key. Both revoke the refresh tokens.

2. 2

   Wait out the access token

   Supabase's reference is explicit: there is no way to revoke an access token until it expires, at most an hour with the default expiry. If that is too long for your data, lower the expiry.

3. 3

   Check what it did

   In the dashboard Logs, start the time range when the token leaked and add a User filter with the user's ID: it matches Auth events and API Gateway requests made with their token. How far back you can look depends on your plan.

4. 4

   Rotate the signing key for a wider leak

   If many tokens leaked, for example in logs that kept Authorization headers, rotate your signing keys and revoke the previous key. Revoking early signs active users out, and Supabase's edge caches the public key list for 10 minutes. Logs that kept cookies also kept refresh tokens: sign those users out too. If the legacy JWT secret itself leaked, that is the service role emergency.

// In the app, as the user: ends their sessions on every device
await supabase.auth.signOut({ scope: 'global' })

// On your server, with a client created with a secret key
await supabaseAdmin.auth.admin.signOut(leakedAccessToken, 'global')

The traps people miss with Supabase tokens

• Tokens that JavaScript can read. Without server-side rendering the session sits in local storage; with it, in cookies that Supabase says need not be HttpOnly, since the browser needs the refresh token. Either way, one cross-site scripting (XSS) bug reads both tokens, and refresh token reuse detection does not protect a session stolen from the device. Prevent the XSS: no user content rendered as raw HTML, and a Content Security Policy (see security headers).
• Authorization headers in logs. Request loggers, error trackers and a quick console.log(req.headers) keep bearer tokens, and Supabase names logged cookies, request bodies and URL parameters as ways refresh tokens leak. Redact authorization, cookie and apikey before anything is written.
• A token pasted where others can read it. An AI chat, a terminal screenshot, a debug log in a public GitHub issue, an MCP config committed with the token inline. Delete the token: editing the message is not enough. The leaked key guide has the order of operations.
• A personal token in the frontend. An sbp_ token in a JavaScript bundle gives a stranger your Supabase account, not one app. Keybrum looks for sbp_ tokens in your JavaScript and confirms one with a read-only call that lists projects.
• A session token used as an API key. A token copied from the developer tools into SUPABASE_KEY runs every request as that user until it expires, then the app breaks. The app needs the publishable key. See anon key vs publishable key.
• A valid token is not an ownership check. A verified token proves who the user is, not that the row is theirs. Policies must compare auth.uid() with an owner column, or any signed-in stranger reads everyone's rows. The RLS guide has the policies; the IDOR guide covers the same bug in your own API routes.

Check what tokens open on your live app

A stranger tests your app signed out, then signed in with a fresh account of their own, then with a token whose signature was removed. The free check starts where they do, with what anyone loading your app sees.