Users Security Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication glue. If identity is being outsourced to SmartAssert's users service, this bundle replaces hand-rolled login/logout, token issuance, and user-provisioning wiring in a Symfony application. That is a genuine "don't build it yourself" saving on a non-differentiating feature.
• Identity architecture: centralized user store vs. per-app auth tables. Adopting this bundle implies a decision to keep users in an external service rather than in local users tables. That decision should be made deliberately — it affects data residency, migration paths, and every downstream service that needs to resolve a user.
• Framework upgrade calendar — new in 12.0. The 12.0 release is a Symfony 8.0 compatibility bump. That makes this package a tether to Symfony's release train: every Symfony major now implies a bundle major, and you cannot take fixes without moving your framework. Any roadmap that plans to stay on a Symfony LTS line for its supported window must assume this bundle lags or forces the upgrade.
• Test infrastructure roadmap. The SmartAssert lineage suggests programmatic/authenticated-session support for functional and integration testing. If test suite reliability is a roadmap priority, this is a candidate for creating authenticated test sessions without driving a real login UI.
• Platform standardization. Relevant when deciding whether the SmartAssert stack becomes a house standard for a Symfony-based service estate, or stays a one-off utility. The 12.0 bump is mild evidence the maintainer intends to track Symfony releases rather than let the package rot — necessary, not sufficient, for a standardization argument.
• Not supported by this package: consumer-facing auth UX, social login, or SSO — see below.

When to Consider This Package

Consider it when:

• You are already committed to (or actively piloting) the SmartAssert users service — this bundle is glue for that platform, not a standalone auth solution.
• Your application is Symfony 8, not Laravel. This was already a Symfony bundle (*Bundle, service-container integration); 12.0 hard-requires symfony 8.0, which means it is now install-adjacent to nothing else. A current Laravel app pins Symfony 7.x components, so Composer will refuse the combination outright. Laravel teams should treat it as a reference implementation, not a dependency — and this release removes the last ambiguity.
• You are prepared to be on Symfony 8 from (or very near) day one of Symfony 8's life. If your platform standard is the previous LTS, 12.0 is not for you and 11.x is where you would sit — an unsupported branch.
• You need a small, MIT-licensed surface that gets wired once and then stays quiet — no custom authorization engine, no role/permission matrix to own.
• You want authenticated sessions for testing or internal tooling and are comfortable with a thin, low-abstraction integration.
• Your team can absorb the integration risk in-house: still 2 stars, still 0 dependents, so there is no community support channel, no third-party tutorials, and no ecosystem of fixes. A new release does not change that.

Look elsewhere when:

• You need battle-tested, broadly supported auth. For Laravel, the default answers are Fortify/Breeze, Sanctum, or Passport. For Symfony, symfony/security-bundle plus league/oauth2-client or an OIDC provider covers standard cases with orders of magnitude more community validation.
• You require SAML, social login, MFA, or enterprise SSO — buy from an identity vendor (Auth0, Cognito, Keycloak, WorkOS) rather than adopting a 2-star bundle.
• You need a supported upgrade path more than one Symfony major wide. 12.0 signals a one-major-at-a-time maintenance model. Verify explicitly whether 11.x still receives security fixes; if not, the bundle's support window is effectively "current Symfony major only," which is a materially harder constraint than most auth dependencies impose.
• Vendor neutrality matters. A bundle tied to a single commercial service creates a soft lock-in; you need a clean seam (an interface or adapter) to swap providers later.
• Your procurement or security review requires evidence of maintenance cadence, security disclosure process, or a support SLA.

Evidence caveats: 12.0 is a positive maintenance signal — a maintainer who ships a Symfony 8 compatibility release within the ecosystem's normal window is at least awake. But a single dependency bump is not a security process, a disclosure policy, or a support commitment, and it adds no users. Read it as "maintained by one person," not "supported." Stars and dependents remain proxies for support risk, not code quality.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, permissively licensed connector that saves us a few weeks of plumbing if we standardize user identity on SmartAssert's users service. The strategic question is not the bundle — it is whether we want a small vendor holding our user records. The latest release raises the entry price slightly: it now targets Symfony 8, so it only fits teams already on or moving to that version, and it ties our framework upgrade timing to a one-person project. The bundle itself is low-cost to trial and low-cost to discard, provided we insist on an abstraction layer so identity can be swapped without a rewrite. It is not a platform bet, and it will not satisfy enterprise security review on its own.

For engineering (the ask): The 12.0 release answers one of our three spike questions and sharpens another. It confirms the supported framework floor (Symfony 8.0) but leaves the supported range open — so treat checking 11.x's support status as part of the spike, not an assumption. Before any code, confirm: (1) which Symfony majors 11.x and 12.x each cover, and whether 11.x still gets security patches after this bump; (2) how tokens are issued, validated, and revoked — unchanged by this release and still unverified; (3) what happens to our data if we walk away. Then timebox a one-to-two-week spike against a non-critical Symfony 8 service only. Wire it behind our own IdentityProvider interface from day one — do not let bundle classes leak into domain code. If we are not on Symfony 8, do not start; park this until we are.

Recommended posture: Evaluate, do not adopt as a standard. 12.0 improves the maintenance signal and worsens the coupling: we now inherit the maintainer's Symfony-major cadence as our own. Low maturity plus vendor coupling plus framework-version coupling means the correct decision today remains a contained proof of concept with an explicit exit path, revisited if the SmartAssert users service becomes a house platform.