Know who is calling, everywhere.
Magic link, Google, Apple, and passwords run on a hosted identity plane; your runtime verifies the resulting session itself — offline, per request — before your function sees the user.
Real identity, locally too
A built-in dev account signs you in with no provider set up and no email sent.
Verification costs nothing
Sessions are signed tokens the runtime checks itself, with no round trip per request.
Access is reviewable
Auth mode, capabilities, and which functions may read a secret are all declared in files.
Auth, running
local developmentSign-in runs centrally, verification runs in your runtime
OAuth callbacks need a stable hosted URL and email needs a sender, so sign-in belongs on a central identity plane. What your project holds is the other half: sessions are signed tokens the runtime verifies itself, offline, on every request.
- Magic link, Google, Apple, and email/password out of the box
- Verification adds no network round trip to a request
- Refresh and revocation stay central, so access can be withdrawn
[auth]
redirect_urls = ["https://myapp.example.com/welcome"]
[[auth.providers]]
name = "apple"
client_id = "com.example.app.signin"
secret_name = "APPLE_SIGNIN_KEY"Three layers of access, all in files
A function's auth mode decides who gets in, its capabilities decide what the code can reach, and the query it writes decides which rows this caller may touch. Secrets follow the same discipline: the name is committed, the value never is.
- public, optional, or required — checked before your code runs
- A secret can name exactly which functions may read it
- Row-level rules are ordinary SQL, written where the query is
[[secrets]]
name = "STRIPE_SECRET_KEY"
functions = ["checkout"] # and nothing else
[[functions]]
name = "checkout"
auth = "required"
capabilities = ["db", "auth", "secrets"]Built for real applications
What teams build with Auth.
Passwordless from day one
Magic link is on by default, so a new project has real sign-in before any provider is registered — and it doubles as the password reset flow later.
Sign in with Apple on iOS
Native apps present an identity token directly, so the user never leaves the app, and the same session verifies inside your functions.
Shared workspaces
Access that follows membership rather than ownership is a join in the function's own query — no separate policy engine to keep in step.
Identity proves who someone is; your functions decide what that person may do.
Why Snoozestack →