Laravel Auth Logs Laravel Package

Technical Evaluation

Architecture fit

• Purpose-built for the Laravel idiom: a package service provider, publishable config and migrations, an Eloquent model over an auth_logs-style table, and event listeners bound to Laravel's native authentication events (Login, Failed, Logout, Lockout/AuthenticationException). This is the lowest-friction shape a Laravel add-on can take and slots into a standard app without architectural change.
• It is an observability component in a domain (authentication) that is otherwise handled by Fortify/Breeze/Jetstream/Sanctum. That means it composes rather than replaces — no guard or user provider surgery required, which is the key architectural green light.
• The optional geolocation and notification layers introduce outbound HTTP calls and queue jobs. That pushes it from "pure library" into "runtime dependency on a third party," which is an architecture decision, not just a config toggle.

Integration feasibility

• Composer install plus vendor:publish plus php artisan migrate is a 30-minute proof of concept for a single-guard web app. Feasibility is high for the happy path.
• Real effort sits in the edges: multi-guard setups (web + API via Sanctum/Passport), custom Authenticatable models, impersonation flows, SSO/social login callbacks, and remembering that token-based API auth does not fire the same events as session login. Coverage must be verified, not assumed.
• Geolocation requires an external IP-intelligence provider. That is a data-processing decision (PII/IP address leaves the estate) that will route through security/privacy review in any regulated environment, independent of code quality.

Technical risk

• Adoption risk (high): 7 stars and 0 dependents is effectively unproven. There is no ecosystem signal that the schema, config surface, or event handling has been hardened by other teams' production traffic. Score of ~13/100 and an opportunity score under 30 reinforce "interesting, not yet validated."
• Bus factor (high): single-maintainer packages with no dependents have no natural co-maintainers. MIT license mitigates the legal risk (we can fork) but not the ongoing-patch risk.
• Compatibility risk (medium): Laravel's authentication internals move (event payload shapes, Attempting/Authenticated events, password rehashing, session handling). Absent a declared support matrix and CI matrix, version upgrades become a manual verification task each cycle.
• Data/PII risk (medium): IP addresses, user agents, and geolocation are personal data in GDPR/CCPA contexts. Retention, lawful basis, and right-to-erasure handling are our responsibility, not the package's.
• Notification-path risk (low-medium): alerting on failed logins is the headline feature, but naive thresholds generate storms under credential-stuffing or misconfigured clients. Rate limiting and dedup are ours to add.
• Release-date anomaly (low): the recorded last release (2026-06-26) should be sanity-checked against the actual changelog and commit history before we treat recency as a health signal.

Key questions

1. Which Laravel and PHP versions are explicitly supported and tested in CI? Is there a published support matrix and a deprecation policy?
2. What exactly is captured per event, and does coverage include failed attempts, lockouts, password resets, logout, remember-me, and token/API authentication — or only session login?
3. Which geolocation provider is used, is it pluggable, is it called synchronously or queued, and what is the fallback when it fails or is disabled?
4. Is there a retention/pruning command or scheduled job, and can individual records be anonymized or purged on erasure request?
5. Are notifications queued and rate-limited, and do they ship with sensible defaults for failed-login thresholds?
6. Does the schema support multi-tenancy (tenant/team scoping) without forking?
7. What is the test coverage and is there a security disclosure process?
8. Who maintains it, what is the commit cadence over the last 12 months, and how many open issues are unanswered?

Integration Approach

Stack fit

• Strong fit if we are on a conventional Laravel monolith or modular monolith with a relational database, a queue worker, and a scheduler already running. In that environment the package is additive: one composer line, one migration, one config file, one listener registration.
• Weak fit for serverless/Lambda deployments where queue workers and schedulers are absent, and for multi-tenant SaaS where the package's table has no tenant key.
• Pairs naturally with existing auth scaffolding (Fortify/Breeze/Jetstream) because it listens to framework events rather than owning the login flow.

Migration path

• There is no historical backfill. Logs start at install. If audit history matters, we must state that explicitly to compliance stakeholders up front — this is the single most common expectation gap.
• Path for an existing app: (1) install into a feature branch and run migrations against a scratch database; (2) enable event logging only, with geolocation off; (3) verify captured rows against manually triggered success, failure, and lockout cases per guard; (4) enable geolocation behind a queue; (5) enable notifications last, with thresholds tuned to baseline traffic.

