Login Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. avoid for authentication. Auth is a domain where "buy" or "first-party" is usually correct; this package is best used as evidence against adding a dependency and for standardizing on the framework's maintained components. Use it as a clean worked example when setting the minimum bar any auth dependency must clear (maintained, licensed, depended-upon).
• Requirements checklist for a login spec. Reading the bundle's flow (configurable login routes, form handling, user provider integration, session handling) is a cheap way to sanity-check your own requirements list — remember-me, throttling, multi-guard support, redirect handling, account recovery — before you finalize the spec.
• Roadmap framing for auth vs. identity. It helps you draw an explicit in-scope/out-of-scope line: this covers form login only. Authorization, MFA, SSO/OIDC, and account recovery are separate roadmap items with separate decisions.
• Framework-fit decision. The *-bundle naming and Symfony Kernel conventions are a clear signal this is not a Laravel package. Treat "Laravel/PHP package" in intake as two separate categories going forward — this artifact supports that process fix.
• Vendor-risk policy calibration. 1 star, 0 dependents, NOASSERTION license, composite score 0.005. A concrete reference case for adoption thresholds.
• Legacy Symfony triage. If you own an older Symfony service, this may appear in a dependency audit; the assessment supports deciding to replace, vendor, or leave it alone — not to expand its role.

When to Consider This Package

Consider it only in narrow circumstances:

• You are on Symfony (not Laravel) and the bundle's supported Symfony/PHP version range matches yours.
• You want prior art to read, not a runtime dependency — you are writing your own login flow and want a reference implementation.
• You are prepared to vendor or fork it, accept full ownership, and have engineering capacity to maintain and security-review it indefinitely.
• The license is resolved in writing to something compatible with your distribution model (SaaS, commercial, or OSS) — NOASSERTION means GitHub could not map it to a recognized SPDX identifier, which is a blocker by default.
• The scope is genuinely non-critical — an internal tool, prototype, or proof of concept that will never see untrusted traffic.

Look elsewhere when:

• You are on Laravel. Use first-party: Breeze or Jetstream for scaffolding, Fortify for headless login/2FA/throttling, Sanctum for API tokens, Passport for OAuth2, plus Laravel's native hashing, rate limiting, and password reset. These are maintained, documented, widely depended upon, and idiomatic.
• Authentication is security-critical — which it always is in production. One star and zero dependents means no security response path, no CVE advisory coverage, and no community review of the code path that guards everything else.
• You need support, an SLA, or a maintenance guarantee. Zero dependents means effectively nobody else is exercising this code; you will be the first to find its bugs.
• Legal or compliance review is required. An unresolved license is a hard gate for most enterprises and a real risk for any commercial distribution. "Public on GitHub" is not "licensed for use."
• Your adoption bar requires traction signals. This falls below any reasonable threshold for a Tier-0 dependency.

How to Pitch It (Stakeholders)

For executives: We evaluated forci/login-bundle as a candidate for authentication and recommend against adopting it. It has negligible adoption (1 star, 0 dependents), an unresolved license our legal review cannot clear, and no maintenance signal — for login code, that means unbounded security and continuity risk with no support path. Auth is a Tier-0 code path: a defect is either a tenant-wide lockout or an auth bypass, and the cost of a single incident — or a forced mid-quarter migration — far exceeds any build savings. It is also a Symfony bundle, not a Laravel package, so it does not fit our stack. Our recommendation: standardize on the framework's first-party auth components (no license ambiguity, large maintained user base). The one thing worth keeping is the login requirements checklist we derived from reading it — that improves our spec at zero cost.

For engineering: Treat this as prior art, not a dependency. It is a Symfony bundle (-bundle suffix, Symfony Kernel conventions), and Laravel has no seam for it — no service provider, no package discovery, no auth guard driver. Making it work means bridging Symfony Security onto Laravel's AuthManager: dual container, dual session semantics, an adapter layer, and multi-week effort for an unproven component. It is the wrong shape of work.

Do not add it to composer.json, do not vendor it, and do not copy code from it until the license is clarified in writing — NOASSERTION means we have no grant to reuse it. If anyone wants to mine the login flow design, do it in a scratch branch and write down the requirements it surfaces.

For the actual implementation: go with Fortify + Sanctum (or Breeze if we want scaffolding), falling back to a vetted OIDC client if federated identity is the real requirement. Keep the auth surface area small and first-party.

Before any further spend, resolve: (1) the license verbatim and copyright owner — blocking; (2) whether Forci is an internal org or an unrelated third party; (3) the capability gap against Laravel first-party — half a day, TPM plus tech lead; (4) declared PHP/Symfony constraints and the transitive dependency list; (5) any commit or CI activity in the last 12 months. Record the go/no-go as an ADR, and if anyone still doubts the framework mismatch, timebox a 2–3 day spike in a disposable branch to confirm it fails fast.