Passkey Login: One-Tap

Users logging in via desktop and mobile browsers follow a standard login flow enriched by the One-Tap passkey experience, leading to higher login rates on trusted devices.

One-Tap is different from the common “Sign in with passkey” button that simply starts the authentication ceremony without checking whether a passkey is available. Those naive buttons often fail and frustrate users. One-Tap uses Passkey Intelligence to show the button only when a passkey is likely available making it a smart, passwordless, and usernameless login path.

Feature documentation: For implementation and configuration details, see the Corbado Connect One-Tap Login documentation.

Users log in via One-Tap

Passkey Intelligence determines the user is likely to have a passkey available on this platform. User taps “Login with Passkey” button on the login screen to start authentication.
The button displays an account hint, for example “Log in as alice@example.com”, so the user can identify the intended account.

System passkey sheet appears

The browser or operating system directly presents the applicable passkey authentication surface. There’s no further selection or click required.
User verifies their identity using their screen lock (e.g., fingerprint, PIN, or face recognition).
User verification happens locally on the device; only a signed assertion is sent to your server, and no shared secret ever leaves the device.

Access granted

User is seamlessly logged in and redirected to the dashboard.

Technical Considerations

Device-scoped availability evidence

The One-Tap Login button appears intelligently based on:

Prior first-party evidence: Whether the user previously created or used a passkey in this browser context
Browser support: Automatic detection of WebAuthn compatibility
Session history: Recognition of the last used account on the device

Edge Cases and Fallbacks

Multiple accounts on the same device

When multiple accounts exist on a device, the One-Tap button defaults to the most recently used account. Provide a dropdown or “Use another account” option for switching accounts.

First-time device access

On a new device, users complete the standard authentication flow. After successful passkey creation or use, One-Tap may become eligible on later visits while sufficient device-scoped evidence remains available.

Passkey unavailable scenarios

If a passkey becomes unavailable (e.g., deleted by user, browser issues), the system gracefully falls back to alternative authentication methods without user confusion.

Acceptance criteria

Benchmark as	User reach
Strategy	High

ID	Level	Acceptance criterion	How to verify
W1.1-AC01	Core	Show One-Tap only after the user has successfully created or used a passkey for this account in the current browser profile. Any successful creation entry point counts, including passkey management. Opening or cancelling creation, or creating a credential that the server fails to register, does not count.	Complete passkey creation from account management and every other supported creation entry point, then complete a passkey login. Each successful server registration or login makes One-Tap eligible. Cancellation, failed server registration, a new browser profile, cleared site data and server-known revocation do not. If a credential is deleted only inside a provider, a stale offer may remain because the application cannot know about that deletion; the user must still reach a safe fallback.
W1.1-AC02	Core	Show enough account information for the user to recognize the intended account. Apply masking where required, but keep different accounts distinguishable. The hint alone cannot enable login without a valid passkey assertion.	Use two accounts in one browser profile and each configured masking mode. Confirm that the hints remain distinguishable and that neither hint can authenticate without a valid assertion for the intended account.
W1.1-AC03	Core	The One-Tap hint selects the account, not one specific credential. Every active passkey accepted for that account remains eligible, so the user can complete login with any available passkey.	Create several active passkeys for one account across the supported providers and devices. Inspect the request and complete One-Tap login with each passkey, including supported cross-device routes. No active credential is pinned or omitted.
W1.1-AC04	Core	Treat browser-stored account state only as an account hint; it never authenticates the user or bypasses assertion verification.	Modify, forge and delete the stored hint, then attempt login without a valid assertion. No state change should grant access.
W1.1-AC05	Core	Provide a directly reachable “Use another account” or equivalent path before authentication.	Render One-Tap for one account and switch to a second account without completing the first account’s ceremony. The second account’s normal login path should be usable.
W1.1-AC06	Core	Do not open a passkey prompt before the user activates the One-Tap action.	Load and focus the login page without activating One-Tap. No modal credential request should appear.
W1.1-AC07	Core	Bind a returned assertion to the intended account independently of the browser-stored account hint.	Attempt to complete the ceremony with a credential belonging to another account and with a modified hint. Neither case may authenticate as the intended account.
W1.1-AC08	Core	The One-Tap entry state does not show or require an identifier field. The user can start passkey login for the hinted account directly, while “Use another account” opens the normal identifier flow.	Render One-Tap for an eligible account. Confirm that its passkey action starts the ceremony directly and that “Use another account” opens identifier entry without first starting a passkey request.
W1.1-AC09	Core	After the user cancels or aborts One-Tap, the product does not open another passkey prompt automatically. It either shows the identifier flow with the available fallback choices or proceeds directly to the configured fallback for the hinted account.	Cancel the One-Tap ceremony on the first and a repeated attempt. Confirm that no new ceremony starts automatically and that the configured identifier-first or direct-fallback route remains usable.
W1.1-AC10	Quality	Include stored transport hints with each account-scoped credential descriptor when available. They help the browser offer suitable routes after One-Tap is activated, such as phone/QR for `hybrid` or a security key for `usb` or `nfc`. Keep the One-Tap icon generic because all active passkeys remain eligible and the stored transports do not identify which route or password manager will be used.	Register credentials with different recorded transports and inspect the generated request options. Each descriptor retains its stored values, while the One-Tap action does not present itself as a specific security-key, phone or password-manager route.

References

Relevant criteria: W1.1-AC03, W1.1-AC04, W1.1-AC06–W1.1-AC10. Web Authentication: An API for accessing Public Key Credentials: Level 3 defines authorization gestures, account-scoped requests, credential descriptors and transports, account binding and server-side assertion verification.
Relevant criteria: W1.1-AC01–W1.1-AC02, W1.1-AC05–W1.1-AC06, W1.1-AC08–W1.1-AC09. One-Tap Login: Seamless Passkey Authentication documents the returning-user pattern, recognizable account hint, explicit activation, account switching and the route back to normal login; it supports the flow shape, not a vendor requirement.
Relevant criteria: W1.1-AC01. How to get high passkey adoption in login flows provides practical guidance for eligibility-driven presentation. Its reported rates provide context, not acceptance thresholds.
Relevant criteria: W1.1-AC09. Passkey fallback and recovery supports deliberate fallback after a cancelled passkey attempt without automatic reprompting.

Overview

Web

Native

Technical Considerations

Device-scoped availability evidence

Edge Cases and Fallbacks

Acceptance criteria

References

​One-Tap Login Flow

​Technical Considerations

​Device-scoped availability evidence

​Edge Cases and Fallbacks

​Acceptance criteria

​References

One-Tap Login Flow

Technical Considerations

Device-scoped availability evidence

Edge Cases and Fallbacks

Acceptance criteria

References