Weave Code
Jwt Refresh Token Bundle Laravel Package
gesdinet/jwt-refresh-token-bundle
Symfony bundle for managing JWT refresh tokens with LexikJWTAuthenticationBundle. Provides secure refresh token handling, a configurable endpoint, Doctrine ORM/ODM support, and easy integration with Symfony security. Requires PHP 8.2+ and Symfony 6.4/7.2+/8.0+.
JWTRefreshTokenBundle manages refresh tokens with JWT in Symfony applications, building on LexikJWTAuthenticationBundle. It issues long-lived refresh tokens alongside short-lived access tokens, so clients can obtain new JWTs without re-authenticating. Supports Doctrine ORM/ODM and requires PHP 8.2+ with Symfony 6.4, 7.2+ or 8.0+.
- Configurable TTL per refresh token and automatic expiry cleanup
- Token rotation with invalidation of used tokens
- Doctrine ORM and ODM storage support
- Custom user provider and token class support
- Seamless integration with Lexik JWT authentication
Frequently asked questions about Jwt Refresh Token Bundle
- Can I install gesdinet/jwt-refresh-token-bundle in a Laravel application?
- No, not in any usable way. It is a Symfony bundle built explicitly on LexikJWTAuthenticationBundle and the Symfony Security component, and its integration surface is a security firewall key, a container Configuration tree, and EventDispatcher hooks. Composer may resolve the dependency, but none of that wiring exists in Laravel's service providers, auth guards, or middleware. There is no adapter layer and none is planned upstream, because the package's scope is deliberately Symfony JWT authentication.
- Which Laravel and PHP versions does this package support?
- It supports PHP 8.2 or later, but no Laravel version at all. The framework constraints are Symfony 6.4, 7.2 or newer, or 8.0 or newer, and older Symfony releases require the 1.x line. The PHP 8.2 floor happens to match modern Laravel, but the Symfony constraints are a hard architectural blocker rather than a version mismatch. Do not treat the PHP requirement as evidence of Laravel compatibility.
- Does it work alongside tymon/jwt-auth or Laravel Sanctum?
- No. The bundle hard-requires LexikJWTAuthenticationBundle to issue the access tokens that its refresh tokens extend, and that dependency conflicts with tymon/jwt-auth, Sanctum, and Passport. The refresh token it stores is tied to Lexik's token payload and user provider, so swapping in a Laravel access-token mechanism means rewriting the bundle anyway. Decide which access-token library you are standardizing on before considering any port.
- What are the alternatives for JWT refresh tokens in Laravel?
- For a Laravel-native setup, the common choices are tymon/jwt-auth with a hand-rolled refresh token table, Laravel Sanctum's personal access tokens with expiry, or Laravel Passport if you need full OAuth2 refresh grants. Sanctum is usually the least work for first-party SPAs and mobile apps, while Passport fits third-party API consumers. gesdinet/jwt-refresh-token-bundle is only meaningful alongside Lexik, which you would not be using in Laravel.
- Is this bundle a good reference for building my own Laravel refresh tokens?
- Yes, that is its main value to a Laravel team. Its semantics are small and well documented: an opaque refresh token persisted per user, a TTL with optional ttl_update on use, rotation, a single_use flag, logout invalidation, and an optional HttpOnly cookie. Treat it as a behavioral spec and reimplement those rules on top of Eloquent plus whichever access-token library you already use. Trying to bridge Symfony's security factory and Doctrine contract into Laravel means writing the port anyway, with extra indirection.
- Does it support Eloquent, or only Doctrine?
- Only Doctrine ORM or ODM, or a custom ObjectManager implementation. Eloquent is not supported, and the bundle auto-maps its refresh token entity through Doctrine metadata. In a Laravel port you would replace that with an Eloquent model, a migration with a unique token column and expiry index, and a relationship to your user model. The Doctrine-specific persistence layer is the part that transfers least.
- How does single_use refresh token rotation work, and does it detect token reuse?
- With rotation enabled, each successful refresh issues a new refresh token, and single_use invalidates the presented one so it cannot be replayed. What it does not provide is a token-family or reuse-detection model, so a stolen token rotated before the legitimate client presents it is not automatically flagged as a breach. If you need that protection in a Laravel port, add a family identifier or parent_id column and revoke the whole chain on reuse. Budget roughly thirty percent more effort for the schema and revocation logic.
- Should the refresh token be returned in the JSON body or set as an HttpOnly cookie?
- The bundle supports both, and the choice is a client concern rather than a bundle feature. Body delivery suits mobile and native clients, while cookie mode is aimed at browser SPAs and defaults to http_only true, secure true, and same_site lax. Cookie mode shifts CSRF protection responsibility onto your application, so plan for token-based CSRF handling and correct same-site configuration. This is the same decision you would make in a Laravel implementation.
- How do I invalidate refresh tokens on logout and clean up expired ones?
- The bundle hooks Symfony's LogoutEvent through the EventDispatcher to invalidate the stored refresh token. In a Laravel port, do the equivalent in your logout controller or middleware by deleting or revoking the token record for that user. Separately, nothing cleans up expired rows automatically, so schedule a pruning command or job on your own. The bundle also ships no brute-force throttling on the refresh endpoint, so add rate limiting in Laravel before exposing it publicly.
- Is gesdinet/jwt-refresh-token-bundle actively maintained and safe to depend on?
- The engineering hygiene looks healthy: a test workflow badge, PHPStan at level 10, Rector, a CHANGELOG, and tagged releases under an MIT license with no legal friction. The repository owner markitosgv differs from the gesdinet vendor namespace, which suggests an ownership handoff and a real single-maintainer risk; the MIT license and small surface area mean a fork stays viable. Treat the popularity signals as unverified, since 713 stars with zero listed dependents is unusual, and confirm the reported 2026-08-05 release date against Packagist before it informs any build-versus-buy decision.
Weaver
How can I help you explore Laravel packages today?