Usernameless and Cross-Device Passkey Sign-In

Overview#

Requiring users to type their email before offering passkey sign-in defeats the convenience and phishing resistance of passwordless authentication. Discoverable credentials (usernameless passkeys) let users tap a biometric or security key without entering any identifier, and seamlessly enrol new devices by scanning a QR code with their phone. Users stay secure, because the server still resolves their account from the signed assertion and verifies the signature, while the experience becomes friction-free and defence in depth.

The platform implements FIDO2 discoverable credentials with full support for platform authenticators (Touch ID, Windows Hello, Android biometrics), USB security keys, and cross-device QR flows. All challenge endpoints are rate-limited to prevent enumeration attacks and timing side-channels.

Key Features#

• Usernameless Sign-In: Users authenticate without typing email or username. The server resolves their account from the signed assertion's userHandle, keeping phishing resistance intact (ASVS V2.7.1, FIDO2 Level 2).

• Discoverable Credentials: Registration marks passkeys as discoverable (resident key) so the authenticator surfaces them without an allow-list. Users see every registered passkey plus the platform's "use a phone" hybrid flow.

• Cross-Device Passkey Enrolment: Users can add a passkey from a different device by initiating registration on the web, scanning a QR code with their phone, and confirming on the phone. Error messages guide users to try a different device if they accidentally tap the wrong authenticator.

• Hybrid Authentication Flow: Users can choose to authenticate locally (platform biometric) or use their phone as a roaming authenticator, scanning a QR code on desktop without leaving the browser or app.

• Rate-Limited Challenge Endpoints: Passkey challenge generation endpoints (generate-authentication, generate-authentication-discoverable, generate-authentication-from-challenge) enforce per-minute limits (5 to 10 requests) to prevent enumeration and timing attacks on user accounts.

• User-Centric Error Handling: InvalidStateError when a credential is already registered is translated to actionable guidance ("use a different device / scan QR") rather than exposing raw errors.

Use Cases#

Privileged Operators#

High-clearance users and administrators authenticating to sensitive systems (classified operations centres, financial trading, healthcare incident response) benefit from zero-friction phishing-resistant login. Passkey-only sign-in with no email entry reduces typos, social-engineering vectors, and audit friction.

Multi-Device Teams#

Field staff, first responders, and remote analysts often work across multiple devices (laptop, tablet, phone). Usernameless passkey enrolment lets them add security to their phone while sitting at a workstation, enabling quick backup authentication without manually syncing credentials or managing email recovery codes.

Self-Service Device Management#

Users can independently add a new device by scanning a QR code; no administrator intervention or email confirmation is needed. The UX is identical across Windows, macOS, iOS, and Android.

Integration#

Clients initiate usernameless sign-in by calling /v1/portal/mfa/passkey/generate-authentication-discoverable with no email parameter. The server returns WebAuthn options with an empty allow-list of credentials, prompting the browser to offer every discoverable credential and the hybrid "use a phone" option.

The user authenticates locally or scans a QR code. The assertion's userHandle (set to the user ID during registration) is sent to the server. The /v1/portal/mfa/passkey/verify-authentication endpoint decodes the userHandle, resolves the user, and verifies the assertion signature against their stored credential public key in a single atomic operation. The challenge is single-use and server-side storage is consumed at verification, preventing replay.

Cross-device passkey enrolment follows the standard WebAuthn registration flow with an additional UX step: if the user triggers a credential on a device where they already have a passkey (InvalidStateError), the client catches the error and suggests scanning a QR code with a different device instead of showing the raw error.

Rate limiting is enforced at the HTTP middleware layer via @limiter.limit("5/minute") on challenge endpoints, returning 429 Too Many Requests when the quota is exceeded. This protects against account enumeration (attackers probing which emails have passkeys) and timing side-channels in challenge generation.

Open Standards#

• W3C Web Authentication (WebAuthn) Level 2: The capability is built entirely on the W3C WebAuthn specification, implementing discoverable credentials (resident keys), empty allowCredentials for usernameless flows, userHandle-based account resolution, attestation object verification, and per-origin relying-party binding.
• FIDO2 / CTAP2 (FIDO Alliance Client-to-Authenticator Protocol 2): CTAP2 governs how browsers communicate with platform authenticators (Touch ID, Windows Hello, Android biometrics), USB security keys, and the hybrid cross-device transport that enables QR-based passkey enrolment from a second device.
• CBOR Object Signing and Encryption (COSE / RFC 8152): Authenticator attestation objects and public key structures within WebAuthn are encoded in COSE/CBOR; the service parses these via the cbor2 library and accepts COSE algorithm identifiers including ES256 (-7), RS256 (-257), and EdDSA (-8).
• NIST SP 800-63B (Digital Identity Guidelines): Challenge endpoints and user-verification requirements are designed to meet Authenticator Assurance Level 2 and AAL3 posture, with per-minute rate limits and required user verification aligning to NIST SP 800-63B-4 guidance on phishing-resistant authentication.
• OWASP Application Security Verification Standard (ASVS) V2.7.1 / V6: User-verification enforcement on all passkey flows (resident key, discoverable, and cross-device) is directly gated by ASVS V2.7.1 and V6.5.7 requirements, rejecting any assertion whose authenticator-data UV bit is clear.
• RFC 9068 (JSON Web Token Profile for OAuth 2.0 Access Tokens): After successful passkey assertion verification the service issues an RS256-signed access token with the at+jwt typ header and standard claims (iss, sub, iat, exp, jti) in conformance with RFC 9068.
• RFC 7517 / JSON Web Key Set (JWKS): The public keys used to verify the session JWTs issued after passkey authentication are published at the OIDC-standard JWKS endpoint in RFC 7517 format, enabling relying parties to validate tokens independently.

Security & Compliance#

• Credential Binding: Passkeys are bound to the relying party identifier (RP_ID / origin) so credentials registered for one service cannot be misused on another, preventing cross-site attacks.

• User Verification Required: All discoverable credential flows enforce user verification (biometric, PIN, or platform unlock) so theft of an unlocked phone does not grant access without the user's active consent.

• Challenge Reuse Prevention: Each challenge is generated once, stored server-side with a 5-minute TTL, and consumed after verification. Attackers cannot replay a valid assertion.

• Usernameless User Resolution: The userHandle field is decoded from the assertion but NOT trusted on its own. The assertion signature is always verified against the resolved user's stored credential public key before issuing a session token.

• Rate Limiting: All passkey challenge endpoints enforce per-minute rate limits to prevent enumeration (detecting which email addresses have passkeys), timing attacks on challenge generation, and brute-force attacks on assertion verification.

• Standards Alignment: FIDO2 Level 2 certification, NIST 800-63B AAL3, PCI DSS SCA. Audit logs record every passkey action (generation, verification success/failure, user resolution, rate-limit hits) with configurable retention.

Availability#

• Enterprise Plan: Included
• Professional Plan: Available as add-on

Last Reviewed: 2026-05-27 Last Updated: 2026-05-27