Login Bundle Laravel Package

Technical Evaluation

Architecture fit: mismatch, and that mismatch is the primary finding. Intake classified this as a Laravel/PHP package; the artifact is a Symfony bundle. The -bundle suffix, vendor namespace, and Flex-style packaging are Symfony Kernel conventions. Laravel offers no seam for it — no Illuminate\Support\ServiceProvider, no package-discovery entry, no publishable config or migrations, no auth guard driver. Laravel's AuthManager and Symfony's Security component are parallel abstractions with different session, CSRF, firewall, and event semantics. Bridging them means running two kernels and two session models in one process, which we should treat as out of bounds rather than as an integration task to estimate.

Integration feasibility as a dependency: low. The honest estimate is not configuration hours but adapter engineering — a custom guard/provider bridge, session and CSRF reconciliation, and event mapping — spent on a component with no production evidence. As a reference artifact, feasibility is high and cheap: a day of reading yields a requirements checklist (remember-me, throttling, multi-guard, redirect handling) at effectively zero cost and zero licensing exposure, provided we do not copy code.

Technical risk, ranked:

• License — blocking. NOASSERTION means GitHub could not map the repo to a recognized SPDX identifier. Until provenance and terms are confirmed in writing, we have no grant to embed, redistribute, or reuse code. This gates engineering spend, not just release.
• Adoption signal — absent. 1 star, 0 dependents, composite score 0.005. Zero downstream compatibility testing, zero community triage, no production survivors to learn from.
• Supply chain — unmonitored. A low-traffic vendor namespace is a plausible account-takeover or typosquat target, and it will not surface in advisory feeds or SCA tooling keyed to known packages.
• Blast radius — Tier-0. Auth defects resolve to tenant-wide lockout or auth bypass, the two most expensive incident classes we run. Unknown PHP/Symfony constraint ranges and an uninspected transitive graph (likely Doctrine-adjacent) compound this.

Key questions before further spend: (1) What capability does it actually deliver — generic form login, or SSO/SAML/OIDC/magic-link/throttling? (2) Verbatim license and copyright holder — blocking. (3) Is Forci an internal org (do we own this IP?) or an unrelated third party? (4) Declared PHP/Symfony constraints and the full transitive dependency list? (5) Any tests, CI, or commits in the last 12 months? (6) Which Laravel first-party component covers the equivalent requirement — Fortify, Sanctum, Passport, Socialite, or a vetted OIDC client? (7) Has anyone security-reviewed the flow for token handling, session fixation, and replay?

Integration Approach

Stack fit. Assume Laravel 10/11 on PHP 8.2+ with Composer. composer require into a Laravel app is not a supported path and should not go past a disposable spike. The likely outcome is Symfony security packages landing in a Laravel tree, no class collisions, and near-certain conceptual collisions in HTTP kernel, session, and firewall handling.

Options, ranked:

• A — Build native (recommended). Map the capability to Laravel first-party: Fortify for login/2FA/throttling, Socialite for OAuth providers, Sanctum or Passport for tokens, and a vetted OIDC client if the requirement is federated identity. Lower cost, upstream support, idiomatic, reviewable by any Laravel engineer on the team — which matters more for our bus factor than any feature delta.
• B — Fork and vendor. Justified only if Forci is our own IP or we secure explicit rights in writing. Requires freezing upstream, pinning a commit, building a test harness around the auth flow, owning dependency bumps, and recording an ADR.
• C — Isolate as a service. Run it as a standalone Symfony identity broker exposing OIDC/SAML to Laravel. Warranted only if the bundle encapsulates protocol logic we could not rebuild in materially less time. Cost: a network hop on the auth hot path and a second runtime to operate.
• Not recommended: direct Composer integration.

Compatibility gates for any option: PHP constraint, Symfony ^5/^6/^7 support, PSR-4 autoload sanity, and whether Doctrine is a hard dependency — Doctrine and Eloquent coexisting is an avoidable permanent tax.

Sequencing: (1) Legal/license clearance as a hard gate — no engineering spend before it clears. (2) Capability gap analysis against Laravel first-party, half a day, TPM plus tech lead. (3) If doubt persists, a 2–3 day timeboxed spike in a throwaway branch to fail fast on Symfony-in-Laravel. (4) Go/no-go versus build-native, recorded as an ADR. (5) If go: fork, pin, add CI and a harness, name an owner. (6) Pilot behind a feature flag on a non-critical tenant with instant fallback.

The TPM's actual deliverable this quarter is the ADR and the requirements checklist, not a merged dependency.

Operational Impact

Maintenance. Zero upstream SLA. Vendoring means we become the maintainers: security patch review, dependency bumps, and PHP/Symfony upgrade tracking — budget roughly 10–15% of one engineer ongoing for a vendored auth component. Critically, SCA tooling and advisory feeds will not surface vulnerabilities for a package with no advisory coverage, so monitoring must be manual and calendar-driven, which is exactly the kind of commitment that quietly lapses.

Support. No vendor channel, no evidence of issue-tracker responsiveness, and documentation maturity unknown and likely low. All operational knowledge must be written internally, or the bus factor simply transfers from the upstream author to one of our engineers.

Scaling. Auth is low-QPS but high-fanout — every request may validate a session, and any IdP round-trip lands on the hot path. The scaling question is our session/token store and provider latency, not this package. The unassessable risk is its caching and locking behavior under retry storms, which we cannot reason about without reading source we may not have rights to reuse.

Failure modes. Worst case: auth bypass, tenant-wide lockout, session fixation, mis-scoped tokens. Because the code is unvetted, these are undocumented failure modes — discoverable only through a harness, not a README. Mitigations regardless of path: an explicit kill-switch back to the existing auth path, per-tenant flags, and alerting on auth success rate and p95 latency.

Ramp-up. High. No StackOverflow corpus, no community examples, no Laravel-idiomatic patterns to copy. Expect 2–3× the onboarding cost of a supported Laravel package, and that cost recurs with every engineer who touches the flow — a recurring tax on a Tier-0 path, which is the argument that wins this decision in a roadmap review.

Recommendation: do-not-adopt in current form. Re-open only if (a) the license is clarified in writing, (b) provenance and ownership are confirmed, and (c) the capability genuinely cannot be met by Laravel first-party components. Nothing in the signal — 1 star, 0 dependents, 0.005 score — justifies carrying an unmaintained Tier-0 auth dependency. Keep the requirements checklist; drop the dependency.