Atomic Authentication
The auth keyword is enforced inside your slice, immediately before the function is invoked, not at the platform edge. The edge authenticates nothing on /api/*: it forwards X-API-Key and Authorization through untouched. A 401 or 403 on a function call came from your slice, and it read the same headers your own application code can read.
| Mode | Behaviour |
|---|---|
auth=none | Public. Anyone can call it, and it is the default when auth= is omitted. |
auth=apikey | Requires the configured key. Missing credential → 401. Wrong key → 403 (compared in constant time). No key ever set for this function → 503 api key not configured for this function. |
| anything else | 403 unknown auth type on every request. Nothing rejects the value at deploy time, so a typo, or auth=jwt, ships cleanly and then refuses every caller, valid credential or not. |
The key may arrive as X-API-Key or in Authorization: bare, Bearer <key> or ApiKey <key>. A browser app that cannot set a custom header can use Authorization instead.
Managing keys
drift atomic auth set my-function <api-key> # --method defaults to post
drift atomic auth set my-function <api-key> -m get
drift atomic auth list my-function # every method's fingerprint for this path
drift atomic auth revoke my-function -m getset and revoke address one method and path, and --method/-m defaults to post. Revoking without it leaves a key on the GET function at the same path in force. list takes no method: it reports every method configured for the path.
Setting a key is itself an auth-mode change.
auth=none; revoking returns it to open. Keys survive a slice restart.For richer rules (sessions, roles, expiry) mint and verify tokens inside the function with the SDK's drift.Deed.JWT primitive (a per-slice signing key you never have to manage). See the Authentication guide → for the full login → protected-route flow.