Sign in with Microsoft

"Microsoft" covers three populations: enterprise users on Microsoft Entra ID (formerly Azure AD), personal Outlook / Hotmail accounts, and Xbox / Skype accounts. From a protocol standpoint they all speak the same OIDC dialect; the difference is which audience your application accepts.

This topic is the OIDC-flavoured social connection. If you want a SAML SSO tie-in with a specific enterprise Entra tenant, see the SAML-Entra topic instead.

Before you start

You need an Entra ID application registration. Sign in to the Azure portal → Entra ID → App registrations → New registration.

Name — what users see on the consent screen ("Cymmetri Banking").
Supported account types — pick one:
- "Single tenant" — only users in your Entra tenant can sign in.
- "Multi-tenant" — users from any Entra tenant.
- "Multi-tenant + personal" — Entra users + personal Microsoft accounts (Outlook / Hotmail / Xbox).
Redirect URI — Web → https://<your-tenant-url>/auth/callback/microsoft.

After creation, note:

The Application (client) ID.
Generate a client secret under Certificates & secrets. Copy it once; you can't view it later.

Step 1 — register the redirect URI

The Redirect URI must be exact:

https://<your-tenant-url>/auth/callback/microsoft

For multi-tenant apps, Microsoft also checks the URI scheme — HTTPS is required for any non-localhost host.

Step 2 — add the connection in IntelliAuth

Tenant admin console → Authentication → Social providers → Microsoft.

Fill in:

Client ID — the Application (client) ID from Entra.
Client secret — the secret you generated.
Tenant — your Entra tenant id, or common for multi-tenant, or consumers for personal-account-only, or organizations for any work/school account.

Save. The connection is live.

Step 3 — add the button in your app

<button onClick={() => loginWithRedirect({ connection: 'microsoft' })}>
  Sign in with Microsoft
</button>

What ends up in the user record

Microsoft's id token carries:

sub — the user's stable Entra id (an opaque GUID).
oid — the object id within the Entra tenant. Useful if you cross-reference with Graph API later.
tid — the Entra tenant id. Tells you which Entra tenant the user signed in from.
email — varies. For work accounts the primary email; for personal accounts the user's chosen email. Always check email_verified.
preferred_username — the user-facing email or UPN.
name — the user's full name.

IntelliAuth maps these to a user record. The mapping is configurable per connection — e.g., you can tell IntelliAuth to use oid as the unique identifier instead of sub if your existing user database is keyed on Entra object id.

Tenant restriction

Multi-tenant apps can sign in any Entra user. If you only want a specific list of Entra tenants, enforce the check in your app: read tid from the id token and reject anything outside your allowlist. Microsoft does not natively restrict an app to a tenant list — they offer single-tenant or multi-tenant, with no middle option.

When to use this vs SAML-Entra

OIDC social (this topic) is right when you want a "Sign in with Microsoft" button for any Microsoft user.
SAML-Entra is right when you need IT-managed SSO for a specific enterprise customer — they own the Entra tenant, they configure IntelliAuth as a SAML Service Provider, and JIT provisioning kicks in for any of their users.

If you are unsure which your customer wants, ask. IT teams typically prefer SAML for centralised control and offboarding; self-service products typically prefer the OIDC social path.

Some scopes Microsoft offers require admin consent — an Entra tenant administrator must approve the app on behalf of users. For the basic openid profile email set, end-user consent is enough. For anything reading Microsoft Graph (calendars, mail, directory data), expect admin consent and surface that in your onboarding copy ("Your IT admin will need to approve Cymmetri before you can sign in.").