Players choose Microsoft on the hosted login page and sign in with their personal Microsoft account, the same account they use on Xbox. You need a Microsoft Entra app registration for personal accounts and a client secret.
1. Register an app with Microsoft
In the Microsoft Entra admin center, open App registrations and select New registration. Any Microsoft Entra directory works, including one that comes with a free Azure account.
Under Supported account types, choose Personal Microsoft accounts only. auth4.dev signs players in through Microsoft's consumer endpoint, which accepts only these accounts.
Under Redirect URI, choose the Web platform and enter this URL, replacing {projectId} with your Project ID:
The console shows the exact URL with a copy button on the Microsoft (Xbox) card. It must match exactly, and it must be the Web platform, not a single-page application.
Register the app and copy the Application (client) ID from its overview page.
Under Certificates & secrets, add a client secret and copy itsValue (not its secret ID) straight away; Microsoft shows it only once. Note when it expires.
2. Connect it in the console
On the project's sign-in methods page, under Microsoft (Xbox):
Paste the client ID into Application (client) ID.
Paste the secret's value into Client secret.
Tick Enable Microsoft sign-in.
Select Save Microsoft settings.
Only project owners can change these settings; admins and viewers see them read-only. The secret is write-only: it is stored encrypted and can't be viewed again.
Microsoft client secrets expire. Before yours does, add a new secret in the app registration, enter it in Replace client secret and save, then delete the old one. If you change the client ID you must also enter its secret.
Once Microsoft is on, players see it in three places:
Continue with Microsoft on the hosted login page.
Link a Microsoft account on the page where guests save their progress.
Continue with Microsoft on the device approval page.
Untick the box and save to turn Microsoft off. The option disappears from all three pages.
What identity data you get
Players are identified by the ID Microsoft gives them for your app registration (the ID token'ssub). It is different for each app registration, so keep using the same one: if you switch to another registration, returning players arrive as new players. The ID is stored as the player's Microsoft identity and isn't put in your tokens. Key game data by your auth4.devsub.
Microsoft may share the account's email address, but doesn't say whether it is verified. auth4.dev stores it and never marks it verified, so don't treat it as proof that the player owns that address. Under the default setting, hosted login therefore asks Microsoft players for the verified email step until they have verified an address with auth4.dev.
A Microsoft account and an email-code, Discord, Google or Apple account with the same address are separate players. They are joined only through account linking in the email step.
Microsoft's tokens and your client secret stay on the server. Your application only receives auth4.dev tokens.
Sending players straight to Microsoft
For a Sign in with Microsoft button, pass the provider to the browser SDK. The hosted login page then goes straight to Microsoft:
await auth4.login({ provider: "microsoft" });
login() sends provider_hint=microsoft. The Next.js SDK takes the same provider. If you build the authorization request yourself, add that parameter. If Microsoft is off for the application, the player sees the usual list instead. See theAPI reference.
Linking Microsoft to a guest
A guest can save their progress by linking a Microsoft account. They keep the same user ID and stop being a guest. Call upgradeGuest() or, in Unity, UpgradeGuestAsync without a provider, and the upgrade page offersLink a Microsoft account with the other enabled methods. Only a Microsoft account that is new to your project moves to the guest; otherwise the upgrade fails with identity_in_use. Accounts are never merged.
Device approval
When Microsoft is on, the device approval page offers Continue with Microsoft. This suits console and PC players: they approve the game's code on a phone or PC with the Microsoft account they already use. Your game calls SignInWithDeviceAsync as usual; nothing changes on the game's side.
When something goes wrong
If the player cancels on Microsoft, the page says that Microsoft sign-in was cancelled and lets them choose another method.
If Microsoft is unreachable or refuses the request, the page reports a temporary problem and offers a retry. An expired or wrong client secret shows up this way.
If Microsoft shows an error on its own page about the redirect URI or account type, check that the registration uses the Web platform, the exact redirect URI and Personal Microsoft accounts only.
If the Microsoft option doesn't appear, check that the box is ticked and a client ID and secret are saved. Incomplete configuration fails closed rather than showing a broken button.
Testing locally
Your app can run on localhost, but Microsoft sign-in itself always happens on the hosted pages and on Microsoft, so you need a real personal Microsoft account. Use a separate auth4.dev project for testing. To run the auth4.dev API itself against a local stand-in, see Testing locally on the Google page; the same setting covers Microsoft.