Weave Code
Security Core Laravel Package
symfony/security-core
Symfony's core security library provides the infrastructure for authentication and authorization: user providers, tokens, voters, role hierarchies, and access decision management, decoupled from your application's actual authorization logic.
Symfony Security Component - Core Library
Frequently asked questions about Security Core
- What is symfony/security-core and can I use it with Laravel?
- It is Symfony's framework-agnostic authorization kernel: authentication tokens, user providers, voters, role hierarchies, AccessDecisionManager, password hashing, and remember-me primitives. It is not a full security stack, since the HTTP firewall, request-based listeners, and DI wiring live in symfony/security-http and symfony/security-bundle. In Laravel you can use its voter and decision-manager subset behind a facade, but you must build the bridge yourself. Laravel already ships a complete competing authorization model, so adopt this package deliberately rather than by default.
- How do I install symfony/security-core in a Laravel application?
- Install it with composer require symfony/security-core and pin a major that matches your PHP version, because 8.x requires PHP 8.4 or newer while the 6.4 and 7.x lines still receive synchronized fixes. The package alone does not wire into Laravel, so you will also need adapter code for user providers, token construction, service registration, and exception mapping. Verify current constraints on Packagist before committing, since supplied package metadata can be unreliable.
- Can symfony/security-core replace Laravel's Gate and policies?
- Not cleanly. It can serve as a framework-neutral policy engine, but Laravel already provides guards, Gate and Policy support, and AuthServiceProvider, and running both creates two authorization sources that can drift apart. That drift is the primary long-term security risk. Replace Laravel auth only if you need pluggable voters, ABAC, or hierarchical roles beyond what Gate::allows() gives you; otherwise a small custom voter layer is usually cheaper and safer.
- Which PHP and Laravel versions are supported by symfony/security-core?
- Support is driven by the Symfony major: 8.x requires PHP 8.4 or newer, while 7.x and 6.4 receive synchronized fixes. There is no official Laravel version support because the package is framework-agnostic, so your bridge must be validated against the Laravel and PHP versions you pin. Confirm the actual Composer constraints on Packagist before making a roadmap commitment.
- How do I connect Laravel's Authenticatable user to Symfony's UserInterface?
- Write an adapter that implements Symfony\Component\Security\Core\User\UserInterface and wraps Illuminate\Contracts\Auth\Authenticatable, exposing getRoles(), getUserIdentifier(), and the password where needed. Symfony 8 removed eraseCredentials() from the interfaces, so the contract differs by major version and your adapter must match the one you pin. Keep the adapter thin and avoid leaking Eloquent models into voter logic if you want the policy layer to remain testable.
- How do I use voters and AccessDecisionManager inside Laravel?
- Register voters such as RoleVoter, RoleHierarchyVoter, and AuthenticatedVoter in a Laravel service provider and bind AccessDecisionManager as a singleton. Build a Symfony token from the current Laravel guard or session state, then call decide($token, $attributes) from middleware, services, or a facade. Keep voter registration in one place so the voter engine stays the single source of truth for those checks.
- How should I handle AccessDeniedException in a Laravel app?
- Do not let Symfony's AccessDeniedException escape unhandled. Map it to Laravel's AuthorizationException or a 403 response in your exception handler or middleware so HTTP behavior stays consistent with Laravel's native authorization failures. Test both Gate denials and voter denials to confirm they produce the same status code and response shape. Without that translation layer, a denied voter can surface as an unhandled Symfony exception.
- Is symfony/security-core safe to use in production with Laravel?
- The library is mature, but production risk comes from your bespoke bridge and from running dual authorization models. Recent upstream fixes touched token and exception unserialize hardening, login-link race narrowing, impersonation de-authentication, lazy-firewall session tracking, and role-hierarchy correctness, which are exactly the failure modes a custom Laravel bridge would not have test coverage for. Avoid persisting tokens into Laravel session or cache unless you are prepared to track security patches closely, and pin a supported Symfony major.
- When should I choose symfony/security-core over Laravel's built-in authorization?
- Choose it when you specifically need hierarchical roles, pluggable voters or ABAC, or reuse of an existing Symfony-oriented dependency, and you are willing to own a permanent bridge. Do not choose it just because Gate::allows() feels limited, since a small custom voter layer usually covers that with far less integration surface. If your product only checks policies against Eloquent models, Laravel's Gate remains the better fit.
- How do I test voters and role hierarchies in a Laravel package?
- Unit-test each voter in isolation with mock tokens and attributes, then test AccessDecisionManager using the same strategy you register in production, whether affirmative, unanimous, or priority. Add integration tests that build tokens from real Laravel guard state and assert the mapped 403 or AuthorizationException behavior. Include regression tests for role hierarchy inheritance and for any serialization path if tokens are stored.
Weaver
How can I help you explore Laravel packages today?