How does user authentication work in Draftbit apps?

Authentication proves who the user is. Authorization decides what that user can see or change. The finished app needs both, and how Draftbit helps with the first part depends on the backend you pick.

With the Supabase backend, the agent can build sign up, sign in, password reset, and profile screens on Supabase Auth and handle the session in the app. The Supabase panel in the Builder exposes the project’s auth settings. You can enable email and phone sign in, configure multi-factor authentication, manage redirect URLs, and turn on social providers including Google, Apple, GitHub, Microsoft Entra ID, Discord, Facebook, GitLab, LinkedIn, Notion, Slack, Spotify, Twitch, X, Keycloak, WorkOS, and Zoom, as well as Solana and Ethereum wallet sign in. Each social provider needs a client ID and secret from your account with that provider.

If you use another provider, the REST catalog has entries for Clerk, Auth0, Stytch, Firebase Auth, Keycloak, and generic OpenID Connect endpoints, and the agent can add a provider’s client SDK to the project. Some of those APIs are meant to be called from a backend, as the Stytch entry notes, and a header that needs a private key cannot ship inside a mobile or web app.

Wherever the session comes from, your backend must check it on every protected operation and enforce roles or record ownership. With Supabase that means row-level security policies, because the publishable key in the app is public. Test with users who hold different permissions, and check callback URLs and deep links on both web and mobile when the app targets both.