Jwt Refresh Token Bundle Laravel Package

Technical Evaluation

Architecture fit. The framing says Laravel/PHP, but the artifact is unambiguously a Symfony bundle. It assumes Symfony's kernel/bundle registration, DI container, security firewall ordering, and typically Doctrine for the refresh-token store, and it sits on top of lexik/jwt-authentication-bundle. Against a Laravel codebase, architecture fit is poor to none — there is no service provider, no config/*.php publish path, no middleware group to slot into. The TPM decision is therefore not "do we install this?" but a two-part question: (a) is there a Symfony service in scope where this pattern legitimately applies, and (b) if not, is this artifact useful only as a reference implementation for a Laravel-native build (Sanctum/Passport plus a custom refresh-token table)?

Integration feasibility. In Symfony, with Lexik already present, this is days: composer require, register the bundle, add the refresh-token entity and migration, wire the firewall and token endpoint. In Laravel, every path is a project, not an install — a Symfony auth sidecar, a port of rotation logic onto tymon/jwt-auth or Sanctum, or a straight replacement with Passport/Sanctum. Budget 1–3 sprints for any of those; none is "adopt the package."

Technical risk. High, and driven by maturity signals rather than line-level code quality: zero stars, zero dependents, composite score 0, single-maintainer appearance. For security-critical code — refresh-token rotation, replay/reuse detection, revocation, signing-key interaction — an unaudited artifact with no observable security disclosure process is a poor dependency of record. The name strongly implies a re-publish of the well-known gesdinet/jwt-refresh-token-bundle (or an older markitosgv fork); that needs confirming before any further spend. The opportunity score (4.16) reads to me as evidence the category matters, not that this artifact earns the slot.

Key questions.

• Is this a fork of gesdinet/jwt-refresh-token-bundle or markitosgv/JWTRefreshTokenBundle, and what exactly changed?
• What are the pinned constraints in composer.json — PHP, Symfony major, Lexik major, Doctrine DBAL/ORM?
• Does it implement rotation with reuse detection, or only issuance plus a sliding TTL?
• Is there a revocation/blacklist path, and does it survive signing-key rotation and clock skew?
• Is Doctrine ORM required, or is a custom storage adapter supported?
• License and security contact — who do we call at 2am?
• Is there any CI, test suite, or static analysis, or is "works on the author's app" the entire evidence base?

Integration Approach

Stack fit. Treat this strictly as a Symfony-ecosystem artifact. If the estate is Laravel-first, the default recommendation is Sanctum (first-party, token abilities, no JWT ceremony) or Passport (only if OAuth2 grants are genuinely required). Pull this bundle into scope only where a Symfony service already exists and already uses Lexik — a realistic scenario in a polyglot estate, and the one case where the effort math flips in its favor.

Migration path. Do not adopt as a top-level dependency at the app level. Instead: vendor or fork the source, extract the refresh-token entity and rotation service behind internal TokenIssuer / TokenRotator / TokenRevoker interfaces, and own the implementation. That converts an unmaintained dependency into an internal component with a known surface area, and keeps the door open to swap in Sanctum/Passport later without touching call sites.

Compatibility. Prove the constraint set resolves against the target app's existing lockfile before committing. The zero-dependents signal means nobody has exercised these version claims against real Symfony/Lexik/Doctrine matrices; treat composer.json as aspiration until a spike proves it. Watch for transitive conflicts with Lexik major versions and Doctrine migrations already in flight.

Sequencing.

1. Confirm provenance (fork of what?) and read the source — rotation, reuse detection, revocation, timing behaviour.
2. Spike in an isolated Symfony service, not the main app: issue → refresh → replay → revoke → key-rotate, end to end.
3. Make the call: fork-and-own, reference-only, or reject.
4. If proceeding, wrap behind internal interfaces and add contract tests around the refresh endpoint.
5. Security review / pen-test of the refresh endpoint and the DB write path before rollout.
6. If the estate is Laravel-only: run the Sanctum/Passport evaluation in parallel, and only revisit this bundle if a Symfony component is confirmed in scope.

Operational Impact

Maintenance. Bus factor is effectively one, and unverified. Plan to own it: pin the version, vendor the source, assign a named internal owner, and assume upstream security patches will not arrive. If the decision is fork-and-own, put the ongoing ownership cost on the roadmap as a line item rather than burying it in integration.

Support. No vendor, no community, no meaningful issue-tracker signal. Internal on-call absorbs refresh-token failures. Before launch, write runbooks for at least: "refresh endpoint 401 spike," "revoked token still accepted," and "mass refresh failure after key rotation."

Scaling. JWT validation stays stateless, but the refresh path is stateful: every issuance and every rotation is a DB write. Expect table growth proportional to active sessions plus rotation churn, and plan indexes and an expired-token reaper from day one. The database — not the crypto — is the scaling bottleneck, and it's the piece this bundle leaves least opinionated.

Failure modes.

• Rotation not enforced or reuse not detected → silent replay acceptance; the whole reason to use refresh tokens evaporates.
• Revocation not checked on the refresh path → compromised tokens outlive logout and password change.
• Signing-key rotation without invalidating refresh tokens → mass 401s across every client at once.
• Doctrine migration drift between environments → missing or mis-typed token table.
• Bundle not registered, or firewall ordering wrong → either hard auth failure or, worse, a bypass.
• Clock skew between issuers → intermittent, hard-to-reproduce refresh rejections.
• Single-maintainer abandonment mid-quarter → you inherit an unowned security component.

Ramp-up. A Laravel-centric team needs Symfony security and DI fluency before this is safe to operate; estimate one to two sprints for spike plus hardening to production-safe, and add recurring ownership cost separately. If the team cannot name who owns auth internals after this ships, that is the strongest signal to choose a managed IdP or a first-party Laravel package instead.