Passkeys Laravel Package

Product Decisions This Supports

• Passwordless roadmap / auth modernization. This is the cheapest credible path to shipping passkey registration, login, and re-authentication in a Laravel app. The package gives you the full WebAuthn ceremony server side — options generation, assertion verification, credential storage — plus a matching @laravel/passkeys npm client. That converts "passwordless" from a multi-sprint security project into a scoped increment you can put behind a flag.
• Build vs buy on WebAuthn. Buy. The valuable, error-prone part isn't the UI — it's the ceremony logic: challenge lifecycle, origin/RP-ID validation, signature verification, counter/clone detection, and stable opaque user handles. v0.1.0 already ships opaque user handles (primary keys never leak to authenticators), a bundled AAGUID catalog, and v0.2.0 added a DB transaction with pessimistic locking around verification. That last item is a genuine correctness issue that teams routinely get wrong when rolling their own.
• Sequenced rollout decisions. The package supports three distinct product bets, and you don't have to pick them all at once:
  • Enrollment-only (lowest risk). Add a "Passkeys / Security keys" panel to account settings. Passwords keep working, login path is untouched, and you get baseline enrollment numbers before committing. This is the recommended first release.
  • Progressive-enhancement login. Put Passkeys.verify() above the password form. One-line guest-page change, measurable lift on returning-user login.
  • Passwordless-first / password-optional. Only after enrollment reaches a threshold and you've built recovery. This is the decision the first two phases are designed to inform.
• Step-up authentication and sensitive-action confirmation. GET/POST /passkeys/confirm plus the documented GenerateVerificationOptions + VerifyPasskey pattern with an authenticated user lets you require a fresh passkey assertion before password change, payout, key rotation, or admin impersonation — without logging the user in again. For most products this replaces SMS OTP (weak, costly per-message, SIM-swap exposed) and is the strongest single justification for adoption.
• Account-takeover and support-cost reduction. Phishing-resistant credentials reduce credential-stuffing and reset-desk volume. Instrument PasskeyRegistered / PasskeyVerified / PasskeyDeleted and track: enrollment rate among active users, passkey-login share, reset-ticket volume per 1k MAU, and ATO incidents. Those four numbers are the business case and the go/no-go for phase three.
• Policy and compliance posture. Passkeys map cleanly onto internal security standards and enterprise security questionnaires ("do you support FIDO2 / phishing-resistant MFA?"). Passkeys::authorizeLoginUsing() gives you the compliance-critical gate — block suspended or banned accounts after a cryptographically valid assertion, which is exactly the check auditors ask about.
• Enterprise / admin surface hardening. management_middleware defaults to password.confirm on passkey add/delete, which is the right default for admin tooling. For internal dashboards and back-office apps, passkeys are arguably a stronger ROI than for consumer apps — smaller user base, higher blast radius per compromise, no recovery-funnel anxiety.

When to Consider This Package

Consider adoption when all of these hold:

• You're on Laravel with session-based auth on a standard guard. guard => 'web' is the default and the package assumes it; API-token or SPA-with-separate-auth-service architectures need more work than the README implies.
• You can ship the front-end half. This package is server-side only. It registers routes and verifies ceremonies; it ships no JS. You need a front-end or full-stack owner to wire @laravel/passkeys, prompt for a device name, and build the credential list/revoke UI.
• You can accept pre-1.0. v0.1.0 → v0.2.1, no major-version stability promise, 116 stars and zero dependents. That's an innovation-budget dependency, not a foundation one. Pilot behind a feature flag; don't put it on a contractual compliance deadline.
• Your users' schema is sane. The PasskeyAuthenticatable trait resolves display name as name → email → auth ID and username as email → auth ID. If you display handles, employee IDs, or tenant-scoped emails, budget an afternoon to override getPasskeyDisplayName() / getPasskeyUsername() — this string is what the OS account picker shows the user six months later with three devices registered.
• You own a recovery story. No passkey means no login. Fallback password, recovery codes, or a support-verified reset flow must exist before you enable passkey-only login.
• You've checked route collisions. Seven routes register silently under web, including GET /user/passkeys/options and DELETE /user/passkeys/{passkey}. If you own /user/*, audit with php artisan route:list. Passkeys::ignoreRoutes() exists if you need to take over routing.

Look elsewhere when:

• You need native mobile passkeys. No iOS/Android SDK here. ASAuthorizationPlatformPublicKeyCredentialProvider and Android Credential Manager integration are yours to build against the same endpoints — feasible, but it's a project, not a dependency.
• You want a managed identity provider. Auth0, WorkOS, Stytch, or Clerk bundle passkeys with recovery policy, cross-app federation, and an SLA. If auth is not your differentiator, that's a legitimate answer, and it's cheaper than owning recovery UX.
• You need SAML/SCIM/enterprise SSO in the same motion. Different problem; this package doesn't touch it.
• You require vendor support, SOC 2 artifacts, or a stable public API. Community-maintained (albeit in the first-party laravel namespace — which materially lowers abandonment risk, but doesn't create a support contract).
• Your security review requires auditable hardening you can't verify yourself. Do the diligence: user_handle_secret defaults to APP_KEY, so rotating APP_KEY silently invalidates every existing credential's user handle. Set PASSKEYS_USER_HANDLE_SECRET explicitly and treat it as rotation-sensitive — that's a config decision with a multi-year consequence.
• You need backup-eligibility or authenticator-attestation policy control beyond what the actions expose. The authenticatorSelection override (platform-only, resident key required) covers the common cases; anything more exotic means extending the actions and owning that code.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Passkeys replace passwords with Face ID, Touch ID, or a security key. This is a small, first-party Laravel package that lets us ship passkey sign-in in weeks rather than a quarter, and we can do it in stages so nothing about the current login flow changes until we choose to flip it. The upside is threefold: fewer account takeovers (passkeys are phishing-resistant — there's no secret to steal), fewer password-reset tickets (a real, measurable support cost), and a straight answer to the "do you support FIDO2?" question that now appears in enterprise security reviews. We recommend starting with enrollment in account settings — low risk, fully reversible, and it produces the data we need to decide whether to make passkeys a first-class login method.

For engineering — the assessment:

• Surface area is small and idiomatic. composer require, publish migrations, add PasskeyAuthenticatable + PasskeyUser to User, done. Seven routes register under web; three events fire (PasskeyRegistered, PasskeyVerified, PasskeyDeleted) so you can hook analytics and audit logging without forking.
• The hard parts are already done. WebAuthn ceremony logic, opaque user handles, AAGUID catalog, and — as of v0.2.0 — transactional verification with pessimistic locking and configurable management middleware (password.confirm by default). That locking change alone justifies not hand-rolling this.
• Every extension point we'd want exists. authorizeLoginUsing() for banned/suspended gating; GenerateVerificationOptions + VerifyPasskey for step-up auth without re-login; bindable actions (e.g. force platform authenticators + resident keys for true passkey UX); four response contracts; custom Passkey model; Passkeys::ignoreRoutes().
• What we own. The JS/browser integration and all UX — enrollment panel, device naming, credential list, revoke, and the recovery path. Plus explicit PASSKEYS_USER_HANDLE_SECRET config.
• What we accept. Pre-1.0, low external adoption, no published support commitment. Mitigation: feature-flag it, pin the version, and don't couple it to a compliance deadline. The laravel namespace is the main reason the abandonment risk is tolerable.
• Recommended sequence: (1) enrollment + management UI behind a flag, (2) passkey button above the password form as progressive enhancement, (3) revisit passwordless-first only with enrollment data in hand.