Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Webauthn Laravel Package

moontechs/filament-webauthn

moontechs/filament-webauthn brings WebAuthn passkey authentication to Filament panels. Users register and sign in with fingerprint, face recognition, or a hardware security key instead of passwords, adding phishing-resistant, passwordless login to your admin panel with minimal setup.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. The package targets the TALL stack — a Filament panel plugin that supplies the WebAuthn registration and assertion ceremonies as Livewire/Alpine components, with credential storage on the Laravel side. That is the right shape for Filament: it keeps the ceremonies inside the panel's existing auth surface rather than introducing a parallel login system. The important architectural nuance is that WebAuthn is an authentication ceremony, not a Laravel guard. Value depends on whether the package cleanly calls into Auth::login() (and regenerates the session) so it composes with the rest of your auth stack — Filament's own login, any 2FA/MFA plugin, Fortify, and password reset. If it bypasses those, you inherit an MFA-bypass path, which for an admin panel is a material finding, not a nitpick.

Integration feasibility. The mechanics are well understood: publish config and migration, attach a trait/interface to the authenticatable model, configure Relying Party ID and origin, and serve over HTTPS (localhost excepted). The friction is the bootstrap problem — a user cannot use passwordless login until they have enrolled a credential, so you need a password-authenticated enrollment step and a permanent fallback, at least for a deprecation window. Also verify reverse-proxy behaviour: behind TLS termination, RP ID and origin derivation depend on correct TrustProxies and APP_URL configuration, and a mismatch fails every ceremony with an opaque browser error.

Technical risk. Two clusters. First, supply chain and longevity: 14 stars and a score of 0.38 imply a very small maintainer base, limited field testing, and a real chance you become the de facto maintainer. Security-critical code with low external scrutiny warrants a read of the source, not just the README. Second, specification surface: the package almost certainly wraps web-auth/webauthn-lib, so its risk is largely inherited — pinned versions, attestation conveyance policy, and whether user verification is required are all decisions you are adopting wholesale. Recovery flows (lost device, new phone, no credentials) are typically out of scope for packages like this and must be designed by you.

Key questions.

  • Which Filament major versions are supported (v3 only, or v4), and which PHP/Laravel floor? Does it follow Filament's plugin contract or monkey-patch the panel?
  • Does it wrap web-auth/webauthn-lib, and at what version constraint? Are dependencies pinned or floating?
  • Does authentication go through Laravel's session guard with session regeneration, and does it respect or bypass existing 2FA?
  • Multiple credentials per user with device labels and revocation UI — or one credential per account?
  • Attestation policy, user-verification requirement, and resident-key/discoverable-credential support?
  • Rate limiting and replay protection on the assertion endpoint; challenge storage and single-use semantics?
  • Test suite, CI, release cadence, open issues, and any prior security advisories?

Integration Approach

Stack fit. Laravel 10/11, PHP 8.1+, Filament 3.x, Livewire 3, Alpine — no new infrastructure, no external identity provider, no additional runtime. Browser-side it requires navigator.credentials, which is universally available in current Chrome, Safari, Edge, and Firefox; platform authenticators (Touch ID, Windows Hello, Android biometrics) and roaming keys both work. Passkey sync via iCloud Keychain and Google Password Manager meaningfully improves the UX but shifts the support burden from "lost key" to "which device has the synced passkey," and enterprise policy on passkey sync varies. Net: the fit is good, and there is no new vendor relationship to negotiate.

Migration path. Additive rather than disruptive. Publish config and migration, add the trait to the user model, ship an enrollment prompt inside the authenticated profile area, and leave password login enabled. Run dual-mode for a defined window; decide explicitly whether passwordless is optional or mandatory for specific roles (a reasonable first target is super-admins on a secondary panel, not the whole user base). Rollback is a config flag plus leaving the credentials table in place — cheap, which argues for doing the spike early.

