Jwt Auth Bundle Laravel Package

Technical Evaluation

Architecture fit — the gate is a framework check, and it fails. This is a Symfony Bundle: it ships a Bundle subclass, a DependencyInjection extension with a config tree, and a Security firewall authenticator factory. There is no ServiceProvider, no guard contract, no middleware alias, no publishes() config. For a Laravel codebase the runtime leverage is zero. The TPM-level conclusion is not "evaluate harder" — it is that the build-vs-buy question was framed against the wrong ecosystem, and the correct output of this evaluation is a decision record closing it, plus a redirect of the engineering time.

What a TPM actually extracts. The artifact of value is a reference design spec, not a dependency: a token-issuer/token-parser service boundary, a claims envelope (sub, iat, nbf, exp, jti plus an application namespace), listener-based validation sequencing, and a configuration surface (secret, algo, ttl, user_provider). That spec is roughly half a day of tech-lead time and costs nothing in licensing or maintenance. It becomes the acceptance criteria for whichever Laravel-native package we do adopt.

Integration feasibility — quantify the delta, don't debate it. A credible port/wrap estimate is 3–5 engineer-weeks (ServiceProvider, custom guard, middleware, mocking Symfony container/event-dispatcher semantics in tests). Compare against laravel/sanctum at well under a day, or tymon/jwt-auth at a day or two. That gap is the headline number for any stakeholder conversation, and it is the benchmark every paid alternative must beat.

Technical risk. Three categories a TPM owns rather than delegates:

• Supply chain / ownership: 0 stars, 0 dependents, no issue history, single maintainer. Adoption means we become the maintainer of every extension point we touch — a permanent line item, not a one-off cost.
• Metadata integrity: the 2026-08-01 last-release date is future-dated. Until verified as a real tag versus an artifact, it must not be allowed to resolve silently through composer update. Treat as a release-engineering control, not a footnote.
• Dependency depth: the bundle wraps firebase/php-jwt. Every JWT CVE in the ecosystem reaches us through a package nobody is patching on our behalf. No CVE monitoring exists unless we create it.

Key questions the TPM must get answered before funding any spike:

1. Is Symfony genuinely in the estate today, or credibly on the 12-month roadmap? If no, close the evaluation.
2. Who is the named owner of the fork, and is that person funded for audit, patching, and upstream tracking?
3. What is our revocation requirement? If "log out everywhere," role demotion, or compromised-token response is in scope, the buy rationale disappears and the requirement must be specced against a native solution.
4. Is the 2026 release date a real tag or a metadata artifact?
5. Do we require refresh-token rotation, OAuth2/OIDC, multi-tenancy, or asymmetric keys (RS256/EdDSA)? None are evidenced here.

Integration Approach

Stack fit: none, and the plan should say so in one line. The Symfony idiom is a request listener/authenticator; Laravel's is a guard plus middleware. The concepts map cleanly; the code does not. Do not schedule a "make it work in Laravel" spike — that is net-new authentication work wearing this bundle's name, and it will be estimated as integration when it is actually greenfield.

The migration path is inverted. There is no path to this package; there is a path away from evaluating it:

1. Week 0 — close the loop. Write a one-page decision record: wrong framework, zero runtime value, reference design retained. Name the redirect target (laravel/sanctum first, tymon/jwt-auth if JWT-specific semantics are a hard requirement).
2. Week 0–1 — harvest the spec. Extract the token service boundary and claims envelope into our own design note. This is the only deliverable that survives.
3. Week 1–2 — native implementation. One POST /auth/token, one protected route, one guard, one config file. Ship a 200 and a 401, then stop.
4. Week 2+ — the requirements this package exposed. Revocation/denylist keyed on jti, refresh rotation in an opaque store we control, clock-skew leeway, algorithm pinning. These are now explicit backlog items rather than mid-sprint discoveries.

Compatibility. The real compatibility axis is Symfony minor version (Security's authenticator model changed materially in 5.3; firewall config shape is version-sensitive), not Laravel. That coupling is a standing upgrade liability with no upstream fix — a reason to avoid it even in a Symfony shop.

Sequencing rule. Auth is the highest-blast-radius component we ship. Nothing in this category enters a lockfile without an owner, a CVE-watch calendar entry, and a documented exit path. If any of those three is missing, the answer is no.

Operational Impact

Maintenance. With 0 stars and 0 dependents we are the de facto upstream. The recurring work is: fork into a path repository with a NOTICE, pin the firebase/php-jwt version, monitor CVEs, and re-audit on every Symfony major. That is an ongoing tax on a component that, in Laravel, delivers no runtime value — the worst possible cost-to-benefit ratio for an auth dependency.

Support. No vendor, no SLA, no issue history, no Stack Overflow corpus. Every edge case is ours to discover and document. For a regulated or customer-facing identity workload this alone is disqualifying.

Scaling. Technically the model is stateless and scales horizontally without ceremony — that is genuinely the best thing about JWT. Operationally it does not scale, because the constraint is people: one maintainer, one fork owner, one person who knows the claim envelope. That is a bus-factor of one on the most security-sensitive path in the product.

Failure modes to write into the risk register:

• Silent bypass — a route that never gets wired to the authenticator returns 200. Mitigation is a CI route-list smoke test asserting 401 without a token on every protected route. Cheap, catches the worst class of bug.
• Algorithm confusion — pinned algorithm only, reject none, never derive from the token header, assert with a test that feeds an alg: none token.
• Clock skew — without 30–60s leeway, distributed services reject valid tokens intermittently; it presents as flaky infrastructure and burns disproportionate incident time.
• Revocation gap — no denylist means a stolen or revoked token works until expiry; decide fail-open vs. fail-closed in writing so the Redis outage behaviour is a decision, not a 2 a.m. discovery.
• Key rotation without kid — rotation becomes a coordinated outage unless overlapping keys are supported.
• Silent metadata resolution — the future-dated tag being pulled in by composer update.

Ramp-up. Reading it for reference value is roughly 30–60 minutes for a senior engineer and is worth doing. Building against it is 3–5 engineer-weeks and is not. The honest ramp-up plan is: one engineer, half a day, produce the spec, close the ticket, redirect the remaining 3–5 weeks to a supported Laravel-native path — which lands in days, not weeks, and carries a maintainer we did not have to fund.