Laravel Biometric Auth Laravel Package

Product Decisions This Supports

• Passwordless / biometric login on first-party mobile apps. This package supplies the server half of a device-bound challenge–response flow: register a device public key, issue a single-use challenge, verify the signature. That maps directly to "log in with Face ID / Touch ID / Android BiometricPrompt" without the backend team inventing a nonce lifecycle from scratch.
• Step-up authentication for high-risk actions. Re-auth before a payout, card change, account deletion, or admin impersonation. Because challenges are single-use, it gives a clean, auditable "prove you're still the person holding this device" primitive instead of another SMS code.
• SMS/OTP cost and fraud reduction. Each flow migrated off SMS is a per-message cost and a SIM-swap/OTP-interception risk removed. Useful line item in a cost-reduction or fraud-roadmap review.
• Device trust registry, as a side effect. Persisting device public keys gives you a per-user device inventory — useful for "manage your devices," session revocation, and anomaly detection, independent of the login story.
• Build vs. buy vs. borrow. This is the "borrow a primitive" option: it de-risks the protocol plumbing but not the product. The real decision it informs is custom device-key auth vs. full WebAuthn/passkeys, and that's a roadmap commitment, not a library choice.
• Sequencing. It supports a narrow, defensible v1 (native app, biometric unlock, one or two step-up flows) while deferring the broader passkey/web story to a later phase — provided you accept the standards gap.

When to Consider This Package

Consider it when all of these hold:

• Your client is a first-party mobile app you control, where the OS biometric APIs can generate and use a hardware-backed keypair (Secure Enclave / Android Keystore). This package assumes the client can sign a challenge; it does not provide the client.
• Your backend is Laravel and you want the key store, challenge issuance, single-use enforcement, and signature verification as framework-native models and endpoints rather than greenfield code.
• You need a narrow, non-standard flow and are comfortable owning the security properties — it is a low-level signature-verification primitive, not a certified FIDO2/WebAuthn server. There is no attestation, no AAGUID/metadata story, no browser/passkey path.
• You have — or can buy — security review capacity. Treat the package as a reference implementation to audit and vendor, not a drop-in trust anchor.
• Team velocity matters more than ecosystem size for a v1 you intend to revisit.

Look elsewhere when:

• You need web/passkey support or cross-platform credentials. Use a real WebAuthn server library (e.g. web-auth/webauthn-lib, laragear/webauthn) instead; the standard solves problems this package deliberately doesn't.
• You require attestation, certified authenticators, or audit evidence for a regulated review (financial-grade SCA, HIPAA-adjacent, government). A 10-star, single-maintainer MIT package will not survive procurement or a security questionnaire.
• Bus factor matters. With ~10 stars and one release, assume you may inherit maintenance. That is acceptable for an internal primitive you've read end-to-end; it is not acceptable as an unexamined dependency on the critical auth path.
• The release date metadata looks anomalous — verify the actual commit history, issue tracker, and test coverage before committing. Popularity here is not a quality signal; the score's low opportunity signal is consistent with a thin, unproven niche.
• You want vendor support, SLAs, or an indemnity. MIT gives you none.

How to Pitch It (Stakeholders)

To executives: "We can add biometric login and step-up verification to the mobile app in weeks rather than a quarter, and take a bite out of SMS costs and OTP fraud. The trade-off is that this is an open-source building block from a very small project, not a supported product — so we budget a security review and accept that we own the code. It gets us a credible v1; if biometrics becomes a strategic pillar or a compliance requirement, we'll migrate to a standards-based passkey implementation."

Frame it as a cheap experiment with a known exit, not a platform bet. Name the exit explicitly.

To engineering: "It handles the fiddly, easy-to-get-wrong parts — public key storage, single-use challenge issuance, replay prevention, signature verification — as Laravel-native models and endpoints. It does not give you a client SDK, attestation, or WebAuthn compatibility. Read it before you ship it, pin the version, and vendor or fork it so an upstream disappearance isn't an outage. We'll want our own tests around challenge expiry, reuse, and key rotation regardless."

To security/compliance: "Non-standard, device-bound, possession-plus-biometric factor. No attestation, no certified authenticator metadata, no third-party audit. Suitable as a convenience or step-up factor with a password fallback; not positioned as a sole authentication factor for high-assurance flows until reviewed."

Decision ask: approve a time-boxed spike (one flow, one platform, security review in scope) with an explicit review gate — continue, replace with a WebAuthn library, or roll our own — before it reaches the login path.