Authentication
"Authentication" is the technical word for the part of your app that figures out who you are. Sign-up, log-in, log-out, password reset, "Sign in with Google". Anywhere your app needs to know which user is on the other end of a tap.
Almost every app needs it. Appsanic can generate the client flow when you describe what you want, while provider settings, redirect URLs, email delivery, OAuth credentials, and database policies remain explicit setup steps.
Heads-up: sign-in is powered by Supabase. If you haven't connected Supabase yet, do that first. Every sign-in feature on this page assumes it's wired up.
What the agent can generate
When you ask for authentication, the agent can generate:
- Email + password sign-up and log-in.
- Email verification: users confirm their email by clicking a link.
- Password reset: secure, time-limited reset emails.
- Log out that properly clears everything.
- Protected screens: screens that require a log-in. Unauthenticated users get bounced to the log-in page.
- Review-first RLS policies for user data. Apply and test those policies in Supabase before treating them as a database-level guarantee. See Database & Data.
All of the sign-in screens (log in, create account, forgot password, verify email) are real screens in your project. You can edit them. Change the colours, the copy, the layout. Ask the agent.
The three prompts that cover almost everything
1. Add authentication to a new project
When you describe your app, include something like:
"Require an account to use the app. Users sign up with email and password, verify their email via a link, and can log out from settings. Anyone not signed in should land on the log-in screen."
That gives you the client flow plus a checklist for Supabase email, redirect, and policy settings you must review.
2. Add "Sign in with Google" or "Sign in with Apple"
"Add 'Sign in with Apple' and 'Sign in with Google' as options on the log-in screen, alongside email and password."
A note on wording: Apple and Google both require the exact phrases "Sign in with Apple" and "Sign in with Google" for those buttons. Don't shorten them. The agent uses the right phrasing by default.
If you offer a third-party sign-in on iOS, review Apple's current App Review requirements for an equivalent privacy-preserving login option. The agent can flag and generate Sign in with Apple, but you still configure its Apple/Supabase credentials and redirect URLs.
3. Use magic links instead of passwords
Passwordless sign-in is increasingly popular and friendly to non-technical users:
"Replace email + password with magic-link sign-in only. The user types their email, we send a link, tapping it logs them in."
The agent swaps the flow and updates the onboarding copy.
Common follow-up tweaks
Stricter password requirements
"Require passwords to be at least 12 characters, with at least one number and one letter."
A "Remember me" toggle
"Add a 'Remember me' checkbox on the log-in screen. When checked, the session lasts 30 days; when unchecked, 24 hours."
Let users delete their account
"Let users delete their account from Settings. Ask them to type their email to confirm, log them out, and remove all their data."
The agent wires up the screen; the actual deletion happens server-side. If you want a confirmation email step (highly recommended for safety), ask for it explicitly.
Two-factor (MFA)
For apps where users will have something to lose if their account gets compromised (payments, sensitive data):
"Add optional two-factor authentication. Users can turn it on from Settings → Security: they scan a QR code with an authenticator app (Google Authenticator, 1Password) and enter a 6-digit code on sign-in afterwards."
What's happening underneath
The default sign-in system uses Supabase Auth. A few things worth knowing:
- Your password is never seen by Appsanic. Supabase securely scrambles ("hashes") it before storing.
- A user's session is kept securely on the phone. Not as something easily extracted.
- Email verification links and password reset links are single-use and time-limited (the reset link expires after 60 minutes by default).
- Your Supabase project lives in your Supabase account, not ours. You can sign in directly any time. See Database & Data.
If a user signs up, verifies their email, and you check the Supabase dashboard, you'll see them sitting there in the Authentication section. That's the real source of truth.
Things to verify before you launch
- Email actually arrives. Supabase has a built-in development sender with limits. For production, connect Resend for bounded domain setup, then explicitly configure Supabase's custom SMTP/provider settings, publish DNS records, and provision the sending credential. The connector does not change auth email delivery automatically. See Sending Email.
- Log out really clears state. After signing out, the user should not see any cached data from the previous account. The agent handles this by default; double-check for your specific flows.
- Test the password reset email end-to-end. The most common silent failure: emails ending up in spam because the domain isn't verified.
Under the hood (for engineers)
Default stack: Supabase Auth, JWT-based sessions stored in SecureStore on mobile and HTTP-only cookies on the web. Auth state in a Zustand store; root layout (app/_layout.tsx) reads it to fork between (auth) and (app) route groups.
RLS policies on every user-scoped table use auth.uid(). Password reset and email verification tokens are single-use and TTL-limited. MFA uses TOTP via supabase.auth.mfa.enroll().
Next
With accounts in place, start storing user data. Read Database & Data.