Entra Laravel Package

Product Decisions This Supports

• Enterprise SSO as a roadmap item, not a research spike. If your roadmap has "SAML/OIDC single sign-on" or "Enterprise tier" sitting in the backlog, this package turns that from an open-ended engineering question into a scoped integration task. It gives you a concrete answer for the most common customer request in B2B sales: "Do you support Microsoft sign-in?"
• Build vs. buy for identity. The default alternatives are (a) buying an identity platform (Auth0, WorkOS, Okta, Entra External ID) or (b) hand-rolling OIDC + Graph API calls. This package is a third option: a thin, MIT-licensed Laravel-native wrapper that assumes Microsoft is your IdP. That materially lowers the "buy" line item for teams already inside the Microsoft ecosystem.
• Authorization model: groups-as-roles. The package's polling of users and groups implies a design decision you should make explicitly — do you map Entra security groups to application roles/permissions, or maintain a parallel role table? If you choose groups-as-roles, IT admins at customer orgs manage access in a tool they already own, which removes an entire admin UI from your roadmap.
• Tenant and provisioning scope. Because it targets Entra specifically, it implicitly decides that you are a Microsoft-shop product. That is fine for UK public sector / rail / enterprise accounts; it is a narrowing decision worth naming in your strategy doc rather than discovering later.
• Procurement and compliance positioning. SSO plus directory-driven group sync is a checkbox on most enterprise security questionnaires (access review, leaver deprovisioning, least privilege). Enabling it unblocks deals and shortens security review — a revenue decision as much as a technical one.
• Deal qualification input. If a prospect is on Google Workspace or Okta exclusively, this package does not serve them; that should inform which segments you pursue next quarter and whether a second connector is justified.

When to Consider This Package

Adopt it when most of the following are true:

• Your application is Laravel/PHP and you have no intention of changing that.
• Your customers are Microsoft Entra (Azure AD) tenants — common in UK enterprise, government, rail, and regulated industries.
• You need two things and only two things right now: letting users sign in with their work account, and reading users/groups to drive roles or reporting.
• You have engineering capacity to own the integration. With 1 GitHub star and 0 dependents, this is effectively unproven in the wild — treat it as a maintained internal library that happens to be public, not as an ecosystem standard. Expect to read the source, pin a version, and be prepared to fork.
• Your risk tolerance for a small-vendor, single-maintainer dependency is acceptable because the failure mode is contained: if it breaks, you fall back to calling Microsoft Graph and Entra OIDC directly. The package is a convenience layer, not a data store — no migration or lock-in cost.
• MIT licensing fits your legal posture (it does; no commercial terms to negotiate).

Look elsewhere — or plan a wrapper — when:

• You need Okta, Google, Ping, or generic OIDC/SAML support, or multi-IdP per tenant. You want a broker (WorkOS, Auth0) or Laravel Socialite plus your own abstractions.
• You need provisioning into Entra (SCIM outbound), conditional access policy management, B2C/External ID, or MFA orchestration. This package is read/sign-in oriented.
• You require a vendor SLA, security disclosure process, CVE response commitments, or a support contract. One star and zero dependents means no community safety net and no commercial backing.
• Your release process demands a stable, semantically-versioned dependency with a public changelog and multiple maintainers. Note also that the listed last-release date is in the future, which suggests metadata you should verify before relying on release cadence as a signal.
• You are building a multi-tenant SaaS where per-tenant IdP configuration, token validation, and secret rotation are core product surface — you will outgrow a thin wrapper quickly.

Mitigation regardless of decision: hide it behind your own IdentityProvider interface with a small adapter. Cost is a day of work; it converts a supply-chain risk into a swap.

How to Pitch It (Stakeholders)

To executives (30 seconds): Enterprise buyers routinely reject software that can't sign users in with their Microsoft work accounts and can't respect the access groups their IT team already manages. This package lets our Laravel product do both in days rather than weeks, at zero licence cost, using the identity system our target customers already pay for. Recommendation: fund a one-sprint integration behind our own abstraction layer, so we capture the sales unblock without taking on dependency risk.

To engineering: It's a small MIT-licensed Laravel wrapper for Entra sign-in and Graph-based user/group reads. It's a starting point, not a foundation — one star, no dependents, effectively single-maintainer. We vendor it behind an interface, pin the version, add contract tests against a test tenant, and keep a documented fallback to direct OIDC + Graph calls. Effort estimate: roughly 3–5 days including the abstraction and tests.

To sales/CS: We can say yes to "Microsoft SSO" for Entra-based prospects, and admins can manage who has access from their existing Entra groups rather than a new admin panel. For Okta or Google-only prospects, we still say "on the roadmap" — don't promise parity.

To security/procurement: No data leaves the customer's tenant beyond standard OIDC/Graph calls; no vendor contract, no PII storage in the library. Residual risk is maintenance, not data handling — mitigated by forking rights under MIT and a small, isolated code surface.