Loading article…
ServicesAuthenticate application users
DocsDocsLoading article…
Platform sessions authorize Studio and management operations. Application users belong to a branch's authentication realm. Tokens from another project or branch are rejected, even when the same email address exists in both.
Better Auth provides password hashing, session creation, verification, reset and OAuth mechanisms. QB Flex provides routing, realm isolation and reserved metadata tables.
Use SDK auth.signUp, auth.signIn and auth.signOut. Passwords require at least 12 characters. Auth requests are rate limited. Studio Authentication can also create users, edit profiles, assign application roles, block or delete users, and revoke sessions. Session revocation takes effect on later requests and realtime authorization checks.
Enable email verification in project settings and configure Resend or SMTP. Both adapters render React Email templates. Unverified users cannot sign in when verification is required. SDK sendVerification requests a new message; resetPassword requests a reset link, and updatePassword completes it with the one-use token.
Use an allowlisted callback URL. Local SMTP messages can appear in Mailpit. Provider failures are surfaced, not silently treated as delivered messages; provider acceptance is not proof of inbox delivery.
Application realms accept single-use magic links. Studio sign-in stays password, passkey and authenticator. A successful request does not reveal whether the address has an account, and it does not prove the message arrived. Links expire after five minutes.
await client.auth.signInWithMagicLink(email);Register an OAuth application with the selected provider. Configure its callback to the explicit branch auth endpoint, then store its client ID and secret in project settings. Add the browser application origin to the project allowlist.
Call auth.signInWithProvider and navigate to the returned authorization URL. After the callback, refresh the application session. These adapters require provider credentials and live callback verification before certification.
The API uses HttpOnly cookies where supported, while SDK bearer tokens remain in memory. The client refreshes session state on initialization. Do not put service keys or management tokens in browser applications. Cross-origin cookies may be restricted by browser privacy settings; use a same-site deployment or explicitly manage an approved session adapter.
Platform owners can enable Better Auth two-factor authentication. Production readiness requires administrator enrollment and MFA enforcement; local availability alone is not a production certification.
Browser clients expose auth.passkey enrollment/list/rename/remove/sign-in and auth.twoFactor enable/verify/disable. A password login requiring TOTP throws MFA_REQUIRED; complete the challenge and refresh the session before reading protected data. See passkeys and MFA for origin restrictions, SDK examples and recovery cautions. Native ceremonies are not implemented yet.