Microsoft authentication

Microsoft authentication lets your users sign in with Microsoft accounts (personal accounts and/or work accounts, depending on your app settings). Once connected, you can offer "Continue with Microsoft" in your WeWeb app.

What this integration supports

• Social sign in with Microsoft
• Redirect to different pages for success, error, and first-time users
• Link Microsoft sign in to an existing email/password account when Microsoft confirms the email is verified

Setup in the Microsoft dashboard

All configuration for this provider happens in the Azure portal (or Microsoft Entra admin center). You will create an app registration, add the fixed WeWeb callback URL under the Web platform, and copy the credentials WeWeb needs.

1. Create an app registration

1. Go to the Azure portal.
2. Open Microsoft Entra ID (or Azure Active Directory) and go to App registrations.
3. Click New registration.
4. Enter a name for your app.
5. Choose the supported account types for your project.
6. Leave the Redirect URI field empty for now and click Register.

2. Add the redirect URI under Web

WeWeb always uses a fixed callback endpoint for Microsoft sign in. Microsoft never sends users back to your Success Page directly.

1. Open your app registration and go to Authentication.
2. If you do not already have a Web platform, click Add a platform and choose Web.
3. Under Redirect URIs, add the Microsoft callback URL for each environment you use:

Environment	Redirect URI
Editor project	https://<your-project-id>-editor.weweb.io/api/auth/callback/microsoft
Staging app	https://<your-project-id>-staging.weweb-preview.io/api/auth/callback/microsoft
Published app	https://<your-project-id>.weweb-preview.io/api/auth/callback/microsoft

4. Click Save.

USE WEB, NOT SINGLE-PAGE APPLICATION

The redirect URI must sit under the Web platform in Azure.

If you add it under Single-page application instead, Microsoft may accept the sign-in request but block the token exchange. You will usually see an invalid_code error.

CALLBACK URL VS SUCCESS PAGE

The Azure redirect URI is always the provider callback URL, such as https://<your-project-id>-editor.weweb.io/api/auth/callback/microsoft.

The Success Page, Error Page, and New User Page you choose in WeWeb are separate. They are the pages inside your app where users land after the Microsoft callback is complete.

CUSTOM DOMAINS

If you publish your app on a custom domain, the callback URL still uses your WeWeb project domain.

For example, if users visit https://www.example.com, you still register https://<your-project-id>.weweb-preview.io/api/auth/callback/microsoft in Azure, not the custom domain.

3. Create a client secret

1. Open Certificates & secrets.
2. Click New client secret.
3. Add a description and choose an expiry period.
4. Click Add.
5. Copy the secret Value right away. Azure only shows it once.

When you paste the secret into WeWeb, use the Value, not the Secret ID.

4. Copy your app credentials

From your app registration, copy:

• Application (client) ID
• The client secret Value from the previous step
• Directory (tenant) ID If your app is restricted to one organization

Connect Microsoft in WeWeb

1. In the WeWeb editor, open the Data & API tab, then open the Authentication subtab and go to SSO Providers.
2. Find Microsoft and expand it.
3. Turn on the Enable toggle.
4. Paste your values:
   • Client ID
   • Client Secret
   • Tenant ID If your app registration is single-tenant (leave this empty only if you allow multi-tenant or personal accounts)
5. Click Save.

After you change provider settings, give the server a few seconds to redeploy before testing again. Republish for staging and production changes.

Test sign in

1. In Interface, add a "Continue with Microsoft" button.
2. Create a workflow on click and add Sign in with social provider.
3. Set:
   • Provider: microsoft
   • Success Page, Error Page, And (optional) New User Page
4. Preview your project and complete the Microsoft sign-in flow.
5. Confirm that:
   • You are redirected to the correct page in your app after sign in.
   • You are authenticated as the corresponding user.

For general information about how sessions, roles, and page protection work once a user is signed in, see Using authentication in WeWeb →.

Link Microsoft to existing email/password users

If a user already exists in your WeWeb project from email/password sign in, Microsoft sign in will not auto-link to that account unless Microsoft confirms the email is verified.

By default, Microsoft Entra ID does not include an email verification claim in the ID token. Google and GitHub do, but Microsoft does not unless you add it in Azure.

Add the verified email claim in Azure

1. In Azure, open your app registration and go to Token configuration.
2. Click Add optional claim.
3. Set Token type to ID.
4. Select verified_primary_email and email if it is missing.
5. Click Add.
6. Sign out fully, then sign in with Microsoft again.

After Microsoft sends the verified email claim, WeWeb can link the Microsoft account to the existing user. The user keeps the same ID, roles, and data. Microsoft becomes an additional sign-in method.

If the claim comes back empty

