- What does laranex/laravel-biometric-auth do?
- laranex/laravel-biometric-auth adds device-bound biometric authentication to Laravel applications. Users enroll a device public key, the server issues a single-use challenge, and the application verifies a signature over that challenge. It is aimed at passwordless or step-up login using fingerprint, Face ID, or device passkeys.
- Is this package WebAuthn or FIDO2 compliant?
- Treat it as a custom challenge-signature scheme rather than a WebAuthn or FIDO2 implementation. It does not provide attestation, AAGUID or authenticator metadata, RP-ID origin binding, or standard passkey recovery semantics. If you need FIDO2 conformance, PSD2 SCA, NIST 800-63B AAL2, or enterprise passkey interoperability, evaluate a mature WebAuthn library instead.
- Which Laravel and PHP versions does laravel-biometric-auth support?
- The package is intended for modern Laravel applications, but confirm the exact Illuminate and PHP constraints in its composer.json before committing. Check that your Laravel major version, PHP version, and OpenSSL extension satisfy those constraints. Run the package test suite against your target versions as part of the evaluation.
- How do I install and configure it in a Laravel app?
- Install it with Composer, publish the package migrations and configuration, then wire its contract or trait into your User model and expose the register, challenge, and verify routes. Keep the published migrations non-destructive and review them against your existing users table. Gate enrollment behind step-up authentication because the server cannot attest the key's origin.
- How does device registration and challenge verification work?
- A device generates a keypair and sends the public key to your Laravel app during registration. For login, the server issues a challenge, the device signs it with the private key held in the Secure Enclave or Android Keystore, and the server verifies the signature against the stored public key. You control both ends of the ceremony, so the client must handle key generation and signing correctly.
- Are challenges truly single-use and safe against replay attacks?
- Single-use challenge consumption is the stated design, but verify that it is enforced atomically, for example with a delete-and-return or conditional update rather than a read-then-write. Under concurrent requests, a non-atomic check can allow replay. Also review TTL handling and clock assumptions, and add negative tests for replayed and expired challenges.
- Which signature algorithms are accepted, and can I restrict them?
- The verifier should accept only an explicit allow-list of algorithms, typically P-256 with a known hash, and enforce that list server-side so openssl_verify cannot be steered toward weak curves or none. Review public-key parsing for PEM, JWK, and DER edge cases. Confirm constant-time comparison is used where the implementation compares values.
- Can I use it as the only authentication method for passwordless login?
- Use it as a step-up factor or second factor alongside your existing password and session issuance, not as the sole authentication mechanism. Without attestation, the server cannot distinguish a genuine hardware-backed key from one created after a password compromise. Sole-passwordless use requires additional hardening, enrollment controls, and a recovery design.
- How are device revocation and lost-device recovery handled?
- Plan for multiple devices per user, explicit device revocation, and a lost-device recovery flow. The package may store device credentials, but recovery is not a standard part of a custom challenge-signature scheme, so you will likely need out-of-band confirmation and re-enrollment. Treat revocation and enrollment as security-sensitive audit events.
- Is laranex/laravel-biometric-auth actively maintained and safe for production?
- The project has a single maintainer, a recent first release, and a small ecosystem footprint, so the bus factor is effectively one. Before production, run negative tests for replayed, expired, and malformed signatures, add rate limiting and audit logging, and check for a security disclosure policy. If those controls are missing, budget hardening time or choose a more established WebAuthn library.