Weave Code
Laravel Jwt Laravel Package
stechstudio/laravel-jwt
JWT authentication for Laravel: issue and validate JSON Web Tokens, authenticate API requests with middleware, and configure custom claims and token lifetimes. A lightweight package for securing Laravel APIs without sessions.
Helper package that makes it easy to generate, consume, and protect routes with JWT tokens in Laravel
Frequently asked questions about Laravel Jwt
- How do I install stechstudio/laravel-jwt in a Laravel app?
- Install the package with Composer using composer require stechstudio/laravel-jwt. Laravel's package auto-discovery registers the service provider and JWT facade, so you can start issuing tokens without manual wiring. Before installing, confirm your application runs PHP 8.2 or newer and Laravel 11 or newer, since those are the supported platform versions for the current release. If your app still uses lcobucci/jwt v4 directly, review the v5 upgrade guide as part of the same change.
- Which Laravel and PHP versions does laravel-jwt support?
- Version 3 supports PHP 8.2+ and Laravel 11, 12, and 13. Laravel 8, 9, and 10 and PHP 8.1 are not supported by this release, so legacy applications should complete their platform upgrade before adopting it. Laravel 13 support is forward-looking, which reduces future upgrade pressure once you are on the 11+ line.
- How do I protect API routes with JWT middleware in Laravel?
- The package ships middleware that validates the incoming JWT and rejects requests with missing, malformed, or expired tokens before they reach your controller. You attach it to route groups or individual routes in your routes/api.php file, just like any other Laravel middleware. Invalid tokens surface through the package's exception classes, which you can render into consistent JSON error responses. Because the middleware and exception API are unchanged in version 3, existing route definitions keep working after upgrade.
- How do I issue a JWT with custom claims using the facade?
- Tokens are generated through the package facade, which lets you build a payload and attach your own claims before signing. Custom claims are typically used for user identifiers, roles, scopes, or tenant keys that your middleware and controllers later read. The public facade API is unchanged in version 3, so existing token-issuance code should not need edits. Keep claims small and avoid putting secrets in the payload, since JWT contents are readable by the client.
- How do I configure JWT token lifetime and the signing algorithm?
- Token lifetime and signing behavior are controlled through the package configuration file, with the signer read from config('jwt.signer'). Set the same signer value in every environment so staging and production issue interchangeable tokens, and verify it explicitly rather than relying on defaults. If your services share tokens across applications, coordinate the signer and key material before rollout.
- Does this package support RS256, ECDSA, or other non-HMAC signers?
- Yes. It supports asymmetric algorithms such as RSA and ECDSA alongside HMAC signers, which is why the signer configuration matters so much. Version 3 fixes a signer-validation bug, so non-HMAC tokens are now validated against the correct algorithm. That fix is correct but may expose previously hidden misconfigurations, so test your RSA and ECDSA paths on staging before deploying. Confirm the private and public keys are present and correctly paired in each environment.
- How do I read and validate an incoming token inside a controller?
- After the middleware runs, you can access the parsed token through the package's ParsedToken object and request macros rather than decoding the raw header yourself. ParsedToken exposes helpers for reading claims and checking the token's validity, and the exception classes cover failure cases. These interfaces are unchanged in version 3, so existing controller code should continue to work after the dependency upgrade.
- Is laravel-jwt a good alternative to Sanctum or Passport for API authentication?
- It is a good fit when you want stateless, self-contained tokens without sessions and without the OAuth2 machinery Passport brings. Sanctum is often simpler for first-party SPA and mobile clients, while this package suits service-to-service or API-first architectures where a signed token carries the claims you need. It is a lightweight layer over lcobucci/jwt rather than a full identity platform, so you remain responsible for login, refresh policy, and key management.
- How should I test JWT authentication flows in Laravel?
- Write feature tests that cover token issuance, middleware enforcement, request macros, ParsedToken access, and exception paths for each signer you actually use in production. Generate tokens through the facade in tests so you exercise the same code path as production rather than hand-crafting strings. Include expiry and malformed-token cases, since those are the failures your API clients will hit most often. If you use both HMAC and asymmetric signers, test both rather than assuming one covers the other.
- What breaks when upgrading from version 2 to version 3?
- The breaking changes are platform-level: version 3 requires PHP 8.2+ and Laravel 11+, and moves to lcobucci/jwt v5 with an explicit lcobucci/clock dependency. The package's own public API, including facades, middleware, request macros, ParsedToken, and exception classes, is unchanged. The most likely source of breakage is application code that references lcobucci/jwt v4 classes directly, so update imports, types, and exception handling per the v5 upgrade guide. Upgrade PHP and Laravel first, then the package, then verify the signer configuration and run regression tests before deploying.
Weaver
How can I help you explore Laravel packages today?