Laravel Authentication Log Laravel Package

Technical Evaluation

Verdict: Low-risk, additive, well-scoped package. It sits on top of Laravel's native auth events rather than replacing the guard, so blast radius is small and rollback is composer remove plus a trait deletion. Value is concentrated in user-facing security UX (device notices, session revocation, login history) and lightweight telemetry — not in compliance-grade auditing.

Architecture fit

• Hooks Illuminate\Auth\Events\{Login, Logout, Failed, ...} via a listener; no replacement of the auth pipeline, no facade-based global state, no middleware forced into the stack.
• Dedicated authentication_log table with a polymorphic authenticatable relation → supports multiple authenticatable models (User, Admin, Customer) rather than assuming a single App\Models\User.
• Clean extension surface: trait, publishable config, notification classes, Eloquent query scopes, optional middleware, artisan export command, webhook fan-out.
• Headless. The README's "session management" and "device management" are model methods only — the admin/member UI is entirely our build cost.

Integration feasibility

• Install is genuinely ~30 minutes; real feature surface is 2–5 dev-days plus UI.
• Constraint: the trait must be added to each authenticatable model. If the User model lives in a shared internal package or is generated, that's friction.
• Core needs no third-party service. GeoIP is optional and brings its own provider dependency.
• Version matrix is strictly coupled to the framework: v6.1+ → Laravel 11/12/13 + PHP 8.2; v3.x → Laravel 10 with basic logging only (no fingerprinting, sessions, webhooks, suspicion detection). On an older runtime we are effectively buying a different product.

Technical risks

1. Capture coverage is event-driven. Token issuance (Sanctum/Passport), SSO callbacks, magic links, and programmatic Auth::login() inside jobs/commands may be logged partially or not at all. This is the single biggest gap between expectation and reality.
2. "Device fingerprinting" is normalized-UA SHA-256. No entropy beyond the user agent; trivially spoofed. RequireTrustedDevice inherits that weakness — treat it as a nuisance-reduction heuristic, never as an authorization control for sensitive actions.
3. Session revocation depends on the session driver. With the file driver we cannot enumerate or invalidate other sessions; "log out all devices" becomes a broken promise. Must be confirmed against production config before committing to the feature.
4. PII and retention. IP + coarse geo + user agent is personal data. There is no retention/pruning command in the documented surface (export only) — the retention job is ours. This needs legal/product sign-off, not a dev decision.
5. Synchronous side effects. New-device notifications and webhooks can execute inside the login request; unqueued, they add latency and create a new failure path into authentication.
6. Metadata is forward-dated (release listed as 2026-10-09, Laravel 13 claims). Pin exact versions and validate compatibility claims against our runtime rather than trusting the matrix.
7. Signal quality of suspicion detection is rule-based and threshold-driven; unset thresholds equal alert fatigue.

Key questions before commitment

• Which auth surfaces are in scope — is API/token or SSO login expected in the log?
• Is this a forensic/compliance record, or a UX and telemetry feed? The answer changes retention, immutability, and the tooling around it.
• What session driver runs in production?
• Who triages suspicion flags — a SOC/on-call, or does this stream to a SIEM?
• Multi-tenant: single table with a tenant column, or per-tenant connection?
• What is the retention window, and who owns the PII policy?

Integration Approach

Stack fit

• Greenfield/current Laravel 11–13 on PHP 8.2+: full feature set, straight composer require with a pinned constraint.
• Laravel 10: v3.x only, basic logging — reassess whether the value proposition survives the feature loss.
• Anything older: not a fit; use framework/IdP audit logs instead.

Migration path

1. composer require rappasoft/laravel-authentication-log:^6.1 (pin minor, never float).
2. Publish config and migrations; run migrate.
3. Add AuthenticationLoggable to the relevant models.
4. Existing installs: the upgrade migration adds columns additively (device_id, is_trusted, is_suspicious, etc.). Rehearse on a production-sized copy — DDL on a large authentication_log table takes a lock — and deploy off-peak with a backup.

Compatibility checks to run in the spike

• Sanctum/Passport, Socialite/SSO, Fortify/Breeze/Jetstream interplay.
• Non-integer user keys (UUID/ULID) — verify the migration's FK/column type matches the model key.
• Multi-guard and multi-model logging via the polymorphic relation.
• Immutable date casting (login_at, last_activity_at), called out in v6.1.0.
• Custom table name / separate DB connection for tenant isolation.

Sequencing

Rollback: config-gated disable (notifications/webhooks off) is instant; full removal is trait + package removal, with the table left in place or dropped independently. Ship step 6 last — enforced trusted-device routing without a "trust this device" flow locks users out.

Operational Impact

Maintenance

• Single primary maintainer plus community contributors. Bus factor 1, but MIT license, compact schema, and event-listener design make a fork cheap (~2–5 dev-days/year if we take ownership).
• Release cadence tracks Laravel majors, and majors have been breaking (v6.0 dropped Laravel 10, added columns). Budget an annual upgrade bundled with framework upgrades; pin and test rather than auto-updating.
• ~1k stars with 0 listed dependents likely reflects a metric artifact — don't read ecosystem weight into it; validate locally.

Support

• Good self-serve surface: README, dedicated docs site, changelog, release notes with an upgrade guide. No vendor, no SLA — internal ownership required for anything we expose to customers.

Scaling

• Write volume is one row per auth event — negligible against application traffic. The real pressure is unbounded table growth, index coverage (authenticatable + time, device_id, ip), and any dashboard query scanning the full table.
• Notification and webhook throughput scales with queue workers, not app instances, if queued correctly.
• The export artisan command loads logs — run it scheduled/off-request, never from a UI action.

Failure modes and blast radius

• DB write failure during login: verify the listener can't fail the auth request; test by injecting a write error.
• Sync notification or webhook timeout → login latency spike. Enforce ShouldQueue, explicit timeouts, and failure isolation.
• GeoIP provider outage → null location; confirm graceful degradation.
• Duplicate or false "new device" notices from UA version churn — v6.1.1 specifically fixed session-restoration duplicates, but notification accuracy is the metric that decides adoption.
• Suspicion flags with default thresholds → alert fatigue; needs tuning and a named triage owner before it is shown to anyone.
• RequireTrustedDevice misconfiguration → account lockout; ship a bypass and a support runbook.
• Unbounded growth → storage cost and slow queries. A scheduled prune job is mandatory scope, not a follow-up.

Ramp-up

• ~1–2 days for a Laravel developer to full productivity.
• ~1 day of PM/security/legal time for retention, PII, and notification policy — this is the actual schedule risk.
• The session/device UI is the dominant build cost (est. 5–10 dev-days depending on polish) and should be scoped as product work, not "included with the package."

Recommendation: Adopt for Laravel 11+ session-authenticated apps where the goal is user-visible login/device transparency plus basic security telemetry. Do not adopt as a compliance-grade audit trail or as an authorization control without supplementary identity/IdP logging. Pilot with notifications disabled, measure the new-device false-positive rate, then enable to a canary cohort before organization-wide rollout.