Jwt Refresh Token Bundle Laravel Package

Product Decisions This Supports

• The session-length vs. security trade-off — the decision this package exists to enable. Refresh-token rotation lets you ship "stay logged in for 30 days" on top of minutes-long access tokens that are actually revocable. As a PM, this is the single most valuable concept here: it removes the forced choice between re-login friction and un-revocable long-lived credentials. The capability is what you're evaluating; the bundle is one implementation of it.
• Revocation as a shippable feature, not a backlog item. Because refresh tokens are persisted server-side, "log out all devices," "sessions" screens, forced re-auth after password change, and immediate de-provisioning of a departing employee all become buildable. These are named requirements in almost every enterprise security questionnaire — having them materially shortens sales cycles for B2B customers.
• Build vs. buy on commodity auth plumbing. Rotation, TTLs, reuse detection, and invalidation are well-understood mechanics. Adopting an implementation converts a 2–4 week build plus permanent security ownership into configuration — if the implementation is trustworthy. The build-vs-buy math here is dominated by maintenance and provenance, not by writing the code.
• Roadmap sequencing for mobile, SPA, and partner API clients. If native apps or third-party API consumers are on the roadmap, refresh tokens are a prerequisite for acceptable UX (no hourly re-login) and for containing token theft (rotation invalidates a stolen chain). This decision gates those roadmap items; it doesn't sit beside them.
• The framework-fit decision, which must be made explicitly and closed. This is a Symfony bundle, not a Laravel package. As a PM, the correct product decision is to record that it is not installable in a Laravel codebase and to route the underlying requirement to Laravel-native tools (Sanctum, Passport, tymon/jwt-auth). Allowing "evaluate this package" to drift into "integrate this package" for a Laravel team burns sprint time on a mismatch that cannot be resolved by configuration.
• A reusable decision record. Framework fit, revocation requirements, and token lifecycle will be re-asked on every new client surface. Capturing the outcome — adopt, extract the pattern, or reject — prevents the same evaluation from being repeated by the next team.

When to Consider This Package

Consider it (as an adoption candidate) only when all of these hold:

• The backend is Symfony, already issuing access tokens via lexik/jwt-authentication-bundle, with a Doctrine-backed persistence layer.
• The requirement is specifically server-side refresh token storage and revocation — device lists, "log out everywhere," admin session kill — not a broader identity mandate.
• You are willing to treat this as an owned internal fork, not a community dependency: 0 stars, 0 dependents, and a zero score mean no production validation and no safety net. That means a pinned version, a vendored copy if necessary, and a named engineer accountable.
• The provenance question is answered first. The description and configuration match gesdinet/jwt-refresh-token-bundle almost verbatim under an unfamiliar vendor namespace, which strongly suggests a private fork or mirror. Diff against upstream and confirm the namespace before assuming you're adopting something distinct. If there's no meaningful divergence, use upstream.

Look elsewhere when:

• The stack is Laravel. This cannot be auto-discovered, booted, or wired into Laravel's container — no service provider, no guard, no facade. Use Sanctum (first-party SPA/mobile, cheapest to operate), Passport (OAuth2-compliant refresh grant), or tymon/jwt-auth (closest conceptual match).
• You need a full OAuth 2.0 / OIDC authorization server — third-party clients, consent screens, scopes, PKCE. A refresh-token bundle is one narrow slice of that; buy or deploy a proper server.
• You need managed identity — SSO, MFA, enterprise directory integration. Buy an IdP; don't grow one from a bundle.
• You need a maintained dependency with CVE response guarantees. With no community, every upstream security fix is a manual cherry-pick. If you can't staff that, prefer upstream or Symfony's stateful session firewall.
• Single-session, short-lived auth is sufficient. A stateful firewall or plain short-lived JWTs may be simpler and cheaper than adding a token table, rotation logic, and a pruning job.

Diligence gates before any commitment: last commit and release cadence; presence of CI and a security contact; test coverage specifically on rotation and invalidation; whether expired-token cleanup exists (an unbounded token table is an operational bug); confirmation of the MIT license as stated; and Symfony/Doctrine version constraints checked against your actual composer matrix.

How to Pitch It (Stakeholders)

For executives: We need revocable, long-lived sessions for our API and mobile clients, and today our access tokens can't be withdrawn once issued — which blocks enterprise security reviews and forces bad UX (frequent re-login) as the only alternative. The refresh-token pattern solves this: short-lived access tokens plus a database-backed refresh token we can revoke at will, which is the industry-standard answer and roughly 2–4 weeks of custom security work we avoid. Two things to flag. First, the specific package surfaced is a Symfony bundle, so if our stack is Laravel we will not use this artifact — we'll use an established Laravel equivalent or take the design as a reference and build it natively. Second, it's a low-visibility fork with no community adoption, so if we do adopt it anywhere, it becomes an owned, pinned internal dependency with a named engineer and a documented fallback to the upstream project. Net: the capability is worth approving; the artifact requires a framework check before we commit.

For engineering: Symfony bundle sitting on Lexik JWT with a Doctrine refresh-token entity — TTL, rotation, invalidation. It is not a Laravel package; do not attempt to install it there, and treat a successful composer require as meaningless evidence of fit. If we're on Symfony: diff against gesdinet, confirm version constraints, and add tests around rotation, reuse detection, and revocation before merge. If we're on Laravel: 1–2 day spike to formally close the question, then choose Sanctum, Passport, or tymon/jwt-auth based on whether we need simple revocation or a real OAuth2 refresh grant. Either way, schedule pruning of expired token rows from day one.

Risk statement to carry into the decision record: the zero score is a supply-chain and governance finding, not a technical one. The capability is standard and low-risk; the provenance is the risk. Pin it, vendor it, name an owner, and keep the upstream migration path open — or avoid the question entirely by using a framework-native alternative.