Filament Passwordless Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel auth. A Filament-native passwordless plugin turns "should we build magic-link login ourselves?" into a cheap spike. The realistic alternative isn't zero work — it's a sprint of token generation, signed-URL expiry, rate limiting, replay protection, session handling, and UI wiring for every panel. This package compresses that into a composer require plus a config publish, which reframes the decision as evaluate for a week rather than commit a sprint.
• Roadmap sequencing: is passwordless a differentiator or table stakes? For an internal ops/admin panel, passwordless login is almost never a selling point — it's friction removal. This package lets you ship it as a low-cost enabler without pulling effort away from revenue-facing roadmap items.
• User-segment scoping. It supports a deliberate split: passwordless email magic links for internal staff and back-office Filament panels now, while deferring SAML/OIDC/SCIM work until an enterprise buyer actually demands it. That keeps the identity investment proportional to the segment.
• Support-cost and onboarding-funnel decisions. Password resets are a measurable, boring tax. Adopting this gives you a clean A/B style comparison — reset-ticket volume and time-to-first-login before vs. after — that produces a number you can use to justify (or kill) further identity investment.
• Feature-level decision: magic link vs. OTP vs. passkeys. Use this as the cheap baseline. If the data shows login friction still hurts after magic links, that's your evidence to escalate to WebAuthn/passkeys rather than guessing.
• Buy-vs-adopt for the identity layer overall. Because it's MIT and Filament-scoped, it's a low-regret stepping stone: adopt now to unblock a panel launch, keep the door open to swapping in a managed IdP (WorkOS, Auth0, Clerk, or Laravel's own Fortify/Socialite stack) once requirements harden.

When to Consider This Package

Consider it when all of these hold:

• You run a Filament panel (admin, ops, internal tooling) and authentication is the last thing blocking a launch or a pilot.
• Your user base is internal staff or a small, known set of external users — tens to low thousands, not anonymous consumer signups at scale.
• You already have reliable transactional email and a verified sender domain; magic links are only as good as your deliverability.
• Enterprise SSO is not yet a contractual requirement. No buyer is asking for SAML, SCIM provisioning, or IdP-initiated flows.
• You're comfortable pinning a single-maintainer, ~26-star dependency, reading its source, and owning a fallback path. Budget the review time explicitly — this is the real adoption cost.
• You want a time-boxed, feature-flagged pilot rather than a permanent architectural commitment.

Look elsewhere when:

• Compliance or security posture demands phishing-resistant MFA (NIST 800-63B AAL2/AAL3, SOC 2 controls that mandate WebAuthn/passkeys, or regulated environments). Magic links are convenience-grade, not strong-MFA-grade, and are often judged AAL1.
• You need enterprise identity: SAML/OIDC, SCIM, group-to-role mapping, audit logs of auth events, session revocation policy. This package's scope is Filament login, not identity governance.
• You need a support contract, SLA, or security disclosure process with teeth. A 26-star package gives you an issue tracker, not a vendor.
• Consumer-scale auth with abuse concerns: signup enumeration, link-forwarding, shared inboxes, bot traffic. That's a different product surface.
• Your team already standardized on an IdP or on Fortify/Socialite. Two auth paths in one codebase is a maintenance tax and a security review headache; don't add a second unless it replaces something.
• Filament version compatibility isn't confirmed for your pinned major. Verify against your actual Filament and Laravel versions before it lands in a roadmap commitment.

How to Pitch It (Stakeholders)

For executives — one paragraph: We can remove password friction from our internal admin panel for roughly a day of engineering plus a review, instead of a multi-week build or an IdP contract. It's MIT-licensed, scoped narrowly to Filament login, and reversible — we'd run it behind a feature flag with password login as fallback, so the downside is bounded. The measurable upside is fewer password-reset tickets and faster onboarding for ops staff. The real risk is that it's a young, single-maintainer package, so we treat it as a validated experiment rather than a platform commitment, and we keep a documented exit to a managed identity provider if requirements harden.

For engineering — the honest version: This is a thin Filament plugin for passwordless auth, last released 2026-06-16, MIT, low community footprint. Adopt it as a pinned dependency behind a config flag, after a source review covering token entropy, expiry, single-use enforcement, rate limiting, and email enumeration on the request endpoint. Instrument three things from day one: magic-link delivery success rate, median time-to-first-login, and password-reset ticket volume. Set an explicit review date (one quarter out) where we decide: keep, fork-and-vendor, or replace with an IdP. Treat email deliverability as a hard dependency, not an afterthought — most "passwordless is broken" incidents are actually SPF/DKIM incidents.