Oauth2 Server Laravel Package

Product Decisions This Supports

• Public/partner API strategy — the gating decision. An OAuth 2.0 authorization server is the dependency underneath any roadmap item that says "we expose an API to third parties": partner integrations, marketplace/embedded apps, "Sign in with us," and machine-to-machine access. This package is one candidate implementation in that build-vs-buy-vs-adopt conversation, not the conversation itself. The PM decision is who owns the maintenance of a security-critical component, not whether the protocol is hard.
• Build vs. buy vs. adopt, framed as TCO. The real comparison set is Laravel Passport (first-party Laravel path, built on league/oauth2-server), league/oauth2-server directly (the maintained successor to the codebase this forks), and managed identity providers (Auth0, Okta, Keycloak, Ory Hydra). This package anchors the "adopt a small MIT library we can read and patch" branch — and its two-star, zero-dependent profile is the honest counterweight to that branch.
• Monetization and packaging levers. Grant types, scopes, and token lifetimes are product surface, not plumbing. Scoped API access maps to pricing tiers; client-credentials maps to usage-based and B2B plans; refresh-token policy maps to session length and seat-count rules. Decide these before engineering picks a library, because the library constrains how expressible they are.
• Enterprise readiness and sales enablement. "Do you support OAuth 2.0?" is a recurring security-questionnaire and procurement checkbox. Shipping it unblocks deals; not shipping it defers them. This is the clearest, most defensible justification for the work regardless of which implementation wins.
• Use cases it can plausibly serve: mobile app token issuance, service-to-service authentication, delegated access for customer-built integrations, and scoped access for a plugin/app ecosystem.
• Roadmap hygiene on a security-sensitive dependency. Because this is a single-vendor fork, adoption is effectively a commitment to own a security-critical component. That belongs on the roadmap as a named line item with a named owner — not as a silent transitive dependency that surfaces during an incident.

When to Consider This Package

Consider it when:

• You are already on OroPlatform/OroCommerce. This fork exists to keep a proven OAuth 2.0 server library running on the PHP versions that stack supports. That is its single strongest justification, and outside that context the case gets thin fast.
• You have an existing deployment on brentshaffer/oauth2-server-php and a PHP upgrade is blocked. A fork is a cheaper bridge than a rewrite — treat it as a security-patch swap gated by a conformance test suite.
• You need the library primitive only — grants, token storage, scopes — and are prepared to write the framework glue and the scope-enforcement middleware yourself.
• Your security posture genuinely favors small, auditable, MIT-licensed code you can read and patch over a large vendor surface, and you have the OAuth2 depth in-house to back that preference.

Look elsewhere when:

• Greenfield Laravel. Use Laravel Passport (which wraps league/oauth2-server) for OAuth 2.0, or Sanctum if you only need first-party API tokens. Despite how it is described, this is not a Laravel package — there is no service provider, config, facade, or Eloquent integration. You supply all of it, including adapting Illuminate\Http\Request into the library's own request/response objects.
• Greenfield non-Laravel PHP. Use league/oauth2-server, the maintained successor to the codebase this is forked from.
• You need OpenID Connect, PKCE-first flows, OAuth 2.1, FAPI, token introspection, or an active CVE-response process. None of that is a realistic expectation from a two-star single-vendor fork. If OIDC or introspection is in scope now or plausibly within twelve months, disqualify it outright.
• You need an SLA, vendor support, or a dependency your security team will accept without a waiver.
• Signals to weigh honestly: 2 stars, 0 dependents, no external bug reporters, no contributor pool, no downstream canary population to catch regressions. Treat it as vendored code with a familiar lineage, not as a dependency with an ecosystem. Budget for a fork-and-vendor strategy within twelve months.

The decision rule: total cost of ownership over 18 months, not license price. Zero license cost is real but small next to the cost of a named internal owner, a patch cadence, and an external security review.

How to Pitch It (Stakeholders)

To executives: Standards-based API authentication is a prerequisite for our partner-integration and enterprise-sales roadmap — buyers and security reviewers expect OAuth 2.0, and its absence shows up as deal friction rather than as a line item on a plan. This package's license cost is zero and its lineage is proven, which makes it tempting; the real cost is ownership. It is a small single-vendor fork with essentially no community, no dependents, and no visible CVE process, so adopting it means our team carries the security patching for a component that, if it fails, fails closed across every protected surface at once. My recommendation is to treat it as a reference implementation and fallback rather than the default. If we are on the Oro stack, adopt it and budget maintenance explicitly. If we are on Laravel or greenfield PHP, standardize on league/oauth2-server via Passport instead — same protocol, maintained upstream, and we get the ecosystem and the Laravel integration for free.

To engineering: It is a fork of the long-standing brentshaffer/oauth2-server-php, so the grant and token machinery will look familiar and the learning curve is low. What we inherit is the maintenance: PHP-version compatibility, security patches, and any protocol modernization — PKCE, refresh-token rotation and replay detection, redirect-URI validation, token introspection — all land on us. The largest integration tax is the request/response abstraction mismatch, and that is also the most common source of subtle bugs. Realistic ramp-up to production-hardened is two to four weeks against roughly two to four days with Passport, plus an external security review that I consider non-negotiable for an auth server.

The ask: Approve a one-to-two-week evaluation spike rather than a direct adoption. Scope it to three things: (a) confirm the fork's supported PHP range and composer.json constraints against our target stack, and establish what Oro actually changed versus upstream and whether those changes matter outside OroPlatform; (b) compare real integration cost against league/oauth2-server plus Passport for our specific stack, including storage adapters, scope middleware, and revocation; and (c) document exactly what we would own — patch cadence, advisory monitoring, named owner, bus-factor mitigation, and the upgrade path to a full IdP such as Keycloak or Hydra if our needs outgrow this. Decision criterion is 18-month total cost of ownership, not license price. I would rather spend two weeks proving Passport is the answer than two quarters discovering this fork isn't.