Skip to content

Auth

Tested with: Databasezy API v1 · supabase-js 2 · PostgreSQL 17

Auth gives your application’s users accounts and sessions. Users live in the auth schema of the project’s primary database, so your row-level security policies can use auth.uid() and your backups include them. It is a product for your users; your own login to Databasezy is unrelated.

  1. Make sure the project has a primary Postgres database (Project settings → Primary database).

  2. Open Platform → Auth, turn it on and set the site URL (where links in emails land) and the allowed redirect URLs. The same settings are available through the API:

    shell
    zb api PUT /v1/orgs/{org}/projects/<project-id>/auth/config -d '{
    "enabled": true,
    "site_url": "https://app.example.com",
    "redirect_urls": ["https://app.example.com/auth/callback"],
    "password": { "min_length": 10, "leaked_password_protection": true },
    "captcha": { "provider": "turnstile", "secret": "<turnstile-secret>" }
    }'
  3. Sign a user up from your app with a publishable key:

    Terminal window
    curl -X POST "https://<ref>.us-east.databasezy.com:8443/auth/v1/signup" \
    -H "apikey: <publishable-key>" \
    -H "Authorization: Bearer <publishable-key>" \
    -H "Content-Type: application/json" \
    -d '{"email":"[email protected]","password":"a-long-password"}'
  4. Protect rows with a policy that uses the signed-in user:

    SQL
    alter table todos enable row level security;
    create policy "own todos" on todos
    for all to authenticated
    using (owner_id = auth.uid())
    with check (owner_id = auth.uid());
MethodClient callNotes
Email and passwordsignUp, signInWithPasswordConfirmation email unless you turn on auto-confirm
Magic linksignInWithOtp({ email })One-time link to the site URL or an allowed redirect URL
Email one-time codesignInWithOtp, then verifyOtp({ type: "email" })Code length and expiry in the settings
Password resetresetPasswordForEmail, then updateUser({ password })

Social providers, MFA, SAML single sign-on, anonymous sign-in and phone codes follow; the status box above lists what is live.

  • Access tokens are ES256 JWTs signed with the project’s own key (kid in the header), verifiable with the JWKS. The role claim is authenticated and sub is the user id.
  • Refresh tokens rotate on every use. Presenting a refresh token that was already used revokes the whole session family, which stops a stolen token from being replayed.
  • Token lifetime (jwt_expiry) and the reuse grace interval are project settings.
  • CAPTCHA: hCaptcha or Cloudflare Turnstile on sign-up, sign-in, magic links and password reset. Pass the widget’s token as options.captchaToken in supabase-js. The provider secret is write-only and stored in the project’s region.
  • Passwords: minimum length, required character classes and a check against known leaked passwords (a k-anonymity range query: the password itself never leaves the region).
  • Rate limits: per-endpoint limits for sign-in, sign-up, email sends and token refresh. Repeated failures are recorded as security events in your audit log.

Auth emails (confirmation, magic link, one-time code, password reset) go through our sender with a daily cap per project, or through your SMTP server when you add one in the settings (no cap). Templates are editable per project.

Platform usage prices and the allowance each plan includes per month
Meter Price FreeSoloTeamEnterprise
Auth monthly active users $0.003 per MAU 10,000 MAU50,000 MAU100,000 MAUContract
Platform limits on each plan
Limit FreeSoloTeamEnterprise
Auth emails per day through our sender 505005,000Unlimited

A monthly active user is a distinct user who signs in or refreshes a session in the calendar month, per project.