Laravel Auth Log Laravel Package

Technical Evaluation

Scope of v1.4.1: Compatibility-only release. The sole change is "Laravel 13 support" (PR #6). No new features, no API changes, no deprecations, no breaking changes. For assessment purposes this is a maintenance heartbeat, not a capability change — but it is the first signal that the package is tracking the current framework line, which matters for a new adoption decision.

Architecture fit

• label84/laravel-auth-log is a narrowly scoped, single-responsibility package: it registers listeners against Laravel's native authentication events (Login, Logout, Failed, Lockout, and related) and persists them to a dedicated table via an Eloquent model, with a publishable config to toggle which events are captured.
• It does not wrap, replace, or decorate the Auth guard. Integration is additive and sits beside the existing auth stack rather than inside it. This is the lowest-risk shape a package in this domain can take.
• No service container binding overrides, no custom guard driver, no middleware injection into the request pipeline — meaning it composes cleanly with Sanctum, Fortify, Breeze, Jetstream, and multi-guard setups without conflict.
• The trade-off of event-listener architecture is coverage-by-convention: anything that authenticates without firing a native Laravel auth event (custom token issuance, SSO callbacks, some social login flows) will silently not be logged.

Integration feasibility

• Standard Laravel package install: composer require label84/laravel-auth-log, publish migration and config, php artisan migrate. Package auto-discovery means no manual provider registration on modern Laravel.
• Total integration effort is measured in hours, not days, including verification. No application code changes are required to capture the default event set.
• The one non-trivial prerequisite is environmental: Laravel 13 sets a higher PHP floor than earlier majors. Confirm the runtime PHP version before committing, and confirm the package's illuminate/* constraint actually widened rather than the release dropping older Laravel majors.
• Reversibility is excellent: remove the package and drop one table. No residual coupling in application code if the config toggles are used rather than direct model queries.

Technical risk

• Low, but not zero. Rated low on functional risk, medium on data-governance risk.
• PII / privacy: the package persists IP address and user agent by default. Under GDPR/CCPA this is personal data in a system of record that likely was not previously covered by the privacy notice or retention policy. This is the single item most likely to require legal/security sign-off and is the most common reason adoption stalls.
• Unbounded growth: no built-in retention or pruning. Steady-state traffic is one row per auth event; hostile traffic (credential stuffing, password spraying) generates one row per failed attempt, which is exactly the scenario where volume spikes and the table grows fastest.
• Failure semantics unverified: whether a database write failure on the Login listener throws and blocks authentication (fail-closed) or is swallowed (fail-open) is the critical unknown. Fail-closed is unacceptable for a logging concern.
• Maintainer concentration: effectively a single-maintainer project. The Laravel 13 PR landing promptly is a positive signal on responsiveness, but there is no organizational backstop.
• Semantic drift: the 1.4.0 → 1.4.1 delta being a single compatibility commit suggests a low-velocity project. That is fine for a package this small, but it means Laravel 14 support should not be assumed on day one.

Key questions

1. Which authentication pathways in our application actually fire the events this package listens to — web session, API token (Sanctum), password reset, remember-me, impersonation, SSO?
2. Does the package fail open or fail closed when the log write raises an exception?
3. What is the retention requirement, and what mechanism will prune the table (scheduled command, partitioning, external job)?
4. Has Security/Legal signed off on storing IP and user agent for this purpose, and is the retention window documented?
5. Which indexes ship with the migration, and do they support our expected query patterns (per-user timeline, per-IP anomaly review)?
6. Does it support a custom model or connection, in case we need to route audit data to a separate database?
7. Is there a queue/async option, or is every write synchronous within the request?
8. What is the minimum PHP and Laravel version after this release, and did 1.4.1 drop support for any older major we still run elsewhere?

Integration Approach

Stack fit

• Fits any conventionally structured Laravel application on a currently supported major (10/11/12/13). No assumptions about frontend, session driver, or guard configuration.
• Particularly well-suited to regulated or security-sensitive contexts (admin panels, healthcare, fintech) where "who authenticated when, from where" is an audit requirement rather than a nice-to-have.
• Poor fit if the primary authentication surface is stateless API tokens or an external IdP: the native auth events may never fire, and the package would produce a misleadingly empty audit trail.

Migration path

• Greenfield or existing app: purely additive. composer require → publish migration/config → migrate → verify. No refactor, no code deletion, no changes to existing auth controllers.
• If partial auth audit exists today (custom Log::info calls in a login controller), migrate by running both in parallel for one release, diffing the event coverage, then removing the bespoke logging. Do not cut over in the same deploy.
• Rollback is a two-step: revert the composer entry, roll back the migration. Historical rows are lost unless the table is retained — decide up front whether the audit trail is a compliance artifact, because if it is, rollback is not actually a free operation.
• v1.4.1 specifically: nothing to migrate. If v1.4.0 is already deployed, this is a routine patch bump. If deploying fresh, pin ^1.4.1 to guarantee Laravel 13 support is present.

Compatibility

• Verify the PHP floor implied by Laravel 13 against our runtime images before sprint planning; this is the most likely blocker and is an infrastructure ticket, not an application ticket.
• Confirm behavior under Laravel Octane: long-lived workers and event listeners are generally fine here, but the package's use of per-request state (IP/user agent resolution) should be sanity-checked in a staging Octane environment.
• Confirm no conflict with event:cache in deployment pipelines — listener registration must survive php artisan event:cache.
• Check the composer.json constraint width: a package that supports Laravel 13 by requiring it is a different risk profile from one that widens the constraint to include it. The release notes as written do not distinguish these.

Sequencing

1. Week 0 — Validate. Confirm PHP/Laravel versions, confirm fail-open behavior by test, confirm event coverage per auth pathway in staging. Resolve PII/retention question with Security.
2. Week 1 — Staging integration. Install, migrate, enable default event set. Exercise every login path: success, failure, logout, lockout, password reset, token auth.
3. Week 2 — Retention and alerting. Ship the pruning job before production enablement, not after. Define indexes for the queries we intend to run.
4. Week 3 — Production, dark launch. Enable with full event capture, no dashboards yet, one release cycle. Confirm volume assumptions against real traffic.
5. Week 4+ — Operationalize. Wire into alerting (failed-login spikes), document the table in the data catalogue, add to the on-call runbook.
6. Decommission any bespoke auth logging once parity is demonstrated.

Do not enable production before the pruning job exists. That ordering is the whole sequencing plan.

Operational Impact

Maintenance

• Low ongoing effort. The package surface is a migration, a config file, a model, and a listener registration. There is nothing to tune.
• Upgrade cadence is driven by Laravel majors, not by the package. Expect one meaningful compatibility release per Laravel cycle plus occasional patches — consistent with the observed 1.4.0 → 1.4.1 pattern.
• Single-maintainer dependency. Mitigation is cheap given the package size: a fork is viable in an afternoon if the project goes dormant. Note this in the dependency register rather than treating it as a blocker.
• v1.4.1 itself requires no action beyond a routine composer update for teams already on the package. It is a patch bump with no behavioral delta.

Support

• Community-only: GitHub issues and PRs, no vendor, no SLA, no paid tier. The Laravel 13 PR merging promptly is evidence of an engaged maintainer, but responsiveness is best-effort.
• Internal support burden falls to the platform team. Budget a small amount of time for the first integration and near-zero thereafter.
• If the audit trail becomes compliance-relevant, the support model becomes a materially bigger concern than the code itself — an unaudited community package holding regulated data needs an explicit risk acceptance.

Scaling

• Write cost: one INSERT per captured auth event, synchronous within the request unless a queue option exists. Relative to bcrypt/argon hashing on the same request, this is noise. Not a throughput concern.
• Read cost: none unless we build dashboards. If we do, index user_id and created_at at minimum, and expect the per-IP anomaly query to need its own index.
• Storage: the real scaling dimension. Baseline volume tracks successful logins and is predictable. Failed-login volume is adversary-controlled and unbounded — a sustained credential-stuffing campaign can write millions of rows in hours. This is both a disk-capacity and a write-amplification risk during exactly the incident when the database is already under stress.
• Mitigations: partition or range-archive by month, rate-limit at the edge so failed attempts never reach the app, and exclude failed-login capture if the traffic profile makes it untenable. Decide this before launch, not during the first attack.

Failure modes

• Fail-closed auth outage (highest severity): if a log write exception propagates, authentication breaks for all users. Must be verified in staging and, if confirmed, patched to fail-open or wrapped in a try/catch at the listener level. This is the single item that can turn a logging package into an availability incident.
• Silent under-capture (highest likelihood): token-based or federated auth paths never fire native events. The audit trail looks healthy and is incomplete — the worst failure mode for a compliance control, because it fails invisibly.
• Unbounded table growth: disk exhaustion or query degradation. Symptom is a slow, correlated degradation across the application, not an obvious error.
• PII exposure: auth logs are a high-value target (they map users to IPs and times). Restrict access, exclude from general-purpose log shipping, and treat the table as sensitive in access reviews.
• Migration conflict: low, but the published migration timestamp can collide in dense migration directories; trivially resolved.

Ramp-up

• For a Laravel-fluent engineer: under a day to install and configure, one to two days to verify coverage across every auth pathway and confirm failure semantics. No new concepts to learn — it is idiomatic event-listener Laravel.
• For an engineer unfamiliar with Laravel's event system: add roughly a day to understand why a given auth path does or does not produce a record, which is the part that most affects whether the audit trail is trustworthy.
• Documentation burden is on us, not the package: the team needs a short internal note on what is captured, what is not captured, the retention window, and the fail-open/fail-closed behavior. That note is the deliverable that makes the integration operationally safe.