afsakar/filament-otp-login
Filament OTP Login adds one-time-password authentication to Filament panels, enabling passwordless sign-in via temporary codes. It provides a simple, configurable flow for issuing and verifying OTPs, helping secure admin access without traditional passwords.
Architecture fit. The package targets FilamentPHP panel authentication, so it sits at the edge of the admin/back-office layer rather than in core domain code. Architecturally that is a favorable insertion point: it should be swappable via the panel provider's ->login() configuration without touching business logic. The real question is whether it replaces password auth (passwordless) or augments it (second factor). Those are materially different risk profiles — passwordless turns the mail/SMS channel into the sole authentication factor, which is a step down from password+TOTP for privileged admin panels.
Integration feasibility. Expected shape is a Composer require, a published config (OTP length, TTL, channel), possibly a migration for OTP persistence, and a custom Login page class wired into the panel. That is a sub-week integration for a Laravel-fluent engineer. Feasibility hinges on Filament major-version compatibility: Filament's auth page contracts and panel configuration API have moved between v3 and v4, and packages that subclass login pages tend to break across majors. Verify the composer.json constraint against our installed Filament version before anything else.
Technical risk. This is an authentication surface with 66 stars and a single maintainer — treat it as untrusted code until read. The codebase is small enough to audit in a day, which is the right move. Specific risks to check: OTP stored in plaintext vs hashed; attempt counters and lockout; TTL and replay protection; constant-time comparison; user-enumeration behavior on the "send code" endpoint; rate limiting on both send and verify; whether password login can be bypassed or left enabled. The stated last release (2026-08-23) is ahead of the current date — verify the metadata is accurate rather than a mirror/scraper artifact.
Key questions.
Stack fit. Native fit for a Laravel + Filament stack that already has working transactional email. If the business requires SMS, assume you will write a custom notifier or driver — confirm the extension point exists before committing. If our panel already has MFA via another package, this becomes a conflict-resolution exercise, not an install.
Migration path. Do not cut over the primary admin login. Sequence: sandbox spike → source audit → staging integration behind a feature flag with password login still available → pilot cohort (internal, non-privileged panel) → monitored expansion. Keep a break-glass password or SSO path for super-admins for at least one full release cycle; an OTP-only login with an email provider outage is a full admin lockout.
Compatibility. Pin the exact package version in composer.json — no caret ranges on an auth dependency from a low-velocity maintainer. Confirm PHP and Laravel version floors match our runtime, and that the package does not conflict with our existing auth guard or session configuration. Check whether it requires a queue worker for delivery.
Sequencing.
Maintenance. Assume fork-and-own within two quarters. Low star count and a single maintainer mean upstream responsiveness is not a dependency we can plan around; budget a named internal owner and a standing task to review the package on each Filament upgrade. MIT license makes forking viable, which lowers the risk considerably.
Support. No vendor SLA. Escalation is GitHub issues plus our own engineer. That is acceptable for a back-office panel, not for customer-facing or regulated auth.
Scaling. OTP generation and verification are negligible compute. The cost driver is the delivery channel — SMS per login is a real per-seat operating expense at scale, and email volume grows linearly with admin headcount and session lifetime. Rate limiting is mandatory not for capacity but for abuse and cost control: an unthrottled send endpoint is an SMS bill and a mail-reputation incident.
Failure modes. Mail marked as spam or delayed past TTL (the most common real-world failure); SMS provider outage; queue worker backlog delaying delivery; user lockout after attempt-cap exhaustion with no self-service recovery; clock drift invalidating codes; broken behavior after a Filament minor upgrade; compromised mailbox becoming a full admin compromise if passwordless. Each needs a documented runbook entry, and the lockout case needs an operator-side unlock procedure.
Ramp-up. Low for a Laravel developer — roughly one to two days to integrate and validate in staging. The honest cost is the security review and the runbook/deliverability work, which is closer to a week of combined engineering and ops time. Allocate accordingly and do not let "it's just a Composer package" compress that estimate.
How can I help you explore Laravel packages today?