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 wires it up automatically when you describe what you want.

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 you get out of the box

When you ask for authentication in a new project, the agent sets up all of the following without you having to think about it:

• 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.
• A privacy guarantee at the database level: even if a bug let the app try to fetch the wrong user's data, the database itself refuses. See Database & Data for how this works.

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 complete flow.

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.

Also: if you offer Google or Facebook sign-in, Apple requires you to also offer Sign in with Apple. No exceptions. The agent adds Apple automatically when you add a third-party option.

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. In development, Supabase has a built-in email sender, but for production you'll want a real one - connect the Resend connector and the agent wires it in (see Sending Email). Verify your sending domain before launch or your messages land in spam.
• 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.