Oauth Server Bundle Laravel Package

Technical Evaluation

Architecture fit — does not fit the stated stack, and that is the first finding. mapado/oauth-server-bundle is a Symfony Bundle, not a framework-agnostic PHP library. It depends on Symfony's kernel bootstrap, service container compilation, event dispatcher, routing loader, security firewall, and Doctrine ORM mappings. A Laravel application exposes none of those extension points, and there is no adapter shim worth commissioning: reimplementing the container and firewall integration is effectively the whole package. For a TPM, this means the "integration" workstream has no engineering path — the only valid output of an investigation is a documented no-go, not a reduced scope.

Provenance — a fork of a retired upstream. The repository resolves to mapado/FOSOAuthServerBundle, a fork of the long-deprecated FriendsOfSymfony bundle, which sits on the end-of-life bshaffer/oauth2-server-php lineage. The maintained successor is league/oauth2-server (and, on Symfony, league/oauth2-server-bundle; on Laravel, Passport, which wraps the same library). Whatever divergence Mapado introduced is undocumented from the outside — no changelog, no diff audit, no compatibility matrix.

Adoption signal — zero. 0 stars, 0 dependents, score 0. For an authorization server — the component that issues and validates the credentials gating the entire API surface — zero external consumers means zero third-party review, zero incidental bug reports, and no community pressure to patch. Treat this as a supply-chain risk indicator, not a quality verdict: composer audit will not surface advisories for a package nobody exercises.

Integration feasibility — not feasible as scoped. Not "hard," not "high effort" — not feasible without replacing the framework or replacing the package. Effort to reach parity with a Laravel-native option exceeds building on league/oauth2-server directly, and the outcome would be a fork of a fork.

Technical risk — high and asymmetric. OAuth2 server defects are security defects: token leakage, scope escalation, redirect-URI validation gaps, PKCE bypass, refresh-token replay. An unmaintained fork of an abandoned bundle has no CVE response path. The downside is a breach with unbounded exposure time; the upside is code reuse available from a maintained library in days.

Key questions to put to the requesting engineer (and record the answers in the decision log):

1. Is the target application Laravel or Symfony? The package choice and the stack in the brief are inconsistent, and that inconsistency alone blocks a decision.
2. What does this fork change relative to upstream FOSOAuthServerBundle? Is there a diff audit, and is it published?
3. Is there a named maintainer at Mapado, and is there a commit in the last 12 months?
4. Is the requirement "OAuth2 authorization server," "OIDC," or "a fork we can vendor"? These are three different decisions with three different answers.
5. Do tokens or client registrations already exist under this server? If yes, that is a migration constraint with a refresh-token-lifetime tail; if no, there is nothing to sequence.
6. Why is Laravel Passport (or league/oauth2-server / Keycloak) not the answer? Force the comparison explicitly.

Integration Approach

Stack fit — none. Laravel's auth surface is Illuminate\Auth, guards, middleware, and Laravel\Passport. A Symfony Bundle cannot register routes, services, or listeners there. Do not fund an adapter spike beyond a one-day timebox whose only acceptable output is "confirmed incompatible."

Recommended path — replace, do not integrate.

• Laravel app: Laravel Passport for a full OAuth2 server; Sanctum for first-party SPA/mobile tokens; league/oauth2-server directly if you need non-Eloquent storage or custom grants. All first-party, maintained, free.
• Symfony app: league/oauth2-server-bundle. Do not adopt this fork.
• Mixed estate: a standalone authorization service (league-based, Keycloak, or a managed IdP) behind a shared boundary is cleaner than coupling the auth server to either framework's runtime — and it decouples the auth roadmap from framework upgrade cycles.

Migration path if tokens already exist (the only scenario where this package is even in scope):

1. Inventory issued clients, scopes, grant types, refresh tokens, and the PHP/Symfony versions currently pinned.
2. Stand up the replacement in parallel; dual-issue and dual-validate behind a routing flag.
3. Migrate client registrations and secrets; re-consent users only where scopes diverge.
4. Drain refresh-token lifetime, then decommission. Budget the full refresh-token TTL as the cutover tail — this is the schedule item most often missed.
5. Decommission the fork; remove from composer.json and from the audit trail.

Compatibility. No PHP, Laravel, or Symfony version statement is defensible for this package — it is versioned against a Symfony generation Laravel never used. The Doctrine entity mappings are the only portable artifact, and they encode a schema you would redesign anyway; treat them as documentation, not as a starting point.

Sequencing and gates.

• Gate 0 — Decision record. Capture stack, requirement, alternatives considered, and decision. One page.
• Gate 1 — Disposition. Confirm target framework. If Laravel → reject and close; the decision is over before any engineering time is spent.
• Gate 2 — If Symfony and a pinned blocker genuinely exists: timeboxed fork evaluation against a documented migration date.
• Gate 3 — Replacement epic. Passport/league migration, dual-run, cutover, decommission.

The TPM's leverage here is the first two gates — they cost hours and prevent a sprint of wasted work.

Operational Impact

Maintenance — fully owned by you. No upstream to consume patches from. Every advisory in symfony/*, doctrine/*, guzzle/*, or PHP itself becomes an internal fork-maintenance task. The staffing statement is not "monitor releases" but "own the package," which for a security boundary means a named engineer with audit responsibility and time allocated in each planning cycle.

Support — absent. No maintainer SLA, no issue triage, no release cadence. The escalation path for a production auth incident is reading the source. If Mapado is an internal or partner org, that relationship is the entire support contract — and it is undocumented here. Get it in writing or assume there is none.

Scaling — not the bottleneck, but the storage layer is. Token issuance is low-QPS relative to API traffic; the scaling concern is validation, which sits on the hot path of every authenticated request. Database-backed token lookup should be paired with a cache or self-contained (JWT-style) validation plus a revocation list, and the token table needs retention/cleanup jobs sized before launch. Whatever you choose, this cost is identical — it is not a reason to pick this package.

Failure modes (risk register entries):

• Silent security drift — a dependency CVE lands, nobody is watching, exposure is unbounded in time. Highest severity, lowest visibility. Mitigation: owner + scheduled review, or don't ship it.
• Transitive-dependency breakage — a symfony/* major bump makes the bundle unloadable; the upgrade stalls with no upstream fix, blocking an unrelated platform upgrade.
• Bus factor — the fork's author leaves; institutional knowledge of the divergence leaves with them.
• Sunk-cost trap — an engineer spends a sprint proving the Laravel integration doesn't work, and still needs Passport. Name this upfront so the timebox is enforceable.
• Dead-schema lock-in — Doctrine entity mappings become de facto data contracts, turning the eventual replacement into a data migration rather than a config change.

Ramp-up — inverted. This package demands Symfony container and bundle expertise the Laravel team does not have and should not acquire for this purpose. The replacement path (Passport/league) uses skills the team already holds: ramp-up measured in days versus weeks with a negative outcome.

Recommendation: reject for a Laravel codebase under any framing. The TPM-appropriate artifacts are: a closed decision record stating "not applicable — wrong framework, retired upstream, no adoption signal"; an approved alternative (Passport for OAuth2 server, Sanctum for first-party tokens, Keycloak or a managed IdP if the requirement is vendor-supported identity); and a standing review trigger — revisit only if Mapado publishes a documented divergence, a named maintainer, an active commit history, and a reason the maintained ecosystem options don't apply. None of that is present in the current metadata.

Success criteria if, exceptionally, it is adopted for a Symfony estate: a named internal owner, a published patch set diffed against upstream, a quarterly upstream review, and a dated migration ticket. Absent those four, the decision is no.