Authenticate users

Supabase Auth verifies identity and issues a session. What the rest of the platform cares about is what that session carries: a JWT access token whose claims — the user ID above all — PostgreSQL policies can inspect later.

Sign a user up with the client library:

const { data, error } = await supabase.auth.signUp({
  email: '[email protected]',
  password: 'correct-horse-battery-staple',
})

New signups need email confirmation by default. When you test against the local CLI stack, no real email is sent — messages are captured by a local Mailpit inbox instead. Run supabase status to get its URL, open the confirmation email there, click the link. No rate limit, no real delivery.

Then sign in and look at the identity you received:

const { data, error } = await supabase.auth.signInWithPassword({
  email: '[email protected]',
  password: 'correct-horse-battery-staple',
})

console.log(data.user.id)
// 8f7a2c1e-4b9d-4e0f-a1c2-3d4e5f6a7b8c

Create two local users and record both IDs. Every authorization test in the lessons ahead compares what those two identities can and cannot do, so keep those identities separate.

Identity is not permission

Authentication answers “who is this”. It does not decide which note, file, or channel a user may access — that is authorization, and it lives in Row Level Security policies, not in Auth settings.

The production checklist

Configure allowed redirect URLs, token handling, and email delivery deliberately. Redirect URLs are an allowlist: a confirmation link pointing anywhere unlisted fails, which is a protection, not a bug.

Email is where hosted projects bite. Every project ships with a built-in mail service so auth flows work immediately, but it is rate limited to a handful of messages per hour and meant for trying the flow, not production delivery. Iterate on a signup form against a hosted project and you will hit:

Error: email rate limit exceeded

The frustrating part: signups appear to succeed, confirmation emails just stop arriving, and only the error response says why. The fix is custom SMTP under the Authentication settings — any transactional email provider works, with a sender address on a domain you verified there. After that, the rate limit is yours to raise in the dashboard.