Microsoft Laravel Package

Product Decisions This Supports

• Enterprise (B2B) authentication roadmap. "Sign in with Microsoft" is a recurring gating requirement in enterprise procurement and security reviews. This package lets a Laravel app offer Microsoft 365 / Entra ID (Azure AD) login without building a bespoke OAuth2 implementation — it plugs into the Socialite provider ecosystem the app likely already uses.
• Build vs. buy. The decision is not "build an identity system"; it's "add Microsoft as one more Socialite driver." That is typically a day of integration work versus weeks of custom token, tenant, and callback handling. The package is a thin, single-purpose adapter, so the build-vs-buy call is low-stakes and reversible.
• Onboarding and activation for B2B accounts. Corporate users authenticate with existing work credentials instead of creating and managing another password, reducing signup friction and time-to-value for organizational rollouts.
• Account-type scoping (a real product decision). The multi-tenant configuration lets you target work/school accounts only, personal Microsoft accounts only, or both. That choice maps directly to whether you're selling to enterprises, prosumers, or education — Microsoft accounts are near-universal in K-12 and higher ed.
• Platform consolidation. Keeps all third-party identity behind one Socialite::driver(...) interface instead of introducing a second auth stack alongside existing Google/GitHub/SSO providers.
• Option value on adjacent roadmap bets. A working Microsoft login is the prerequisite for later Microsoft Graph work (calendar, mail, Teams, OneDrive). Adopting this now keeps those options cheap, since the tokens obtained here are the entry point.

When to Consider This Package

Adopt when:

• The application is Laravel and already uses (or plans to use) Laravel Socialite with the SocialiteProviders manager.
• The requirement is authentication — verify a Microsoft identity, receive a token, map a user — not deep Microsoft Graph integration.
• You need multi-tenant Entra ID support (consumers, organizations, or both) and can accept a community-maintained provider rather than a vendor-backed one.
• You want minimal surface area and no lock-in: it's small enough to fork or replace with a short in-house AbstractProvider subclass if it stalls.

Look elsewhere when:

• You're not on Laravel — use league/oauth2-client or Microsoft's own MSAL libraries.
• You need SAML or WS-Federation, which many enterprise IT departments still require; OAuth2/OIDC won't satisfy every customer.
• You need full Microsoft Graph capability — directory sync, mailbox access, Teams APIs. Pair with the official Microsoft Graph SDK; don't expect this provider to cover it.
• You need enterprise-grade identity features — SCIM provisioning, conditional access enforcement, MFA policy, audit logging. Those belong to a dedicated IdP (Entra ID, Okta, Auth0, WorkOS), not a Socialite driver.
• You require vendor SLAs or security attestations. This is community-maintained. The package-level signals (35 stars, 0 dependents) are weak in isolation and likely understate real usage — this is a split package inside the larger socialiteproviders/providers monorepo — but treat them as a prompt to verify release cadence and maintainer responsiveness, and as a signal not to make it a strategic identity dependency.
• You need native/mobile or daemon/background Graph flows, or a stateless API-only backend; the server-side session-based OAuth state model doesn't fit without extra work.

Verify before committing: release cadence of the monorepo, Composer constraints against your installed laravel/socialite and socialiteproviders/manager versions, tenant configuration support in the pinned version, and which of the overlapping Microsoft drivers (microsoft vs microsoft-azure) matches your tenant model.

How to Pitch It (Stakeholders)

For executives: Enterprise buyers routinely ask for "Sign in with Microsoft" before they'll roll out to their organization — it's a recurring blocker in enterprise deals and procurement reviews. This package delivers that capability on top of the identity layer we already run, so it's a configuration change rather than a new system, a new vendor contract, or a fresh security review. It removes that blocker at a fraction of the cost of a custom build, lowers onboarding friction for corporate customers, and keeps the door open for Microsoft 365 integrations later.

For engineering: It's a single-purpose Socialite provider inside a well-known community monorepo — no new framework and no new runtime dependency beyond the OAuth2 provider contract. Implementation is a service-provider registration plus an event listener for SocialiteWasCalled, a microsoft block in config/services.php, and the standard redirect/callback routes. The token and user payload land in the existing Socialite flow, so downstream user mapping stays identical to our other providers.

The risks are narrow and containable, and we should name them honestly:

• Community-maintained rather than Microsoft-official, with a low visible adoption signal at the split-package level.
• Real engineering effort sits outside the package: tenant topology, app registration, admin consent, scope selection, redirect URI inventory, and secret rotation. That is one to two weeks of cross-team work, not one day, for a production rollout.
• Identity mapping must not key on email, which is not reliably present or stable across account types; use the Entra object ID (oid) plus tenant ID.
• Common production failure modes are operational — expired client secrets (AADSTS700016/login outage), missing consent after scope changes (AADSTS65001), redirect URI mismatches (AADSTS50011), and session/state mismatches behind load balancers. Each needs an owner and a runbook.

Mitigations are cheap: pin the package, verify Composer constraints against Socialite majors, add an integration test against a non-production tenant, run a pilot behind a feature flag with parallel login, and keep the provider shim thin enough to swap for a first-party implementation or MSAL if it goes stale. Staff an identity owner alongside the Laravel developer — the package is a replaceable adapter inside a larger Microsoft identity integration, and it should be treated as such.