Auth on SupaHost
How Supabase Auth works on SupaHost: what each project gets, which sign-in methods are available, where the settings live in the dashboard, and what isn't configurable.
Every SupaHost project runs its own copy of Supabase Auth (the open-source GoTrue server, currently v2.197.0). It stores users in your project's database, issues JWTs that Row Level Security understands, and sends sign-up, magic link and password reset emails for you. Because it's the same server Supabase uses, supabase-js and the other client libraries work without changes.
Auth for a project lives at:
https://app-one.acme.supahost.space/auth/v1
You rarely call that URL yourself. The client library does it when you pass your project URL and anon key to createClient.
What you can use
| Feature | On SupaHost |
|---|---|
| Email and password | Yes. See Email and password sign-in |
| Magic links and email OTP codes | Yes. See Magic links and email OTP |
| OAuth (social login) | Yes, 19 providers. See Social login |
| SAML 2.0 single sign-on | Yes, for business customers' identity providers (Okta, Entra ID and others). See SAML 2.0 single sign-on |
| Anonymous sign-ins | Yes, off by default. See Anonymous sign-ins |
| Multi-factor authentication | TOTP (authenticator apps) through the supabase.auth.mfa API. See MFA |
| Identity linking | Automatic, plus manual linking when enabled. See Linking identities |
| Admin API | Yes, with the service_role key on a server. See Managing users |
| Server-side auth (cookies, SSR) | Yes, with @supabase/ssr. See Server-side auth |
| Phone and SMS sign-in | Not available |
| Phone MFA | Not available |
| Custom SMTP | Not available. Emails are sent by SupaHost |
| Auth hooks (custom access token, send email and so on) | Not configurable. There's no setting for them |
| CAPTCHA | Not configurable. See Rate limits and abuse protection |
Where the settings are
Open Dashboard → your project → Auth tab. It has four cards:
- Auth: "App name" (the sender name and header of your Auth emails, up to 60 characters), "Site URL" and "Redirect URLs". Saved with Save Auth settings. See Site URL and redirect URLs.
- Auth emails: the five email templates (Confirm sign-up, Magic link, Reset password, Invite, Change email). See Auth emails and templates.
- Sign-in & security: toggles for "Email sign-in", "Disable new sign-ups", "Skip email confirmation", "Anonymous sign-ins" and "Manual identity linking", plus "Minimum password length" (6 to 72) and "Access token lifetime" (300 to 604800 seconds). Saved with Save sign-in settings.
- OAuth providers: one row per provider with its Client ID, Client secret and, for a few providers, a URL field. The callback URL to give each provider is shown at the top of the card.
Only the instance owner can change these settings. Invited team members see the cards read-only. Saved changes reach the project within about a minute, because the platform applies them on its next pass over your instance.
A first sign-up
With email sign-in on (the default), this is enough to create a user and send a confirmation email:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.SUPABASE_URL!, // https://app-one.acme.supahost.space
process.env.SUPABASE_ANON_KEY!
)
const { data, error } = await supabase.auth.signUp({
email: '[email protected]',
password: 'a-long-passphrase',
options: { emailRedirectTo: 'https://recipes.example.com/welcome' },
})
The user gets an email from [email protected], shown with your App name as the sender. After they confirm, they can sign in and every request they make carries a JWT with their user id, which your policies read with auth.uid():
create policy "Cooks read their own recipes"
on public.recipes for select
to authenticated
using ((select auth.uid()) = user_id);
Things to know before you build
- Set the Site URL early. If it's empty, Auth falls back to
http://localhost:3000, so confirmation links in production emails would point at localhost. - Emails are rate limited. Auth sends at most 30 emails in its rate-limit window (
GOTRUE_RATE_LIMIT_EMAIL_SENT=30) and the number can't be raised. Plan bulk invites accordingly. - Keys are the legacy JWT kind. Projects have an
anonkey and aservice_rolekey, both HS256 JWTs. There are nosb_publishable_orsb_secret_keys, and the keys and JWT secret can't be rotated. See API keys. - Custom domains change the callback host. Once a custom domain is active, Auth uses it for links and OAuth callbacks, so OAuth apps need the new callback URL. See Custom domains.
- Branches start with default Auth settings. A branch copies users if you copy data, but not Auth settings or OAuth providers. Set them on the branch if you need them there. See Branching.
- Imports bring users, not settings. Importing from Supabase Cloud copies users with their passwords and identities, but not the site URL, redirect URLs or provider keys. Users sign in again once, because the JWT secret is different.
Where to go next
- Users and the auth schema explains where user data lives and how to attach your own profile table.
- Server-side auth and SSR and Auth in Next.js cover cookie-based sessions.
- Sessions, JWTs and refresh tokens explains what's in the token and how long it lasts.
- For every method and option in the client library, see the supabase-js Auth reference.