- What is kleijnweb/jwt-bundle and what problem does it solve?
- kleijnweb/jwt-bundle is a Symfony bundle that adds JSON Web Token authentication to a Symfony application. It supplies a security firewall listener that parses and validates signed tokens, plus token encoding, decoding, and signing-key management. The main problem it solves is stateless API authentication: instead of relying on sessions or cookies, each request carries a signed token that the firewall verifies. This makes it a fit for REST APIs and service-to-service calls where session state is undesirable.
- Does kleijnweb/jwt-bundle work with Laravel?
- No. Despite appearing in Laravel-oriented Composer catalogues, this package is a Symfony bundle that depends on Symfony's security component, firewall listeners, and bundle registration. It has no Laravel service provider, no config publishing via artisan, and no middleware group integration. If you are building on Laravel, use a Laravel-native option such as tymon/jwt-auth or wire firebase/php-jwt or lcobucci/jwt directly into your guard. Treat any evaluation notes that describe this package as a Laravel package as inaccurate.
- How do I install and enable kleijnweb/jwt-bundle?
- Install it with Composer using the package name kleijnweb/jwt-bundle, then register the bundle in your Symfony kernel bundles configuration if your project does not use Symfony Flex auto-registration. After that, add the bundle's JWT configuration under your Symfony config directory and configure the security firewall to use the JWT listener. Because the v1.0.0 release notes contain no changelog or scope statement, verify the exact bundle class name and configuration keys against the package source before wiring it in.
- How does kleijnweb/jwt-bundle integrate with Symfony's security firewall?
- The bundle registers a firewall listener that inspects incoming requests for a token, decodes and validates its signature and claims, and then authenticates the request through Symfony's normal security machinery. Because it plugs into the security component rather than replacing it, access control, role checks, and route protection continue to work as they do for session-based authentication. That also means your firewall configuration, not the bundle, defines which routes are protected and which are public.
- How do I configure signing keys and token validation in kleijnweb/jwt-bundle?
- Signing keys and validation behaviour are configured through the bundle's Symfony configuration rather than in code. Keep the key material in environment variables or a secrets manager and never commit it to the repository, and use a strong, sufficiently long secret for HMAC algorithms or a proper key pair for asymmetric ones. Validation typically covers the signature plus standard claims such as expiry and issuer, so make sure your issuer and audience settings match between the token producer and the firewall configuration. Rotate keys deliberately, since rotating without overlap will invalidate every outstanding token.
- Can I use custom user providers and custom claims with this bundle?
- Yes. The bundle is designed to work with Symfony's user provider system, so you can authenticate token subjects against Doctrine, an in-memory provider, or your own custom provider implementation. Custom claims carried in the token are available through the token and user objects, which lets you map roles or tenant identifiers without an extra lookup. Be careful about putting authoritative authorisation data in the token itself, because claims are only as fresh as the token's lifetime.
- Does kleijnweb/jwt-bundle need sessions or database lookups for authentication?
- The bundle is built for stateless authentication, so no session is created or required to validate a request. Whether a database lookup happens depends on the user provider you configure: a provider that loads users from storage will hit the database per request, while a provider built from the token claims will not. For high-traffic APIs, consider caching user resolution or keeping the token payload sufficient to avoid a query on every call.
- Which Symfony and PHP versions does kleijnweb/jwt-bundle 1.0.0 support?
- The supported Symfony and PHP ranges are declared in the package's composer.json, and that file is the only authoritative source. The published v1.0.0 release notes contain no changelog, no upgrade guide, and no scope statement, so compatibility cannot be confirmed from the release itself. Check the composer.json constraints against your pinned Symfony and PHP versions, and against the rest of your dependency graph, before committing to the package. A narrow constraint on Symfony minor versions becomes an upgrade tax later.
- What changed in kleijnweb/jwt-bundle 1.0.0 and is the public API stable now?
- Reaching 1.0.0 signals a SemVer commitment: breaking changes should from here on arrive only in major releases with a documented migration path. However, the v1.0.0 release notes as published contain no changelog, so it is impossible to tell whether this is a mature package graduating from 0.x or a first public push. Resolve that question, along with maintainer activity and issue response times, before putting the bundle on a committed roadmap. Until then, treat any assessment of its stability as provisional.
- What are the alternatives to kleijnweb/jwt-bundle for JWT authentication?
- For Symfony the most established alternative is LexikJWTAuthenticationBundle, which has a larger user base and more documentation. If you want to avoid a bundle entirely, firebase/php-jwt and lcobucci/jwt are solid lower-level libraries you can wire into a custom Symfony authenticator or guard. On Laravel, tymon/jwt-auth is the conventional choice. Comparing maintenance activity and release cadence across these options is worth doing before you standardise on one.