This page documents Microsoft authentication for your app’s users. It is available only for apps using the built-in backend (Cloud). It is not about signing in to Lovable itself with a Microsoft account (see SAML SSO for using Microsoft Entra ID as your workspace’s identity provider), and not about the Microsoft 365 connector your app can use for files and email. For an overview of all sign-in methods, see Users and authentication.
- Managed by Lovable: Lovable manages the OAuth configuration and security updates. This is the default and requires no Azure account.
- Your own credentials: you connect an app registration from your own Azure account and manage its credentials yourself.
- The user picks Microsoft sign-in in your app
- Microsoft asks them to sign in and confirm
- Microsoft redirects the user back to your app, signed in
Why use Microsoft sign-in
Microsoft sign-in reduces signup friction, and it fits audiences that already live in Microsoft accounts, especially at work:- Your users work at organizations that run on Microsoft 365, so they already have a Microsoft account
- Faster onboarding without password creation, and less password reset overhead
- With your own credentials, sign-in can be limited to your organization’s own accounts
- It combines with other methods: users pick Microsoft, Google, Apple, or email on the same login page
Common use cases
Microsoft sign-in is commonly used for:- B2B tools where customers sign in with their work Microsoft accounts
- Internal tools restricted to your organization’s Microsoft Entra directory
- Consumer apps that offer Microsoft alongside Google and Apple sign-in
Microsoft authentication setup options
The end-user experience is identical in both modes; the difference is who manages the OAuth credentials and what you can control.- Managed by Lovable (default)
- Your own credentials
Lovable manages the OAuth configuration and related security updates. No Azure account is required.Use this option if you:Lovable enables the provider in Cloud tab → Users → Auth settings → Microsoft and adds the sign-in button to your app’s login page. You can also enable it manually from the same settings with the Enable Microsoft sign-in toggle.In Managed by Lovable mode, any Microsoft account can sign in: the tenant cannot be restricted, and the consent screen shows Lovable’s name. Switch to your own credentials for either.
- want zero setup
- are fine with the Microsoft consent screen showing Lovable’s name
- do not need to restrict sign-in to one organization
1
Prompt Lovable to add Microsoft sign-in
2
Test the flow
Verify that:
- a Microsoft sign-in button appears on your login page
- users are redirected to Microsoft to sign in
- users return to the app in a signed-in state
- new users appear in Cloud tab → Users
Managing Microsoft authentication
You can switch between Managed by Lovable and Your own credentials at any time from Cloud tab → Users → Auth settings → Microsoft. Switching back to Managed by Lovable deletes your stored client ID, secret, tenant, and redirect URL selections, so switching to your own credentials again means entering them fresh. Turning Enable Microsoft sign-in off also clears stored credentials. To remove the sign-in option, ask Lovable in chat:Troubleshooting
Microsoft sign-in stopped working after months of working fine
Microsoft sign-in stopped working after months of working fine
If you use your own credentials, your client secret has probably expired. Azure secrets expire on the date set when they were created. Create a new secret in the Azure Portal, copy its value, and save it in the Microsoft auth settings.
Users see a redirect error during sign-in
Users see a redirect error during sign-in
The redirect URIs in your Azure app registration don’t match the redirect URLs Lovable shows. Copy every URL from the Redirect URL(s) field into the Azure Portal under Authentication → Add a platform → Web exactly, then retry. If sign-in fails only on your published app or custom domain, also check your project’s redirect URLs.
People from outside my organization can't sign in
People from outside my organization can't sign in
That is your tenant setting doing its job. If it shouldn’t: in Cloud tab → Users → Auth settings → Microsoft, clear the Tenant ID (Directory ID) field to allow any Microsoft account, or set it to
organizations to allow work or school accounts from any organization. With your own credentials, also check that your Azure app registration’s supported account types allow those accounts.FAQ
Do I need an Azure account for Microsoft sign-in?
Do I need an Azure account for Microsoft sign-in?
Only if you use your own credentials. In Managed by Lovable mode, Lovable provides the OAuth configuration and no Azure account is needed.
Can I limit Microsoft sign-in to my company's employees?
Can I limit Microsoft sign-in to my company's employees?
Yes, with your own credentials. Enter your directory’s ID in the Tenant ID (Directory ID) field, and only accounts from that Microsoft Entra directory can sign in. Managed by Lovable mode cannot restrict the tenant.
Why does the consent screen say Lovable instead of my app's name?
Why does the consent screen say Lovable instead of my app's name?
The provider is in Managed by Lovable mode, so Microsoft shows the name of the app registration that requests sign-in, which is Lovable’s. Switch to Your own credentials to show your own app’s name.
Which Microsoft accounts can sign in?
Which Microsoft accounts can sign in?
By default, any Microsoft account: personal accounts and work or school accounts. With your own credentials you can narrow this to work or school accounts only, personal accounts only, or a single organization.
Does Microsoft sign-in replace email and password sign-in?
Does Microsoft sign-in replace email and password sign-in?
Can I switch between managed and my own credentials later?
Can I switch between managed and my own credentials later?
Yes, anytime from Cloud tab → Users → Auth settings → Microsoft. Switching back to Managed by Lovable deletes your stored client ID, secret, tenant, and redirect URL selections, so switching to your own credentials again means entering them fresh. Azure shows a secret’s value only once, so you may need to create a new secret then.