Your app’s built-in backend (Cloud) includes authentication. Ask RShift Sites to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level security. For example, tell RShift Sites:
Add login to the app. Require login before accessing the CRM dashboard. Also, add a 'Sign in with Google' button so users can log in with their Google accounts.The Users view lets you manage the people who sign up and configure how they sign in. To open it, go to More → Cloud → Users.
Manage users
The Users view shows a Signups chart of new users over the last 7, 30, or 90 days, and a searchable list of every user in your app.
To add users yourself, click Add user:
- Send invitation: enter an email address and RShift Sites sends the person an invite email to join your app.
- Create new user: enter an email address and password to create the account directly. Users created this way are automatically confirmed.
Click a user to open their details, including their user ID, sign-up and last sign-in timestamps, and which login methods they use. The Raw JSON tab shows the full user record.
To remove a user, open their details and choose Delete user. The user loses access to your app, and the action cannot be undone.
Authentication settings
Click Auth settings in the Users view to configure how users sign in. The Sign in methods list shows each available method with an Enabled or Disabled badge.
You can change these settings directly, or ask RShift Sites in the project chat. When you enable a sign-in method, RShift Sites can also update your app’s login page, for example by adding the matching sign-in button.
Each sign-in method has its own page with full configuration details:
- Email: the default method, with settings for confirmation, password rules, one-time codes, and sending limits.
- Phone: SMS one-time codes through your own SMS provider (Twilio, Twilio Verify, TextLocal, Vonage, or MessageBird).
- Google: managed by RShift Sites with no setup, or your own Google Cloud OAuth credentials.
- Apple: managed by RShift Sites, or your own Apple Developer credentials.
- Microsoft: managed by RShift Sites with no setup, or your own Azure app registration.
- SAML SSO: sign-in through a SAML 2.0 identity provider such as Okta or Microsoft Entra ID.
Sign-up controls
Two settings on the main auth settings form control who can join your app:
- Disable sign-up: prevent new users from signing up. Existing users can still sign in, and you can still add users with Add user.
- Enable anonymous users: let visitors use your app without creating an account. Ask RShift Sites in the project chat to build flows that use anonymous sessions, such as guest checkouts.
Site URL and redirect URLs
Under Advanced in the auth settings:
- Site URL: the default URL users are redirected to after authentication when no redirect URL is specified.
- Redirect URLs: up to 50 URLs that auth providers are permitted to redirect to after authentication. Custom schemes (for example,
myapp://callback) are supported for mobile apps.
For apps on the built-in backend (Cloud), RShift Sites keeps both up to date for you. When you publish, RShift Sites sets the Site URL to your published lovable.app address, and when you connect a custom domain, RShift Sites adds it to the redirect URLs. A Site URL you set yourself stays unchanged. Apps that use your own Supabase project get no automatic updates, so add the addresses in that project’s auth settings.
If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason. Ask RShift Sites in the project chat to update them for your domain. If your app uses Google sign-in with your own Google OAuth credentials, the new domain also needs a redirect URI in Google Cloud Console. See Managing Google authentication.
Auth emails
Authentication flows send emails for signup confirmation, password resets, invites, magic links, email changes, and re-authentication. By default they come from a generic sender. To send them from your own domain with custom branding, set up Emails under More → Cloud. See Custom emails.
FAQ
Do I need my own Google, Apple, or Microsoft developer account for social sign-in?
No. Google, Apple, and Microsoft sign-in work in Managed by RShift Sites mode, where RShift Sites handles the OAuth configuration and security updates. You only need your own credentials if you want the consent screen to show your own branding and verified domain.
Can workspace admins control which sign-in methods projects use?
Yes. On Business and Enterprise workspaces, admins can block sign-in methods for every project in the workspace with the App login methods setting (Settings → Security → Privacy & security → App login methods). Blocked methods are locked: project owners can turn them off but cannot turn them back on.
Are my app’s users copied when I remix a project?
No. Remixing copies the structure of backend data, such as tables and auth configuration, but not the data itself. The remixed project starts with no users.
Why does sign-in fail on my published app but work in preview?
The published URL or custom domain is missing from your project’s redirect URLs. For apps on the built-in backend (Cloud), RShift Sites adds these addresses automatically when you publish and when you connect a custom domain. If sign-in still fails, or your app uses your own Supabase project, ask RShift Sites in the project chat to add your domain to the auth redirect URLs, or add it under Auth settings → Advanced → Redirect URLs. If your app uses Google sign-in with your own Google OAuth credentials, also add the new domain’s redirect URL in Google Cloud Console and select it in RShift Sites. See Managing Google authentication.