jwt-auth keeps the tymon JWT guard alive for Laravel and Lumen

A fork taken because the original stopped moving

The repository states its own history in the first substantive section, and it is unusually direct about the reason. It is a fork from the original tymondesigns/jwt-auth, and the maintainers decided to fork and work independently because the original one was not being updated for a long time, and they wanted to keep doing support for the application. That is the whole pitch of the project: not a new idea about token authentication, but continuity of maintenance for an existing API. The package covers JSON Web Token authentication for Laravel and Lumen, and the fact that it is a fork rather than a rewrite is what makes it easy to reason about. The behaviour you rely on is the behaviour the original had, with fixes applied since.

The namespace is the only thing that changes in most codebases

The migration path is the README's main content, and it is short because the API is preserved. The new package uses a different namespace from tymondesigns/jwt-auth but otherwise provides the same API, and the README says that makes migration to this repository fairly easy. The three steps are removing the old package, replacing the namespace in your code, and requiring the new one.

composer remove tymon/jwt-auth
composer require php-open-source-saver/jwt-auth

The namespace strings to substitute are Tymon\JWTAuth on the old side and PHPOpenSourceSaver\JWTAuth on the new one, and the README suggests using the find and replace feature of your IDE, mentioning the Ctrl and Shift and R shortcut. It also warns that an error will appear when removing the old package because it is still in use, and that the error should be ignored, since the removal step happens before the code has been rewritten. In practice the order matters: remove, replace, require, as listed.

The one documented break is a new constructor argument

The notes section admits there are incompatibilities caused by features added in this library, while saying that in most cases this will not hurt you. The exception is if you have implicitly disabled autodiscovery for the original Tymon package, which is the Laravel mechanism for opting a package out of automatic provider registration. The current compatibility break listed is that JWTGuard has a new required constructor parameter, $eventDispatcher, and the README links that parameter to the service provider that constructs it. If your application never instantiates the guard itself, that change is invisible. If you extend the guard or build it by hand in a test, you now have to pass a dispatcher, and that is a real code change. The README also points at a security policy for disclosing security issues, and at a separate documentation site.

The repository is mostly source, with the docs living elsewhere

The top level of the repository tells you where the substance is. There is src/ holding the package code, including the JWTGuard class and a Providers/AbstractServiceProvider.php that wires things up, a config/ directory for the package configuration, tests/ with a phpunit.xml.dist, and a docs/ directory with an mkdocs.yml file, which is the source of the published documentation. The engineering scaffolding is what you would expect from a package that has been maintained continuously: a .php-cs-fixer.dist.php for style, phpstan.neon.dist with a phpstan-baseline.neon, a .codecov.yml for coverage reporting, a CHANGELOG.md, a LICENSE file and a SECURITY.md. A .github/ directory holds the workflow definitions. There is also a README.pr-ar.md, an Arabic translation of the readme, and a top level .editorconfig and .gitattributes. Nothing here is unusual for a well-kept PHP package, and it is a reasonable place to look if you want to see how actively the fork is worked on without reading a single line of the library.

The difference between this package and the original

The comparison with tymondesigns/jwt-auth is the one the project itself invites, and the difference is maintenance rather than design. The original is the package this one was forked from, and by the README's account it had not been updated for a long time, which is what prompted the fork in the first place. That is the entire practical distinction: same API, same guard, same configuration model, but a maintainer applying updates to one of them and not the other. For an application that already depends on the original, this is the alternative that changes the least. The interesting consequence is the one the migration notes hint at, which is that the fork has added features, since new features are the stated reason for the incompatibility, and a fork that only cherry-picked fixes would have had none. What those features are is not described in the repository README, which is where the readthedocs site becomes necessary reading rather than a convenience.

Where a JWT guard is the wrong shape for the job

The limits here are the usual ones for stateless token auth, and the repository does not claim otherwise. A JWT guard issues a token and then trusts it on subsequent requests, which means revocation is not free: without extra bookkeeping in your own code, a token that has been issued stays valid until it expires. If your requirement is immediate logout, or if you need to see and audit active sessions, that is work this package does not do for you, and the README is silent on it. The second limit is audience. This is a Laravel and Lumen package, so a team on another framework gets nothing from it, and the whole surface area is the framework integration, the guard and the configuration. The third limit is the documentation split: the repository README is short and points to laravel-jwt-auth.readthedocs.io for the full documentation, so the repository alone is not enough to evaluate whether the package covers your requirements, particularly around key rotation, token lifetimes and blacklist handling.

Editorial conclusion

jwt-auth suits a Laravel or Lumen application already running the tymondesigns package whose team wants continued upstream fixes without rewriting its auth layer, and the migration is a namespace replacement rather than a redesign. It is the wrong choice for a new project that would rather use a session or Sanctum based approach, since this package is a JWT guard with its own configuration surface, and it is the wrong choice if your application extends the guard class directly, because the new constructor argument is a breaking change in exactly that case. Before switching, check whether you have implicitly disabled package discovery for the original package, look at the changelog for the releases you are skipping, and read the readthedocs documentation rather than relying on the repository README, which is short. The last push was on 2026-08-21, with v2.9.3 released the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PHP-Open-Source-Saver/jwt-auth on GitHub
4. README
5. Releases