Symfony Authenticator Restrictor Bundle Laravel Package

Product Decisions This Supports

• Firewall topology: one firewall with scoped authenticators vs. firewall sprawl. The default answer to "this login method must only be live on /api" is to split the Symfony firewall by route pattern. That's a heavyweight architectural commitment — split firewalls duplicate context, remember_me, logout, and access-control config, and break shared sessions across them. This bundle reframes the decision as "keep one firewall, scope the authenticator by route." That reframing — not the code — is the primary thing worth evaluating.
• Incremental auth modernization on the roadmap. Adding passkeys, OAuth2/OIDC, or machine-token auth alongside a legacy form login is normally a big-bang cutover behind one firewall. Route-scoped authenticators let you ship the new mechanism on /app while /legacy keeps the old one. If a roadmap item is "modernize sign-in," this is a genuine de-risking lever that shortens the migration window and reduces the rollback surface.
• Triaging a recurring defect class. Multiple authenticators in one firewall means every authenticator sees every request. JSON-login authenticators that short-circuit on POST, or token authenticators that throw on non-API paths, generate bugs that present as routing problems but are actually authenticator-ordering problems. If support tickets or QA cycles are being burned here, this is a narrow-blast-radius fix.
• Build vs. buy — and here the recommendation leans "build." The capability is small: a request matcher plus an AuthenticatorInterface decorator, plausibly under ~100 lines. Against 0 stars, 0 dependents, and no visible release or maintenance signal, "buy" really means "vendor an unmaintained dependency into the authentication path." A PM should treat the pattern as the deliverable and the package as a reference implementation to read.
• Supply-chain and compliance review scoping. Any dependency inside the auth chain triggers security review regardless of size. Knowing that up front determines whether you spend review budget here or on a first-party decorator your team owns outright.

One decision this does not support: anything on a Laravel codebase. Despite being a PHP package, this is a Symfony bundle that hooks the post-5.3 AuthenticatorInterface pipeline. Laravel's guard drivers, auth:<guard> middleware, and per-route-group selection already express this constraint declaratively. For a Laravel-first portfolio, the correct product decision is "note the pattern, do not adopt."

When to Consider This Package

Consider it only when all of the following hold:

• The target service is Symfony, not Laravel. Gate on framework first; if the stack is Laravel, stop here and use per-guard route groups with auth:<guard> middleware.
• You have multiple authenticators inside a single firewall and need per-route scoping that native options can't express.
• Native mechanisms are genuinely insufficient — firewall pattern, a custom RequestMatcher, entry_point, security.access_control, or per-route IS_AUTHENTICATED_* rules don't cover the constraint, and expressing it natively forces a firewall split you don't want.
• You're willing to pin the exact version, audit the source in full, and own a fork if upstream goes quiet.

Look elsewhere or solve in-house when:

• A firewall pattern or a custom RequestMatcher already solves it. Prefer native config every time — supported, documented, survives upgrades.
• You need support, SLAs, or audit-grade provenance. Zero stars, zero dependents, unproven maintainer record, and no advisory channel are disqualifying for a regulated auth path unless you fork and own it.
• Symfony version compatibility is unverified. Auth internals churn across majors (lazy firewalls, authenticator deprecations in 6.x/7.x). Confirm the declared constraints target your LTS before it enters a design doc.
• No concrete route exists where an authenticator must be suppressed today. Without a real case, this is a solution in search of a problem — defer.
• Engineering can't get half a day to review ~100 lines. If you can't review it, you can't responsibly depend on it — and can't responsibly copy it either, which collapses the decision to "native config only."

How to Pitch It (Stakeholders)

For executives. We have a recurring class of problem where our login mechanisms interfere with each other, because Symfony applies every configured authenticator to every request in a firewall. The clean native fix is splitting our security configuration into separate firewalls — a costly refactor that duplicates config and breaks shared sessions. A small community bundle offers a narrower option: keep one firewall, scope each login mechanism to the routes it belongs to. That would let us add modern sign-in (passkeys, SSO) to new pages without a big-bang migration and without touching legacy routes. Recommendation: treat the technique as the valuable part, not the artifact. Have engineering spend roughly a day implementing the decorator first-party rather than pulling a dependency with no users and no maintenance track record into our authentication path. If we do adopt, pin it, review the source, assign an owner, and log the fork plan as a known risk.

For engineering. It's a Symfony bundle — not a Laravel package — that constrains which authenticators run on which routes within a firewall. Mechanically it's a DI extension plus a compiler pass that decorates authenticator service definitions with a request matcher: small surface area, low functional risk, but it sits in the highest-consequence code path we have and is unmaintained by any external signal (0 stars, 0 dependents, unknown CI, bus factor of one). Suggested path: read the source, prototype the decorator behind a feature flag, and only take the dependency if our version proves worse than theirs. Before any adoption, answer: what exactly is matched (route name vs. path regex vs. compound), and what happens when nothing matches — suppression or permission? Test the negative case explicitly, since an auth bypass or a lockout both stem from getting the unmatched default wrong. Then pin the exact version, add an integration matrix across every authenticator × route pair, and register the fork plan in the risk log. Realistic ongoing cost is a few hours a year, spiking to a day or two at each Symfony major upgrade.