* feat: rename `allow` config option to `auth`
Aligns the SDK with Supabase CLI terminology — `auth: 'user'` reads
more naturally than `allow: 'user'`. The legacy `allow` key still
works (with a one-time `console.warn` per process) and will be
removed in a future major release; when both `auth` and `allow` are
provided, `auth` wins. Also exports new `AuthMode` / `AuthModeWithKey`
types alongside deprecated `Allow` / `AllowWithKey` aliases.
* feat!: rename auth mode values `'always'` → `'none'` and `'public'` → `'publishable'`
Aligns auth-mode values with Supabase CLI terminology. `'none'` reads more
directly than `'always'` for "no authentication required", and
`'publishable'` matches the `SUPABASE_PUBLISHABLE_KEY(S)` env var names.
`'secret'` and `'user'` are unchanged.
BREAKING CHANGE: the `'always'` and `'public'` mode values no longer work.
Replace `auth: 'always'` with `auth: 'none'`, `auth: 'public'` with
`auth: 'publishable'`, and `auth: 'public:<name>'` with
`auth: 'publishable:<name>'`. Runtime checks like
`ctx.authType === 'public'` must be updated to
`ctx.authType === 'publishable'`.
* feat!: rename `authType` field to `authMode` on `AuthResult` and `SupabaseContext`
Lines the field name up with its type — `authMode: AuthMode`. Reads more
naturally for both humans and AI agents working with the API.
BREAKING CHANGE: the `authType` field was renamed to `authMode` on
`AuthResult` (returned by `verifyAuth` / `verifyCredentials`) and on
`SupabaseContext` (passed to handlers). Find-and-replace
`ctx.authType` → `ctx.authMode` and `auth.authType` → `auth.authMode`
across your codebase.
* feat!: rename `claims` field to `jwtClaims` on `AuthResult` and `SupabaseContext`
Pairs naturally with `userClaims` and makes the snake_case JWT payload
distinct from the normalized identity view at a glance.
* refactor!: narrow `SupabaseContext.authKeyName` to `string | undefined`
The field used to be `string | null | undefined` (optional + explicitly
nullable), forcing consumers to handle two absence values. Collapse to a
single representation by dropping `null`: the property is simply omitted
for `'user'` and `'none'` modes, which don't match a named key.
`AuthResult.keyName` keeps its `string | null` shape — it's the
low-level type where the field is always present and `null` actively
signals "no named key for this mode."
* docs: add publishable-key example to README quick start
The auth-modes table documented the publishable mode but the quick start
only showed user, none, secret, dual, and server-to-server examples,
leaving readers without a concrete shape for publishable. Slot it
between the "no auth" and "secret" examples so the progression reads
no key → publishable (anon, key-gated) → secret (admin, key-gated).
The example clarifies the resulting client behavior — `supabase` is
anonymous, RLS still applies, and the publishable key is a client gate
rather than a user identity — which is the most common point of
confusion vs. `auth: 'secret'`.
* docs: update skill description
* docs: update ssr references accross docs and skill
* docs(adapters): add ecosystem index + community contribution guide
Adds src/adapters/README.md (index, maintenance model, contribution
checklist) and docs/adapters/h3.md. Moves docs/hono-adapter.md into
docs/adapters/. Slims the top-level README Framework Adapters section
to a canonical adapter table + brief examples. Updates CONTRIBUTING.md,
docs/getting-started.md, and the supabase-server skill to reference the
new paths.
* docs: sweep adapter and SSR docs to use renamed API
The cherry-picked docs commits were authored before the API renames in
this branch, so the new content arrived using `allow:`, `'always'`,
`'public'`, `claims`, `authType`, and `AllowWithKey`. Update the
newly-arrived files in line with the renamed API:
- docs/adapters/h3.md — `allow:` → `auth:`, `claims, authType` →
`jwtClaims, authMode` throughout
- docs/ssr-frameworks.md — composed Next.js adapter example now uses
`auth:` / `AuthModeWithKey` / `jwtClaims` / `authMode`
- src/adapters/README.md — adapter-test checklist mentions the four
current modes (`'user'`, `'publishable'`, `'secret'`, `'none'`)
- CONTRIBUTING.md — same wording fix in the adapter-PR section
- skills/supabase-server/SKILL.md — top-level skill description points
at `auth:` and the new mode values; legacy patterns folded into the
existing migration trigger
- src/adapters/hono/middleware.ts — inline comment example uses `auth:`
in both halves rather than mixing legacy and current option names
- README.md — collapsed Hono and H3 quick-start snippets use `auth:`
Migration prose (`README.md` callout, `docs/auth-modes.md` callout,
`docs/api-reference.md` deprecated-aliases section, `SKILL.md`
migration callouts) intentionally still references the old names; they
document the migration itself.
* docs: reframe Beta disclaimer for v1 launch + extract MIGRATION.md
The Beta callout ("APIs and documentation may change") directly
contradicts the SemVer commitment that v1 makes. For launch material
that pins to v1, the contradiction undermines the stability message
the version number is meant to carry.
Replace it with a v1.0 callout that leads with stability under SemVer
and follows with honest "active development continues" framing — new
adapters and ergonomic improvements in minor releases, breaking
changes only ever in a major bump.
Move the v0 → v1 rename map out of the README and into a dedicated
MIGRATION.md. The README quick start was buried under 20+ lines of
migration tables that only matter to upgraders, not first-time
readers — exactly the wrong tradeoff at launch. New short callout
points upgraders at MIGRATION.md.
SKILL.md gets the same Beta → v1.0 swap. The agent-operational
migration rules (lines 12-14: "always emit `auth:` in new code", "the
new mode values are `'none'` / `'publishable'`") are kept inline —
they're rules the agent applies every time it writes code, not
user-facing migration steps, so they don't belong in MIGRATION.md.
* docs: reframe v1.0 callout as "Public Beta" to match Supabase house style
The previous "Stable under SemVer; active development continues" framing
mixed two distinct axes — code stability (SemVer) and product
lifecycle stage (Public Beta / GA) — into the SemVer line. Several
Supabase docs run those independently: a release can be v1+ in SemVer
terms and still labeled Public Beta in lifecycle terms.
Lead with both signals in the headline: "v1.0 — Public Beta." Keep the
SemVer commitment ("breaking changes only ship as a major bump") so
launch copy can pin to v1, and pair it with the Public Beta lifecycle
stage so readers know the product line is still early. Same swap in
the SKILL.md mirror.
7.0 KiB
Core Primitives
When to use primitives
Use withSupabase or createSupabaseContext for standard use cases. Drop down to core primitives when you need:
- Multiple routes with different auth in a single handler
- Custom response headers or error formats
- Integration with frameworks other than the ones provided
- Pre-extracted credentials (e.g., from cookies, custom headers)
- Just auth verification without client creation
All primitives are available from @supabase/server/core.
The composition pipeline
The primitives compose into a pipeline. Each step is independent — use only what you need:
resolveEnv() → SupabaseEnv
extractCredentials(request) → Credentials { token, apikey }
verifyCredentials(credentials, opts) → AuthResult { authMode, token, userClaims, jwtClaims, keyName }
createContextClient(options) → SupabaseClient (RLS-scoped)
createAdminClient(options) → SupabaseClient (bypasses RLS)
Or use the convenience function that combines extraction and verification:
verifyAuth(request, opts) → AuthResult (extractCredentials + verifyCredentials in one call)
resolveEnv
Resolves Supabase environment configuration from runtime variables. The only hard requirement is SUPABASE_URL.
import { resolveEnv } from '@supabase/server/core'
const { data: env, error } = resolveEnv()
if (error) {
// error is an EnvError — e.g., SUPABASE_URL not set
console.error(error.message)
}
With partial overrides:
const { data: envOverridden } = resolveEnv({
url: 'http://localhost:54321',
})
Returns { data: SupabaseEnv, error: null } on success, { data: null, error: EnvError } on failure.
extractCredentials
Pure extraction — reads headers, performs no validation.
import { extractCredentials } from '@supabase/server/core'
const creds = extractCredentials(request)
// creds.token → string | null (from Authorization: Bearer <token>)
// creds.apikey → string | null (from apikey header)
This is synchronous and never fails. Fields are null when the corresponding header is absent.
verifyCredentials
Verifies pre-extracted credentials against allowed auth modes. Use this when credentials come from a non-standard source (cookies, custom headers, etc.).
import { verifyCredentials } from '@supabase/server/core'
const credentials = { token: cookieToken, apikey: null }
const { data: auth, error } = await verifyCredentials(credentials, {
auth: 'user',
})
if (error) {
return Response.json({ message: error.message }, { status: error.status })
}
console.log(auth!.authMode) // 'user'
console.log(auth!.userClaims) // { id: '...', email: '...', role: 'authenticated' }
Supports all auth mode syntax — single mode, arrays, and named keys:
// Multiple modes
const { data: auth } = await verifyCredentials(creds, {
auth: ['user', 'publishable'],
})
// Named key
const { data: auth } = await verifyCredentials(creds, {
auth: 'publishable:web',
})
// Wildcard
const { data: auth } = await verifyCredentials(creds, {
auth: 'secret:*',
})
verifyAuth
Convenience function that combines extractCredentials and verifyCredentials in a single call. Use this when working with a standard Request:
import { verifyAuth } from '@supabase/server/core'
const { data: auth, error } = await verifyAuth(request, {
auth: 'user',
})
if (error) {
return Response.json({ message: error.message }, { status: error.status })
}
console.log(auth.userClaims!.id) // "d0f1a2b3-..."
console.log(auth.token) // the verified JWT string
createContextClient
Creates a Supabase client scoped to the caller's identity. RLS policies apply.
import { verifyAuth, createContextClient } from '@supabase/server/core'
// With a user's token (from verifyAuth)
const { data: auth } = await verifyAuth(request, { auth: 'user' })
const supabase = createContextClient({
auth: { token: auth!.token, keyName: auth!.keyName },
})
// Anonymous (no token) — RLS as anon role
const anonClient = createContextClient()
The client is configured with:
- The publishable key as the
apikeyheader - The user's JWT as the
Authorization: Bearerheader (if token is provided) - Server-safe auth settings:
persistSession: false,autoRefreshToken: false,detectSessionInUrl: false
This function throws EnvError if SUPABASE_URL or the required publishable key is missing. Wrap in try/catch when using directly.
createAdminClient
Creates a Supabase client that bypasses Row-Level Security using a secret key.
import { createAdminClient } from '@supabase/server/core'
const supabaseAdmin = createAdminClient()
// With a specific named key
const supabaseAdminInternal = createAdminClient({
auth: { keyName: 'internal' },
})
Same server-safe settings as createContextClient. Throws EnvError if the secret key is missing.
Full example: custom multi-route handler
Using primitives to build a handler with different auth per route, without a framework:
import {
verifyAuth,
createContextClient,
createAdminClient,
} from '@supabase/server/core'
export default {
fetch: async (req: Request) => {
const url = new URL(req.url)
// Public route — no auth needed
if (url.pathname === '/health') {
return Response.json({ status: 'ok' })
}
// User-authenticated route
if (url.pathname === '/todos') {
const { data: auth, error } = await verifyAuth(req, { auth: 'user' })
if (error) {
return Response.json(
{ message: error.message },
{ status: error.status },
)
}
const supabase = createContextClient({
auth: { token: auth!.token, keyName: auth!.keyName },
})
const { data } = await supabase.from('todos').select()
return Response.json(data)
}
// Admin route — secret key only
if (url.pathname === '/admin/users') {
const { data: auth, error } = await verifyAuth(req, {
auth: 'secret',
})
if (error) {
return Response.json(
{ message: error.message },
{ status: error.status },
)
}
const supabaseAdmin = createAdminClient({
auth: { keyName: auth!.keyName },
})
const { data } = await supabaseAdmin.from('profiles').select()
return Response.json(data)
}
return new Response('Not found', { status: 404 })
},
}
Cookie-based environments (with @supabase/ssr)
In Next.js, SvelteKit, Remix, and other cookie-based frameworks, the JWT lives in session cookies rather than the Authorization header. The recommended pattern is to compose with @supabase/ssr: let @supabase/ssr own the cookie session lifecycle and refresh-token rotation (via middleware), then hand its fresh access token to verifyCredentials and build typed clients with createContextClient + createAdminClient.
For the full pattern — middleware setup, the composed adapter, JWKS caching, and other-framework adapting tips — see ssr-frameworks.md.