How do I add login to Lovable?

The basic flow

Authentication is part of Lovable Cloud's built-in backend. You don't configure it manually — describe what you want and Lovable builds it.

1. If your project doesn't have a backend yet, ask Lovable to add one (or it will prompt you to when you ask for login).
2. Describe the sign-in method(s) you want:

Add login to my app with email/password and Google sign-in. Redirect users to /dashboard after login and protect that route for logged-in users only.

3. Lovable generates sign-up and login pages, sets up the auth tables, and wires up protected routes.
4. Review what "logged in" should unlock — which pages, which data — and make sure related tables have RLS policies matching that (see /questions/do-i-need-rls-on-my-lovable-app).

Supported sign-in methods

Lovable Cloud's authentication supports email, phone, Google, Apple, Microsoft and SAML SSO, depending on your plan and setup.

Things to specify up front

• Whether email confirmation is required before login.
• What happens to a logged-out user hitting a protected page (redirect to login vs show a preview).
• Whether you need user roles (admin/customer) — set these up in a separate user_roles table, never a column on the user's profile.

What usually goes wrong

• Asking for "login" with no detail, resulting in a generic setup that doesn't match your actual access rules — describe roles and protected pages explicitly.
• Forgetting that adding login doesn't automatically restrict database access — you still need RLS policies tied to the logged-in user.
• Testing only as one user, missing that another account can see data it shouldn't (see /questions/why-can-users-see-other-users-data).

See also /questions/how-do-i-add-user-registration, /questions/how-do-i-add-google-login, /questions/why-isn-t-my-login-working.

Adding login step by step

1. Enable the backend. Auth needs Lovable Cloud enabled so user records, sessions and email delivery exist.
2. Choose methods. Email/password is the default. Add Google sign-in if your audience expects it — configure the provider in the same session, or the first attempt fails with an unsupported-provider error.
3. Create a profiles table. A row per user for the fields you need to display (name, avatar, company), created automatically on signup.
4. Add the routes. /auth for sign-in and registration, plus a route for password reset. Send people to a public URL after OAuth, then redirect onward once the session exists.
5. Gate the private pages. Wrap protected routes in a guard that checks the session server-side and redirects signed-out visitors to /auth.
6. Protect the data too. Route guards only hide the UI. Row level security is what stops someone reading another user's rows directly.

A prompt that produces a working flow

Add email/password authentication with Lovable Cloud. Create a profiles row on signup with full_name. Add /auth with sign-in, register and forgot-password. Redirect signed-out visitors from /dashboard to /auth, and signed-in visitors from /auth to /dashboard. Enable row level security on profiles so a user can only read and update their own row.

Roles and admin access

Store roles in a separate user_roles table and check them with a security-definer function. Never keep a role flag on the profile a user can edit, and never decide admin status in the browser — anything in local storage can be edited by the visitor.

Testing before launch

• Register a brand-new address and confirm the verification email arrives
• Log in, refresh, and confirm the session survives a reload
• Request a password reset and complete it from the emailed link
• Sign out and try a protected URL directly — you should be redirected
• Sign in as a normal user and request an admin-only URL — it must be refused
• Query a second user's data from the browser console — row level security should block it

Common failures

• Redirect loops — the guard runs before the session hydrates; check the session server-side or wait for hydration.
• Verification emails missing — the sending domain is not verified, or the mail landed in spam.
• "Unsupported provider" — social login enabled in code but not configured in the backend.
• Works for you, not for others — you are testing with an admin account; retest with a fresh normal user.