---
title: "Auth pattern — Supabase Auth + RLS"
url: https://memory.wiki/mjpt9oz8
updated: 2026-05-16T14:17:17.590Z
hub: https://memory.wiki/hub/demo
bundle_count: 1
concept_count: 12
source: "demo-seed"
---
# Auth pattern — Supabase Auth + RLS

## Why Supabase Auth (not Clerk / NextAuth / Auth0)

- Same vendor as DB → JWT `sub` ↔ `auth.users.id` join is native (no email-lookup roundtrip)
- RLS lives next to the data — auth and authz are one table read away
- Magic link + Google + GitHub out of the box
- Free up to 50k MAU; matches our pre-revenue runway

## RLS policies (per role)

```sql
-- Tenant isolation: every table has user_id or organization_id
CREATE POLICY "own rows only" ON pages
  FOR SELECT USING (
    organization_id IN (
      SELECT organization_id FROM organization_members
      WHERE user_id = auth.uid()
    )
  );
```

Editors get write access. Viewers get read-only. Admin role bypasses
via service-role key on the server only — never in the browser.

## Session handling

- Server components → `createServerClient` with cookie store
- Client components → `@supabase/ssr` browser client
- API routes → verify the JWT with `verifyAuthToken` (see `lib/verify-auth.ts`)
- Anonymous edits → cookie-grouped `anonymous_id` until first sign-in

## Magic link tips

- Email template lives in Supabase dashboard, not in code (annoying for PRs)
- 24h link TTL; user pasting into wrong browser → friction. Use OTP fallback when telemetry shows >5% magic-link bounces.

## Open questions
- Org invitations: do we want self-serve invite links or just email invitations?
- Should we move to passkeys before launch or after?


---

## Concepts in this document
- **Supabase** _(entity)_
  Backend-as-a-service providing authentication, database, and row-level security without separate auth overhead.
- **Vendor consolidation** _(concept)_
  The operational principle of reducing authentication surfaces, SDKs, and control planes by keeping vector search within the existing Postgres infrastructure.
- **pgvector** _(entity)_
  PostgreSQL extension providing vector data type and HNSW indexing for efficient similarity search.
- **Authentication** _(tag)_
  Core security domain covering user identity, session management, and authorization patterns.
- **Database Design** _(tag)_
  Data modeling domain including schema design, migrations, and query optimization strategies.
- **API Design** _(tag)_
  RESTful interface design covering endpoints, error handling, and client-server communication.
- **Resend** _(entity)_
  Email service provider supporting both transactional and marketing communication channels.
- **Next.js App Router** _(entity)_
  Chosen routing framework leveraging RSC and Server Actions to match the project's data-heavy, read-mostly workload.
- **Vercel AI Gateway** _(entity)_
  AI provider abstraction layer offering failover and zero data retention for model access.
- **Next.js 15** _(entity)_
  Chosen frontend framework leveraging React Server Components and caching for performance.
- **Row-level security** _(concept)_
  Supabase RLS capability co-locating authentication and authorization with data, justifying single-vendor consolidation.
- **React Hook Form** _(entity)_
  Primary form handling library paired with Zod schemas for both client and server validation.

## Concept relations (within this doc's concepts)
- **Supabase** enables approach **Vendor consolidation**
- **Supabase** implements **Row-level security**
- **Supabase** hosts **pgvector**
- **Vercel AI Gateway** similar pattern **Resend**
- **Supabase** exemplifies approach **Vendor consolidation**
- **Row-level security** supports decision **Vendor consolidation**
- **Supabase** reduces complexity **Vendor consolidation**
- **Row-level security** supports **Vendor consolidation**
- **Supabase** integrates **pgvector**
- **Supabase** exemplifies strategy **Vendor consolidation**
- **Supabase** provides **Row-level security**
- **Vendor consolidation** guides **Supabase**
- **Vendor consolidation** guides **Vercel AI Gateway**

## Bundles containing this document
- [Cross-tool dev workflow](https://memory.wiki/b/p_mdtSk0)
  > Acme Pulse, a fictional landing-page builder. The seven docs in this bundle are the project's living context — README, auth pattern, DB schema, API conventions, UI patterns, decision log, open questio

_Hub canonical:_ https://memory.wiki/hub/demo
_Concept digest:_ https://memory.wiki/raw/hub/demo?digest=1&compact=1