Auth Laravel Package

Technical Evaluation

Architecture fit. delight-im/auth is not a Laravel package despite the framing — it is a framework-agnostic PHP authentication library. It ships as a small set of classes (Auth, Database, Mailer, Random) that consume PDO directly and read request context from superglobals ($_POST, $_SERVER). There is no service provider, facade, config file, Eloquent model, event, or PSR-3/PSR-7 compliance. Any Laravel adoption therefore means writing and owning an adapter layer — the library supplies the domain logic (registration, login, verification, password reset, "remember me", throttling) but not the framework contract. Fit is strongest in plain-PHP or legacy codebases that already have no framework; fit is weakest in an idiomatic Laravel application.

Integration feasibility. Technically feasible in a 1–2 day spike: install via Composer, import the bundled SQL schema (users, users_confirmations, users_remembered, users_throttling), point it at the Laravel PDO connection, and wrap it in a singleton binding plus controller routes. The real feasibility question is not "can we wire it" but "should we own the seam." Known friction points: the library assumes it controls the user table (conflicts with an existing users table or table-prefix conventions), assumes its own column names, and defaults to PHP's mail(), so a real mailer override is mandatory for deliverability and queueing. Localization and message customization are available but non-standard.

Technical risk. Moderate-to-high for a platform dependency, driven less by code quality than by ownership economics:

• Maintainer concentration. Single-maintainer project, low release cadence, and 1,244 stars with 0 dependents — negligible ecosystem validation and no downstream community to absorb or signal breakage.
• Runtime drift. The library predates current PHP releases; PHP 8.2/8.3 deprecation behavior (nullability, dynamic properties, strict signatures) needs explicit verification before it can be declared supported. This is a recurring tax, not a one-time check.
• Global-state coupling. Superglobal reads and a monolithic Auth class make unit testing and request-context isolation awkward; expected coverage will be integration-level at best.
• Security surface you inherit. Throttling, timing-safe comparison, and reset-token handling exist, but the package provides no security advisory feed, CVE process, or disclosure channel. Your team becomes the de facto security owner.
• Capability gaps for a modern product. No MFA/TOTP, no OAuth/SSO, no passkeys, no scoped API tokens, no audit log, no multi-tenancy model. Each is a future build, not a config flag.

Key questions.

1. Is the target system genuinely framework-agnostic (plain PHP, Slim, legacy), or is this a Laravel app where Breeze/Fortify/Jetstream is the lower-risk default?
2. What is the fully loaded cost of the adapter layer, the schema fork, and the annual PHP-version revalidation — versus a maintained first-party alternative?
3. Who owns security patching when the upstream maintainer is unresponsive? What is the SLA and the fork-in-place plan?
4. Do current or 12-month roadmap requirements include MFA, SSO, passkeys, or multi-tenant identity? If yes, the TCO gap widens sharply.
5. What does the data migration off this schema look like if we later adopt Laravel's native auth or an external IdP — are hashes portable?

Verdict for planning purposes: viable as a bounded, self-owned component in a non-Laravel PHP service; not viable as a strategic identity platform. Treat the 25/100 opportunity score as consistent with "narrow fit, high ownership burden."

Integration Approach

Stack fit. Confirm the actual runtime first. If the host application is Laravel 10/11, the recommended path is Laravel's native auth stack plus Fortify for headless/API cases; delight-im/auth should be reserved for a non-Laravel service, a polyglot monolith, or a short-lived internal tool where speed beats longevity. If the decision is to proceed anyway, scope it as an adapter-owned dependency: the library sits behind an internal IdentityService interface so application code never references Auth directly. That single design choice preserves the exit option and is the highest-leverage thing a TPM can mandate here.

Migration path (brownfield). Phased, reversible, with a clear rollback:

1. Schema coexistence — import the library's tables under a distinct prefix; do not overwrite the existing users table. Map legacy users into the library's column shape via a one-way sync or view.
2. Hash compatibility — validate that existing password hashes verify under the library's password_verify path (bcrypt/Argon2 are portable; custom or legacy MD5 schemes require transparent rehash-on-login). Rehash-on-successful-login is the safest cutover mechanism and avoids a forced reset wave.
3. Shadow mode — run the adapter in parallel on a subset of sessions; compare outcomes and log divergences before flipping default.
4. Cutover and deprecate — flip by feature flag, monitor login success rate and reset completion rate as the primary SLIs, then remove the legacy path after one full password-reset cycle has elapsed.

Compatibility. Verify PDO driver coverage against the target (the library targets MySQL/MariaDB, PostgreSQL, SQLite; validate collation and case-sensitivity on unique email constraints). Align session handling — the library leans on PHP's native session and its own "remember me" table, which must be reconciled with the framework's session driver, cookie name, and same-site policy. Confirm the mailer override, queue integration, and any table-prefix or connection-pooling assumptions.

Sequencing. (1) Feasibility spike on the actual PHP version and DB — one engineer, three days, explicit go/no-go. (2) Interface + adapter + mailer override. (3) Schema migration and hash validation. (4) Shadow validation. (5) Cutover behind a flag. (6) Write the internal runbook and fork policy before shipping, not after — the runbook is a deliverable, not cleanup.

Operational Impact

Maintenance. Assume you own the code. Budget for a fork in the org's VCS with a documented patch process, plus a recurring PHP-version compatibility review each time the runtime is upgraded. Annualized cost is modest in engineer-hours but permanent, and it competes with roadmap work — the classic hidden line item in a "free, MIT-licensed, 1.2k stars" decision.

Support. No commercial backing and no vendor escalation path. Support is the internal team plus GitHub issues with uncertain response time. Mitigation: a named owner, a documented decision log, and a security-watch routine (periodic manual review, since there is no advisory subscription to rely on).

Scaling. Authentication is DB-bound, so scaling follows the database. Three specific concerns: the throttling table grows with every attempt and needs a pruning job or it becomes a write-hotspot and a storage issue; session affinity matters unless sessions are externalized to a shared store; and password hashing cost must be tuned to the instance class — Argon2/bcrypt defaults tuned for a laptop will saturate CPU on small containers under login bursts. All three are solvable, but each is an unowned default until someone owns it.

Failure modes. Enumerate these in the runbook:

• Mailer failure silently blocks verification and password reset — the single most common real-world outage for this class of library. Requires queueing, retries, and an alert on reset-completion rate.
• Throttling false positives lock out legitimate users behind shared NAT/corporate egress IPs; needs a tunable policy and a support override path.
• DB unavailability is total auth unavailability — there is no offline or cached-credential fallback, and no graceful degradation.
• Session and cookie misconfiguration across subdomains or during a rolling deploy produces intermittent, hard-to-reproduce logouts.
• Enumeration leakage through divergent error messages or response timing if the UI layer is customized carelessly.

Ramp-up. A mid-level PHP engineer can be productive in roughly one to two weeks; the friction is not the library's complexity but the absence of framework conventions — developers used to Laravel will reach for Eloquent, events, and validation traits that do not exist here, and will need to be told explicitly not to bypass the adapter. Plan for a short internal knowledge transfer, a written integration guide, and at least two people (not one) who can patch the dependency. Single-owner knowledge on an unmaintained auth library is the operational risk most likely to convert a cheap decision into an expensive one.