Auth + Basket rules
Using auth.user.id in rules: per-user data with no backend.
One token, both services
The access token Flares Auth issues is exactly the token Basket DB verifies. There is no
exchange step and no adapter: sign a user in, send their token with Basket requests, and every
rule that mentions auth.user.* starts meaning something.
User signs in ──▶ Flares Auth issues an access token
│
▼ X-Basket-User-Token
Basket DB verifies it (project-bound signature)
│
▼
Rules see auth.user.id / .email / .claims
In practice
// 1. Sign in
const session = await fetch(`${AUTH}/signin`, {
method: 'POST', headers: pub, body: JSON.stringify({ email, password })
}).then(r => r.json());
// 2. Use the token with Basket
await fetch(`${BASE}/collections/messages/records`, {
method: 'POST',
headers: { ...pub, 'X-Basket-User-Token': session.access_token },
body: JSON.stringify({ data: { body: 'Hello', sender_id: session.user.id } })
});
With the rule messages.create → owner (sender_id), a user can only ever create messages as themselves. Forging sender_id is refused server-side.
What a rule receives
auth.user.id usr_01J… the pool user's id
auth.user.email aisha@example.com
auth.user.claims { email_verified: true, iss: "flares-auth", … }
Degrading, not exploding
An expired or invalid token makes the caller anonymous rather than rejected: the rules then decide. A session that lapses mid-use reads as "signed out" — the natural thing — instead of a hard error your UI has to special-case.
Custom tokens for other identity systems
If your users already exist somewhere else, a backend holding the secret key can mint the same kind of token directly:
POST /v1/projects/{project}/auth/tokens {user_id, claims?, expires_in?}
Flares Auth is the canonical issuer for applications that use it; this endpoint remains for applications that authenticate elsewhere and only need Basket to know who the caller is. Security rules →