How to Add Authentication to Bolt
Bolt V2 introduced native authentication with email/password, email verification, and leaked password detection built into Bolt Cloud. For social login, MFA, or advanced auth, integrate Supabase Auth or Auth0. Both approaches work through simple prompts — Bolt generates the entire auth flow.
Why this matters
Bolt V2's native auth was a major upgrade. Before V2, every Bolt app needed an external auth provider. Native auth means you can have a working login system in minutes without configuring a third-party service. For more advanced needs, external providers are still fully supported.
What's at stake
Choosing the wrong auth approach means either unnecessary complexity (external provider when native auth would suffice) or missing features (native auth when you need social login). Understanding both options lets you make the right choice.
In detail.
Native Auth vs. External Providers
Bolt V2 Native Auth
Best for: Simple apps that only need email/password login.
- Email + password authentication out of the box
- Email verification to prevent fake signups
- Leaked password detection for enhanced security
- User management dashboard to see who signed up
- No external service to configure
Limitations: No social login, no MFA, no magic links, no SSO.
Supabase Auth (External)
Best for: Apps that need social login, magic links, or database-level security.
- All methods: email/password, magic links, social OAuth, phone auth
- Row Level Security (RLS) integration for data access control
- 50,000 free MAUs
- Requires connecting to a Supabase project
Auth0 (External)
Best for: Enterprise apps with complex auth requirements.
- Most auth methods including MFA, SSO, and passwordless
- Extensible with Rules, Hooks, and Actions
- 7,500 free MAUs
- More complex setup, higher cost at scale
Setting Up Authentication
For native auth, prompt Bolt:
"Add native authentication to my app with email/password login, signup page, and logout button. Protect the /dashboard and /settings routes."
For Supabase Auth, prompt Bolt:
"Connect to Supabase and add authentication with email/password and Google login. Create a user profile table with RLS policies. Protect all routes except / and /about."
Important: Test by Deploying
Authentication does not work in Bolt preview mode. WebContainers cannot handle server-side auth operations (cookies, sessions, email sending). You must deploy to Bolt Cloud, Netlify, or Vercel to test login.
Common Auth Mistakes in Bolt
- Testing in preview — auth will not work, leading you to think it is broken
- Not enabling email verification — allows anyone to create accounts with fake emails
- Missing route protection — authentication without route guards means logged-out users can still access protected pages
- Mixing auth systems — using both native auth and Supabase Auth creates conflicting sessions
Complete authentication audit for your Bolt application
- Auth configuration check for native and external providers
- Route protection verification across all app pages
- Email verification and security feature audit
Frequently asked questions.
Yes, but it requires migrating user accounts and session management. If you think you will need social login or advanced features in the future, start with Supabase Auth from the beginning to avoid migration.
Native auth is designed for Bolt Cloud. If deploying to Netlify, Vercel, or Cloudflare, use Supabase Auth or Auth0 instead, as native auth may not be compatible with external hosting.
Add a role field to your user data. Then prompt Bolt: "Add role-based access control. Only users with the admin role can access /admin routes. Show a 403 page for unauthorized users." The AI generates the role check middleware.
Bolt V2 native auth checks new passwords against databases of known leaked passwords (from data breaches). If a user tries to sign up with a password that has been exposed in a breach, the system rejects it and asks them to choose a different password.