Weave Code
Jwt Auth Bundle Laravel Package
auth0/jwt-auth-bundle
Symfony SDK for Auth0 authentication and Management APIs. Supports PHP 8.1+ and Symfony 6.4 LTS, 7, and 8. Install with Composer, then configure your Auth0 domain, Client ID, and Client Secret to add login, callback, and logout handling to your Symfony app.
Symfony SDK for Auth0 Authentication and Management APIs.
Frequently asked questions about Jwt Auth Bundle
- Is auth0/jwt-auth-bundle a Laravel package?
- No. Despite the Composer name, auth0/jwt-auth-bundle (published as auth0/symfony) is a Symfony bundle, Auth0\Symfony\Auth0Bundle, and it ships Symfony-only primitives such as a bundle class, a Flex recipe, config/packages/auth0.yaml, a security.yaml user provider and custom security authenticators. It cannot be installed into a Laravel application without re-platforming. If your stack is Laravel, use the separate auth0/login package instead.
- How do I install the Auth0 SDK in a Symfony application?
- Run composer require auth0/symfony. Symfony Flex should generate config/packages/auth0.yaml and register the bundle; if the config file is missing, create it manually. Then set your Auth0 domain, Client ID and Client Secret as environment variables and add a firewall stanza to security.yaml. You can optionally declare the login, callback and logout routes.
- Which PHP and Symfony versions does auth0/symfony support?
- The requirements list PHP 8.1+ and Symfony 6.4 LTS, 7, or 8. Symfony 8 support is explicitly community-contributed and currently experimental, so do not build an upgrade roadmap on it. The published documentation also contradicts itself in places, including a support-policy note that says LTS versions are not supported. Always verify the real constraints in the package's composer.json rather than trusting the docs for upgrade planning.
- How do I configure the Auth0 domain, Client ID and Client Secret in Symfony?
- Create a Regular Web Application in the Auth0 Dashboard and confirm the Token Endpoint Authentication Method is set to POST. Add your callback and logout URLs under Application URIs. Then reference the credentials as environment variables in config/packages/auth0.yaml, for example %env(trim:string:AUTH0_DOMAIN)%, along with client_id and client_secret, and set cookie_secret to %kernel.secret%. Never commit the literal credentials to that file.
- How does the bundle hook into Symfony's security firewall?
- It provides two custom authenticators that extend rather than fight Symfony's security component. The auth0.authenticator handles stateful browser session flows, while auth0.authorizer validates stateless bearer tokens for APIs. You reference them from a firewall in security.yaml and point the bundle's user provider at your local user records, which keeps browser and API authentication cleanly separated.
- How do I validate Auth0 API access tokens and map scopes to roles in Symfony?
- Use the auth0.authorizer authenticator on your API firewall and configure the expected audiences in auth0.yaml so tokens are checked against the right API identifier. Scopes from the validated token can then be translated into Symfony roles for access control. Budget roughly two to three extra days for this beyond the browser login flow, since the scope naming conventions and role mapping are policy decisions rather than SDK configuration.
- Does the Auth0 Symfony bundle handle logout and backchannel logout?
- Yes. AuthenticationController::logout handles the browser redirect flow, and BackchannelController::handle processes OpenID Connect backchannel logout by validating the logout token. This removes one of the more error-prone parts of an OIDC integration, which developers frequently get wrong when writing it by hand. You still need to declare the routes and register the backchannel logout URL in the Auth0 Dashboard.
- Which cache should I use for Auth0 token caching in Symfony?
- The token_cache and management_token_cache options accept any PSR-6 cache service, for example cache.auth0_token_cache. Note the SDK explicitly does not support Symfony's Cache Contracts adapter type, so wiring cache.app out of habit is a footgun in a modern Symfony app. Define a dedicated PSR-6 service instead and point the config at it.
- Is auth0/symfony production-ready and well maintained?
- It is a first-party Auth0 SDK and the bundle itself is thin glue over auth0/auth0-php, so code quality is not the main concern. The practical risks are external: you depend on a paid hosted identity tenant, and an outage or pricing change becomes a product-level incident. Community surface is low (around 127 stars and 0 dependents), so edge cases fall to you, and the documentation contains inconsistencies and expired support dates that you should verify against the actual release history before quoting them in a decision document.
- What are the alternatives to auth0/symfony?
- If you are on Laravel, use auth0/login or a native Laravel OIDC/Socialite provider instead of this bundle. If you are on Symfony but have not yet chosen an identity provider, compare Auth0 against Keycloak and other OIDC providers before committing, since the SDK is worthless without a tenant. If you only need to validate JWTs issued elsewhere, a lighter bundle such as a JWT authentication package may be a better fit than a full hosted IdP integration.
Weaver
How can I help you explore Laravel packages today?