Microsoft & Xbox Login in Unity (OAuth, no backend)

Microsoft login covers a big, cross-cutting audience: personal Microsoft accounts, Xbox players, and Windows users, all through one identity. This guide wires it up with OAuth, no backend, and covers the email field quirk that catches people out when work or Xbox accounts are involved.

When Microsoft login fits

Microsoft is a mainstream identity with a strong Xbox and Windows tilt. It fits games that ship on Windows or Xbox, titles targeting players in the Microsoft ecosystem, and anything where "Sign in with Microsoft" reaches an audience your other providers miss. Because Microsoft and Xbox accounts are the same identity, a player signs in once and you have them — the full Xbox Live layer (gamertag, achievements) is a separate service, but the sign-in is standard Microsoft OAuth.

Step 1: Register an app in Entra (Azure AD)

1. Go to the Microsoft Entra admin center → App registrations → New registration.
2. Under Redirect URI (platform: Web), set it to exactly:

https://sso.oathwall.com/auth/callback

3. Choose the supported account types — personal Microsoft accounts, or personal plus work/school, depending on who you want to let in.
4. Copy the Application (client) ID, then under Certificates & secrets create a client secret and copy its value.

Step 2: Paste your credentials into Oathwall

In the Oathwall dashboard, add Microsoft as a provider and paste the Client ID and Client Secret. The secret stays server-side; Oathwall runs the token exchange and reads the profile from Microsoft Graph for you. Oathwall requests the openid, profile, email, and User.Read scopes — enough to read the display name and email, nothing more.

Step 3: Wire it up in Unity

Same base class, same single call as every other provider:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // openid + profile + email + User.Read scopes.
    // Client secret stays on Oathwall's servers.
    public void OnMicrosoftButton() => StartLogin("microsoft");

    protected override void OnLoginSuccess(LoginResult user)
    {
        // user.email may be a UPN for work/guest accounts.
        LinkPlayer(user.id, user.name);
    }
}

StartLogin("microsoft") opens Microsoft's sign-in page in the system browser. Oathwall exchanges the code and reads the profile from Graph's /me — user.id is the stable account id, user.name is the display name, and user.email is the account email (with a fallback described below).

The gotchas worth knowing

The email field isn't always an email. For personal Microsoft accounts, you get the account email cleanly. For work or school (Entra) accounts, Graph's mail field can be empty, so Oathwall falls back to the userPrincipalName. That usually looks like an email — but for external B2B guest accounts it contains a #EXT# marker and isn't a deliverable address. Treat user.email as an identifier that may or may not be a real inbox, and key your player records on the stable user.id. That "don't trust the email as a primary key" discipline is the same one Apple enforces with its private relay addresses.

Account types are decided at registration. Whether personal accounts, work/school accounts, or both can sign in is set when you register the app (step 1.3). If Xbox and personal players can't get in, check that setting first — it's a portal configuration, not a code bug.

No avatar comes back by default. The basic Graph profile gives you the display name and email, not a photo. If your UI wants an avatar, use a default set keyed on the account id.

Microsoft is a mainstream provider you can offer on its own or beside others. The Unity authentication guide shows several providers sharing one login class, and since Oathwall stores refreshable sessions, a returning player stays signed in — see access tokens vs refresh tokens for how that keep-alive works.