Some tenants do not populate the verified email claim for every user. In that case, the fallback is to delete the existing user in Data & API → Authentication → Users and let Microsoft create a new account on the next sign in.

Only do this if nothing important is tied to that user's ID, because they will get a new one.

Make Microsoft the only sign-in method

Once Microsoft sign in works, you can go to Data & API → Authentication → SSO Providers and disable the Email provider, or disable sign up, to prevent new email/password accounts.

Every existing email/password user will hit account_not_linked on their first Microsoft sign in until the verified email claim is working. Test with one user before rolling out Microsoft sign in to your whole team.

Common pitfalls

Redirect URI mismatch (AADSTS50011)

If Microsoft shows an error like AADSTS50011: The redirect URI ... does not match the redirect URIs configured for the application, the callback URL WeWeb sent is not listed in Azure.

1. Copy the exact redirect URI from the error message.
2. In Azure, open App registrations → your app → Authentication.
3. Under the Web platform, add that exact URL.
4. Click Save and try a fresh sign in.

The error message itself is often the fastest way to get the right value.

Using the success page as the Microsoft callback

The Success Page in the Sign in with social provider action is not the value you paste into Azure.

• Microsoft needs the fixed WeWeb callback URL: https://<your-domain>/api/auth/callback/microsoft.
• The action page settings only decide where the user lands after that callback is complete.

invalid_code after the redirect URI is correct

If Microsoft accepts the redirect but sign in still fails with invalid_code, check these common causes:

• The redirect URI is under Single-page application instead of Web.
• You pasted the client secret Secret ID instead of the secret Value.
• Your app registration is single-tenant, but Tenant ID is empty in WeWeb.
• You refreshed or retried on the callback error page. The login code is single-use, so start a fresh sign in from your button each time.

account_not_linked for an existing user

This means WeWeb found an existing account with the same email, but Microsoft did not confirm the email is verified.

Add the verified_primary_email claim in Azure as described above, then test again with a full sign out first.

Wrong account type or tenant

If some users cannot sign in, check whether your app registration is limited to a specific organization (tenant) or account type.

• For single-tenant apps, paste the Directory (tenant) ID into the Tenant ID field in WeWeb.
• For multi-tenant or personal account apps, leave Tenant ID empty unless your setup requires it.

Reference

WeWeb settings reference

Setting	Description	Where to find it in Microsoft
Enable	Turns Microsoft sign in on for your WeWeb project.	Not used in Azure. Turn this on in WeWeb after you finish the Microsoft setup.
Client ID	Identifies your Microsoft app registration.	App registration Overview → Application (client) ID.
Client Secret	Secret used by WeWeb when completing the Microsoft sign-in flow.	Certificates & secrets → copy the secret Value.
Tenant ID	Tells WeWeb which Microsoft tenant to use for single-tenant apps.	App registration Overview → Directory (tenant) ID. Leave empty for multi-tenant or personal account setups unless your app requires it.

Microsoft values to prepare

Microsoft field	What to enter
Web redirect URI	The full callback URL, such as https://<your-project-id>-editor.weweb.io/api/auth/callback/microsoft.
Optional ID token claim	verified_primary_email (and email if missing) when you need to link Microsoft sign in to existing email/password users.

FAQs

Which redirect URI should I add in Microsoft?

Add the fixed WeWeb callback URL for each environment you use:

• https://<your-project-id>-editor.weweb.io/api/auth/callback/microsoft
• https://<your-project-id>-staging.weweb-preview.io/api/auth/callback/microsoft
• https://<your-project-id>.weweb-preview.io/api/auth/callback/microsoft

If you publish on a custom domain, still use your WeWeb project domain for the callback URL.

Is the success page the same as the Microsoft redirect URI?

No. The Microsoft redirect URI is the fixed callback URL ending in /api/auth/callback/microsoft. The success page is where WeWeb sends the user after Microsoft sign in has already finished.

Why do I get invalid_code even after adding the redirect URI?

The redirect URI may be under Single-page application instead of Web, or you may have pasted the client secret Secret ID instead of the secret Value. Single-tenant apps also need Tenant ID filled in WeWeb.

Why do I get account_not_linked for a user who already signed up with email?

WeWeb will not auto-link a social login to an existing email/password account unless the provider confirms the email is verified. Add the verified_primary_email optional claim in Azure, then test again after a full sign out.

Can I use Microsoft sign in and email/password together?

Yes. You can enable both providers and let users choose how to sign in. If you want Microsoft to be the only way in, disable the Email provider or disable sign up after Microsoft sign in is working.

Continue learning

After Microsoft sign in is working, the next step is deciding what authenticated users can access.

Managing roles →