- Can I use terehinis/jwt-refresh-token-bundle in a Laravel application?
- No. This is a Symfony bundle that registers a Bundle class, a DI extension, a YAML configuration tree, and Doctrine-mapped entities, and it subscribes to Symfony security firewall and LexikJWTAuthenticationBundle events that Laravel never dispatches. Composer may install it, but nothing in a Laravel app will wire it up or run it. Treat it as a design reference and port the refresh-token logic into a first-party Laravel package instead.
- What does this bundle actually do?
- It adds a long-lived refresh token layer on top of short-lived JWT access tokens issued by LexikJWTAuthenticationBundle. It lets you issue, rotate, and revoke refresh tokens, storing them through Doctrine ORM or ODM with configurable expiration. The goal is persistent user sessions without forcing users to re-authenticate every time the access token expires.
- How do I install it in a Symfony project?
- The standard flow is composer require terehinis/jwt-refresh-token-bundle, register the bundle in config/bundles.php, and configure the refresh token entity, expiration, and firewall settings under the bundle's config key. You then generate and run a Doctrine migration for the refresh_tokens table. Before doing any of that, check the repository's composer.json, license, and commit history, since the project shows no stars, no dependents, and no visible maintainer activity.
- Which Symfony and PHP versions are supported?
- The provided repository information does not state supported Symfony or PHP versions, so inspect composer.json and the CI matrix directly before committing. Symfony bundles of this type typically pin constraints that age out quickly, especially around security-bundle and Doctrine versions. Verify the dependency tree resolves cleanly against your current Symfony LTS before adopting it.
- Does it work with LexikJWTAuthenticationBundle?
- Yes, that is its explicit purpose. The bundle hooks into the Lexik authentication flow and Symfony's security firewall events to attach a refresh token to the login response and to accept one at a refresh endpoint. It is not a standalone JWT implementation, so you still need Lexik configured and issuing access tokens. It also will not work with other JWT libraries without modification.
- How does refresh token rotation and reuse detection work?
- The design intent is single-use rotation: each refresh call invalidates the presented token and returns a new one, and reuse of an already-consumed token should signal theft and revoke the token family. The provided context does not confirm that this fork implements family-level revocation or reuse detection correctly. Audit the rotation routine and the revoke path before trusting it with production sessions.
- Are refresh tokens hashed at rest?
- This is not documented in the available information, and it is the single most important thing to verify. Storing refresh tokens in plaintext means a database read turns into account takeover for every active session. If you port the design to Laravel, generate an opaque cryptographically random token, store only a SHA-256 hash, and put a unique index on that hash.
- Is this package maintained and safe for production?
- The evaluation is unfavorable: zero stars, zero dependents, no listed maintainer activity, and a name that strongly suggests a fork of gesdinet/jwt-refresh-token-bundle without an obvious reason to fork. For security-sensitive rotation code, that raises a governance problem, because you cannot easily answer who absorbs an upstream rotation vulnerability. Ask whether the fork history and license are preserved, what changed versus upstream, and who owns the code internally if you adopt it.
- What are the Laravel alternatives to this bundle?
- Laravel Passport already implements OAuth2 refresh tokens with rotation and revocation on an actively maintained codebase, and Laravel Sanctum covers first-party SPA and mobile sessions with API tokens. Most teams reaching for a JWT refresh bundle actually just need logout to work, which Sanctum handles with far less surface area. Only build custom stateless JWT plus rotating refresh tokens if you specifically need that combination and control of the revocation store.
- How would I port this refresh token design into Laravel?
- The port surface is small: a refresh_tokens table with a hashed token, user id, expiry, revoked flag, and device metadata, plus a unique index on the hash and an index on (user_id, revoked_at). Add a RefreshTokenService with issue, rotate, revoke, and revokeAllForUser methods, a scheduled refresh_tokens:prune command, and controllers for /auth/refresh and /auth/logout. Keep tokens opaque and random rather than JWTs, hash them before storage, and implement reuse detection that revokes the whole token family. That is days of work, not weeks, and it removes the Symfony and Doctrine coupling entirely.