Compatibility

• Confirm Laravel/PHP versions against composer.json constraints and CI badge before committing. Check whether the migration publishes with the correct column types for our DB engine (JSON columns, IP storage as string vs. binary).
• Verify behavior with our specific auth stack: custom guards, social login, MFA challenge steps, and Sanctum-protected APIs. Each is a potential coverage hole that produces false confidence in dashboards.
• If we are on a Laravel version outside the tested range, budget time for a compatibility patch or vendor fork.

Sequencing

1. Spike (1–2 days): install in a sandbox, confirm event coverage matrix per guard, inspect generated schema, review the geolocation call path and payload.
2. Privacy/security review (parallel): data classification for IP and geolocation, retention decision, provider review or explicit decision to disable geolocation.
3. Phase 1 — silent logging in production: logging on, geolocation and notifications off. No user-facing behavior change, low blast radius.
4. Phase 2 — retention and access: add pruning to the scheduler, restrict table access, wire into existing observability if present.
5. Phase 3 — alerting and geolocation: enable queued geolocation, then notifications with rate limiting and dedup after baselining normal failed-login volume.
6. Phase 4 — dashboards/reporting: only if a consumer (security, support, compliance) actually needs the query surface; otherwise phase 1–3 is the full value.

Operational Impact

Maintenance

• Low routine burden: it is a small, single-purpose package that rides on framework events. Upgrades to Laravel are the main recurring cost — each major bump requires verifying event payload compatibility or applying a patch.
• Bus factor of one means we should assume we may need to fork. Mitigation: keep the config and migrations in our repo, avoid deep customization of package internals, and vendor-pin the version. Treat it as "adopt with an exit plan," not "adopt and forget."
• Table growth is the hidden maintenance item: every login attempt writes a row. On a high-traffic app this reaches millions of rows quickly, so pruning and indexing are day-one requirements, not optimizations.

Support

• Internal support surface is small but real: "why didn't this failed login appear," "why did I get an alert at 3am," and "why is location blank." Each maps to a known failure mode (guard coverage, alert thresholds, geolocation provider outage) and should be documented in a runbook at rollout.
• No commercial support and minimal community depth means escalation path is "read the source." Acceptable for a security-adjacent logging tool with a simple schema; unacceptable if we later treat it as an audit system of record.

Scaling

• Write volume scales linearly with authentication attempts, which spikes precisely during attacks — the moment we most need the data. Bounded by DB write throughput; on large apps, consider a separate connection or table partitioning.
• Notification and geolocation scale via the queue. Geolocation adds one external call per new IP; caching repeated IPs materially reduces provider cost and latency.
• Query/reporting scale is fine at small volumes and becomes a concern on the primary database at large volumes; export to a log warehouse if the data is used analytically.

Failure modes

• Missed events: API/token auth and custom guards silently bypass listeners → gaps that look like "no attacks" rather than "no logging." Highest-severity failure because it is invisible.
• Geolocation provider outage or rate limit: either synchronous latency on login or blank location fields, depending on implementation.
• Notification storms: credential stuffing or a misconfigured scanner triggers thousands of alerts; without rate limiting this degrades into alert fatigue and ignored alerts.
• Database pressure: unpruned growth slows writes and queries; in extreme cases auth logging becomes a login-path dependency.
• Queue backlog: if geolocation/notifications share the default queue, a backlog delays alerts during exactly the incident they exist for.

Ramp-up

• Engineering: ~0.5 day to a working local install, ~2–3 days to production-ready with guard coverage verification, retention, and alert tuning.
• Security/compliance: ~1–2 days of review focused on PII classification, retention policy, and provider data flow — likely the critical path, not the code.
• Operations: ~0.5 day to document the runbook, pruning schedule, and alert expectations for on-call.
• Overall verdict for a TPM: a cheap, well-shaped logging component that solves a real problem with low integration cost, but currently carries unproven-adoption and single-maintainer risk. Adopt as a supplemental signal source behind a feature flag with an explicit fork plan; do not position it as an audit system of record until event coverage and retention are verified in our own environment.