Compatibility. Confirm the exact Filament, Livewire, and web-auth/webauthn-lib matrix before committing; the package's composer constraints are the binding contract, not its README. Check for conflicts with any existing auth plugins (Shield, Breezy, Fortify) and with custom login pages. Treat the RP ID and origin as effectively immutable once credentials exist: changing the panel's domain or moving from admin.example.com to example.com/admin invalidates every enrolled credential. That is a planning constraint, not a bug, but it must be on the roadmap before rollout.

Sequencing.

  1. Spike in a throwaway repo: install, enroll, authenticate, and read the ceremony code end to end.
  2. Staging deployment on a non-production panel with real HTTPS and proxy configuration matching production.
  3. Internal dogfood with 5–10 users across macOS/Windows/iOS/Android plus at least one hardware key.
  4. Opt-in rollout with password fallback and a documented recovery path.
  5. Hardening pass: rate limits, audit logging of enrollment and assertion events, alerting on failure-rate spikes.
  6. Only then consider passwordless-only for privileged accounts.

If step 1 surfaces gaps in recovery, MFA composition, or Filament version support, plan to vendor a fork rather than block on upstream.

Operational Impact

Maintenance. Assume you own this. Pin the version, mirror or fork if the repository goes quiet, and track the underlying WebAuthn library's advisories independently of this package's release notes. Budget a recurring review — annually at minimum, and on any change to the panel's domain, TLS termination, or auth stack. The code volume is small enough that a fork is tractable, which lowers the risk considerably.

Support. The dominant operational cost is not the happy path, it is the recovery path. Before rollout you need: a self-service credential management screen, a help-desk script for "new phone / lost device," and an identity-verification procedure for resetting credentials out of band. Publish a short user-facing explainer; most tickets will be "my passkey isn't offered" rather than genuine failures, and the causes are usually browser profile, sync state, or the wrong device.

Scaling. Negligible. An assertion is one credential lookup plus a signature verification; at admin-panel volumes this is noise. The one thing to verify is challenge storage: it must be per-session with a short TTL and single-use semantics. If the package uses a shared cache key without a user-scoped nonce, concurrent logins can collide — worth an explicit test.

Failure modes.

  • RP ID / origin mismatch after a domain or path change — breaks every credential at once and is the highest-severity operational risk.
  • Proxy or TLS-termination misconfiguration, presenting identically as an opaque browser error.
  • Expired or already-consumed challenge, often surfacing as intermittent failures under slow networks.
  • Clock skew on hosts validating clientDataJSON timestamps.
  • Lockout when password fallback is removed before recovery tooling is proven.
  • OS/browser updates altering platform authenticator behaviour; a small fraction of users will regress on every major release.
  • Orphaned credential rows if the migration is rolled back without cleanup.

Ramp-up. A Laravel developer familiar with Filament should be productive with the package in two to three days; the WebAuthn concepts (challenges, RP ID, attestation vs. assertion, discoverable credentials) take longer, and the team should not be on call for this until at least one person can explain the ceremony flow from memory. Documentation at this maturity level is likely thin, so plan to learn from the source. Total cost to a confident, hardened production rollout: roughly two to three engineer-weeks including the spike, staging validation, and hardening — plus a standing maintenance line item for as long as the feature lives.

Position. Technically sound direction and a good architectural fit for Filament, but at 14 stars and a 0.38 score the package is a starting point, not a dependency you can take on trust. Appropriate for a time-boxed spike and a controlled opt-in rollout on a non-critical panel; not appropriate as the sole authentication path for a production admin panel without a fork-and-own decision, a designed recovery flow, and the domain-immutability constraint written into the roadmap.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elmogy/larafast
xeviant/laravel-paystack
gorilladash/laravel-website-sdk
martialbe/flysystem-oss
chondal/3312client
jeroen-g/flickr
opscale-co/nova-genbi
itsjustvita/laravel-retention
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log
gregsphotography/site-builder-components
io-digital/clickatell
snowsoft/laravel-admin
oxygen/auth
relicsoftware/barakah-payment-gateway
tobya/work-with-composer
equipc/laravel-email-validator
equipc/laravel-email-database-log
adedsec/nova-translated-labels