|
| 1 | +--- |
| 2 | +title: Supabase Auth |
| 3 | +description: "Lock decryption to the authenticated user: use the Supabase Auth session JWT as a lock context so encrypted data only decrypts for the identity it belongs to." |
| 4 | +type: guide |
| 5 | +components: [encryption, auth] |
| 6 | +audience: [developer] |
| 7 | +verifiedAgainst: |
| 8 | + stack: "0.18.0" |
| 9 | +--- |
| 10 | + |
| 11 | +Row Level Security scopes *queries* to the logged-in user. Identity-aware encryption goes one layer deeper: values encrypted with a **lock context** can only be *decrypted* by presenting the same user's identity — enforced by [CTS](/security/cts), CipherStash's token service, not by your application code. Even your own backend, holding valid workspace credentials, cannot decrypt another user's locked values without that user's session. |
| 12 | + |
| 13 | +With Supabase Auth, the identity is the session JWT you already have. |
| 14 | + |
| 15 | +<Callout type="warn"> |
| 16 | +Lock contexts require a Business or Enterprise workspace plan. |
| 17 | +</Callout> |
| 18 | + |
| 19 | +## Register Supabase Auth with your workspace |
| 20 | + |
| 21 | +CTS needs to trust your Supabase project as an OIDC issuer — that's what lets it exchange a Supabase session JWT for a CipherStash identity token. The issuer for a Supabase project is: |
| 22 | + |
| 23 | +``` |
| 24 | +https://<project-ref>.supabase.co/auth/v1 |
| 25 | +``` |
| 26 | + |
| 27 | +The easiest path is the CipherStash dashboard's [Supabase integration](/integrations/supabase/dashboard-experience), which configures this during setup. Manual OIDC configuration is covered in the [auth reference](/reference/auth). |
| 28 | + |
| 29 | +## Lock queries to the session user |
| 30 | + |
| 31 | +Identify the user with their Supabase session token, then attach the lock context to any [`encryptedSupabase`](/reference/stack/supabase) query: |
| 32 | + |
| 33 | +```typescript |
| 34 | +import { LockContext } from "@cipherstash/stack/identity" |
| 35 | +import { db } from "./lib/db" |
| 36 | +import { patients } from "./lib/schema" |
| 37 | + |
| 38 | +// 1. The Supabase session you already have |
| 39 | +const { data: { session } } = await supabaseClient.auth.getSession() |
| 40 | + |
| 41 | +// 2. Identify: exchanges the Supabase JWT for a CTS identity token |
| 42 | +const lc = new LockContext() |
| 43 | +const identified = await lc.identify(session.access_token) |
| 44 | + |
| 45 | +if (identified.failure) { |
| 46 | + throw new Error(identified.failure.message) |
| 47 | +} |
| 48 | +const lockContext = identified.data |
| 49 | + |
| 50 | +// 3. Encrypt and decrypt under that identity |
| 51 | +await db.from("patients", patients) |
| 52 | + .insert({ email: "alice@example.com", name: "Alice Chen" }) |
| 53 | + .withLockContext(lockContext) |
| 54 | + |
| 55 | +const { data } = await db.from("patients", patients) |
| 56 | + .select("id, email, name") |
| 57 | + .eq("email", "alice@example.com") |
| 58 | + .withLockContext(lockContext) |
| 59 | +``` |
| 60 | + |
| 61 | +A value written with `.withLockContext()` can only be decrypted with a lock context for the **same identity**. Reading it without one — or as a different user — fails with an encryption error, regardless of what RLS allows. |
| 62 | + |
| 63 | +By default the identity is the JWT's `sub` claim, which for Supabase Auth is the user's UUID. You can widen or change that: |
| 64 | + |
| 65 | +```typescript |
| 66 | +const lc = new LockContext({ |
| 67 | + context: { identityClaim: ["sub"] }, // default; add "scopes" to bind permissions too |
| 68 | +}) |
| 69 | +``` |
| 70 | + |
| 71 | +## Where it fits |
| 72 | + |
| 73 | +- **Per-user data** (a user's own medical history, messages, documents): lock to `sub`. The row is useless to anyone but its owner — including operators with database access and your own service role. |
| 74 | +- **Shared/tenant data** (a support queue, org-wide records): don't lock it, or you'll be unable to decrypt it outside a user session. Plain encryption already protects it from the database side; RLS scopes who can query it. |
| 75 | +- **Server-side jobs** that must read locked data need the owning user's session — by design. If a background job must read a field, that field shouldn't be identity-locked. |
| 76 | + |
| 77 | +## Errors |
| 78 | + |
| 79 | +`identify()` returns a result, not a throw. The common failures: |
| 80 | + |
| 81 | +| Scenario | What you see | |
| 82 | +| --- | --- | |
| 83 | +| Expired or invalid Supabase JWT | `CtsTokenError` from `identify()` | |
| 84 | +| Issuer not registered with the workspace | `CtsTokenError` — register the OIDC issuer first | |
| 85 | +| Expired CTS token at query time | `LockContextError` — call `identify()` again | |
| 86 | +| Decrypting another user's locked value | `encryptionError` on the [query response](/reference/stack/supabase#responses-and-errors) | |
| 87 | + |
| 88 | +## Where to next |
| 89 | + |
| 90 | +<Cards> |
| 91 | + <Card title="Identity-aware encryption" href="/concepts/identity-aware-encryption"> |
| 92 | + The concept: lock contexts, CTS, and what identity binding proves. |
| 93 | + </Card> |
| 94 | + <Card title="encryptedSupabase reference" href="/reference/stack/supabase"> |
| 95 | + `.withLockContext()` and `.audit()` on the query builder. |
| 96 | + </Card> |
| 97 | + <Card title="Auth reference" href="/reference/auth"> |
| 98 | + OIDC configuration, access keys, and clients. |
| 99 | + </Card> |
| 100 | +</Cards> |
0 commit comments