Jwt Refresh Token Bundle Laravel Package

Product Decisions This Supports

• The session-lifetime trade-off, stated as a product bet. This package exists to answer a user-facing question: how long does a user stay signed in, and what do we expose while they are? By pairing short-lived JWTs with a longer-lived, revocable refresh token, "stay signed in on mobile" stops being a security concession and becomes a configurable default you can defend to a security reviewer.
• Mobile and SPA roadmap viability. Native apps and browser front-ends degrade badly under re-login-heavy auth. Refresh-token rotation is the enabling primitive behind the "never log me out" expectation users import from consumer apps — a retention lever, not an infrastructure nicety.
• Build vs. buy on auth plumbing. The real alternative is 2–4 engineer-weeks of rotation, revocation, storage, and replay detection written in-house. This bundle is a candidate to compress that to days — if it clears the vetting below. Treat it as a market signal (opportunity score 4.16 = a genuine ecosystem gap) rather than a finished answer.
• Device management and forced re-auth. A server-side refresh-token record is what makes "sign out all devices," per-device session lists, and forced re-auth after a password change implementable. Roadmap these only once the token store is trustworthy.
• Security-incident posture. TTLs and revocation windows become product-configurable defaults with an owner and a documented rationale, instead of hardcoded constants someone reverse-engineered from old code.
• Use cases that justify the work: long-session consumer apps, multi-device accounts, admin consoles with short idle timeouts but persistent identity, and any surface where biometric/PIN re-entry is on the two-year roadmap.

When to Consider This Package

Framework fit is the first gate — and the framing here is wrong. Despite the "Laravel/PHP" label, this is a Symfony bundle: it depends on Symfony's kernel, DI container, security firewalls, and (by default) Doctrine, and it extends the lexik/jwt-authentication-bundle pattern. It does not drop into a Laravel app. On a Laravel estate, evaluate laravel/sanctum (first-party, token abilities, no JWT ceremony) or laravel/passport (only if OAuth2 is genuinely required) first and stop.

Adoption signals are disqualifying as-is. Zero stars, zero dependents, a composite score of 0, and a name that strongly suggests a re-publish of the well-established gesdinet/jwt-refresh-token-bundle. For code that sits directly on your authentication path, a single-maintainer artifact with no observable security-disclosure process is a supply-chain and bus-factor risk you cannot put on a roadmap. Treat this repository as a pointer, not a dependency: evaluate the upstream original, check its release cadence, CVE history, and Symfony version support.

Consider the category (rotating refresh tokens over JWT) when: you have a Symfony service already using Lexik, mobile/SPA clients, sessions that must outlive the access-token TTL, and a real need for revocation.

Look elsewhere when:

• You need OAuth2/OIDC proper — use league/oauth2-server, or better, delegate to a managed IdP (Auth0, Cognito, Keycloak, WorkOS) and stop owning auth.
• You want opaque tokens with instant server-side revocation — JWT's statelessness actively fights you; plain database-backed tokens are simpler.
• Your team has no appetite to own a fork. Zero dependents means zero community pressure-testing; adopting it makes you the maintainer.
• Compliance (SOC 2, PCI) demands a vendor with a defined security-response process.
• You are Laravel-only. Adopting this means a Symfony sidecar or a 1–3 sprint port. No path here is "install the package."

Bottom line for the roadmap: adopt the pattern, not this artifact.

How to Pitch It (Stakeholders)

To executives: Authentication is a recurring tax on every client we ship. Refresh tokens let us shorten the blast radius of a stolen credential while increasing how long users stay signed in — better security and better retention from a single change. Building it ourselves costs weeks of engineering plus permanent security-review overhead, so the right move is either a maintained open-source implementation or a managed identity provider, not custom code. I'm asking for a funded two-day spike, not a dependency.

To engineering: This specific package is a Symfony bundle with no adoption and no downstream dependents, and it looks like a re-publish of gesdinet/jwt-refresh-token-bundle. I am not asking anyone to depend on it. I'm asking for a spike comparing (a) the upstream gesdinet bundle inside a Symfony service, (b) a managed IdP, and (c) laravel/sanctum or laravel/passport if we're Laravel-first — scored on maintenance health, framework-version support, revocation and replay-detection semantics, and integration effort. If we do proceed with any open-source option, the plan is to wrap it behind internal TokenIssuer/TokenRotator interfaces, vendor the source, and name an owner, so the choice stays reversible.

Decision requested: approve the spike; do not approve this dependency. The capability is worth funding; this artifact is not worth adopting.