Microsoft Azure Laravel Package

Product Decisions This Supports

• Enterprise SSO as a roadmap item (build vs. buy): This package is the "buy" answer for letting users in Microsoft-entra-tenant organizations sign in with their work accounts. It removes a multi-week OAuth2 integration (tenant discovery, token exchange, Graph profile fetch) from your backlog and replaces it with configuration plus a single event listener registration. The decision it informs is not "should we support SSO" but "do we ship SSO this quarter by wiring a dependency, or next quarter by building it ourselves."
• B2B/enterprise tier viability: Microsoft Entra ID (formerly Azure AD) is the identity provider for a large share of mid-market and enterprise buyers. If your product's expansion motion targets companies on Microsoft 365, this package is the enabling dependency for a feature that frequently gates procurement and security review. Treat it as a prerequisite for the enterprise plan, not a nice-to-have.
• Multi-tenant vs. single-tenant go-to-market: The tenant config value is a product lever, not just a credential. A multi-tenant app ID lowers sales friction (any customer can self-serve connect), while a single-tenant configuration supports customers who mandate a dedicated app registration in their own tenant. The package supports both without code forks, so you can decide per-deployment or per-customer-segment rather than per-release.
• Segment-specific deployment variants: The optional proxy setting and overridable graph_url mean you can serve customers behind corporate proxies and customers on sovereign/non-commercial Microsoft clouds (e.g., GCC High, government or regional Graph endpoints) with configuration only. That converts "we can't support regulated customers" into a supportable segment without new engineering work — but see the trust caveat below.
• Scope of identity data you can promise customers: Because the provider calls Microsoft Graph for the profile, the attributes you get back are governed by the Graph endpoint and app permissions you configure. This shapes what onboarding flows are feasible (email, display name, tenant/object IDs for account linking) and what you must still collect separately.
• Feature prioritization relative to other identity providers: Compared with adding Google, Okta, or generic SAML, this is a narrow, low-effort increment. It should be sequenced by customer demand concentration — if a meaningful share of your pipeline runs on Microsoft 365, this outranks a more general "more IdPs" initiative.

When to Consider This Package

Adopt when:

• You are on Laravel and already use Socialite (or are willing to), so the SocialiteProviders manager pattern is a natural fit rather than an extra abstraction layered on your auth stack.
• Microsoft Entra ID sign-in is a named requirement in active deals or a documented top request, and you need it in weeks, not quarters.
• You need both workforce and customer-facing scenarios covered by one integration, including multi-tenant self-serve and single-tenant locked-down deployments.
• You operate behind an egress proxy or need to point Graph calls at a trusted non-default endpoint (including test mocks) — the exposed config covers this.

Look elsewhere or build in-house when:

• You need group/role claims, directory sync, SCIM provisioning, or conditional-access-aware flows. This package authenticates a user; it is not an identity governance integration. Those requirements mean a larger IdP integration or an enterprise identity vendor.
• You need SAML rather than OAuth2/OIDC, or you need to act as the identity provider rather than the relying party.
• Third-party dependency risk is unacceptable for an auth-critical path. The signals here are thin: roughly 60 stars and no dependent packages means limited community validation and a small blast radius if maintenance lapses. Auth is a security-sensitive dependency, so require a review of the maintainer cadence (recent releases are a positive signal) and a pinning/upgrade policy before committing.
• The graph_url override is genuinely a trust boundary — access tokens are sent to whatever endpoint is configured. If your deployment model lets less-trusted operators change environment configuration, either lock that variable down or reconsider exposing it.
• Your stack is not Laravel, or you have standardized on a different Socialite provider fork; porting cost likely exceeds the benefit given the modest size of this integration.

How to Pitch It (Stakeholders)

To executives: Enterprise buyers on Microsoft 365 currently can't use their work accounts to sign in, which shows up as friction in procurement and security review. This package lets us close that gap with configuration rather than a custom build — days of integration work instead of a multi-week project — and it covers the two commercial shapes we sell into: self-serve multi-tenant connection and customer-owned single-tenant app registrations. The tradeoff is a small third-party dependency in the auth path with limited community adoption, which we mitigate with version pinning, a security review, and an exit path to a first-party implementation if needed.

To engineering: It's a SocialiteProviders OAuth2 driver for Microsoft Entra ID. Install via Composer, add an azure block to config/services.php (client ID, secret, redirect, tenant, optional proxy and Graph URL), and register the SocialiteWasCalled listener in AppServiceProvider::boot() for Laravel 11+. We get tenant configurability, proxy support, and an overridable Graph endpoint for testing — no custom OAuth code and no new architectural pattern. Risks to flag: auth-critical dependency with low adoption, so pin the version, review the Graph URL override as a token-exposure surface, and keep our auth abstraction thin enough that swapping to an in-house provider later is contained.