On the open web, a passkey tap opens the system authenticator and signs you in. Inside an embedded WebView that same flow is the one that breaks: WebAuthn depends on browser and platform capabilities the WebView does not reliably provide, and passkeys are scoped to the host app's domain, not yours. A host-owned runtime bridges the device's native authenticator — one API that signs in on every engine.
Android: WebView does not support WebAuthn
Authoritative integration guides are explicit: Android's System WebView "doesn't support WebAuthn," and FIDO on Android depends on Google Play Services reaching the page. Inside an embedded WebView the ceremony has no guarantee of a platform authenticator, so navigator.credentials.create() and .get() may throw or silently do nothing. Even where the underlying engine could support it, the host app — not a real browser — controls the WebView, so the full passkey ceremony that Safari or Chrome performs is not assured. The Yubico compatibility matrix confirms the picture: on Android, FIDO support is delivered by Google Play Services, not by the WebView component itself.
iOS: navigator.credentials is missing in WKWebView
On iOS the situation is sharper. Developer reports and passkey guides show that navigator.credentials is only available in SFSafariViewController and ASWebAuthenticationSession, not in the WKWebView that most apps embed — calling it produces "WebAuthn not implemented on iOS." Worse, passkeys inside a WKWebView are scoped to the host app's Associated Domains, not your relying-party domain: a user who arrives at your site inside Instagram or TikTok cannot use your passkeys because the WebView is bound to their domain, not yours. Conditional UI — the passkey autofill that surfaces credentials in the username field — is also not supported inside a WebView.
What breaks when passkeys die
- Passwordless login dead-ends. The fast, phishing-resistant sign-in you lean on is the one that fails inside the in-app browser.
- Security-key MFA fails. WebAuthn second factor and discoverable credentials never start.
- Users fall back to passwords and OTP. The slowest, most abandon-prone routes become the only ones.
- Failures are invisible. A ceremony that never starts leaves no server call, so analytics shows an unexplained abandon, not an error.
The runtime fix
A host-owned runtime bridges the device's native authenticator. The page calls one uniform API — runtime.createPasskey() and runtime.authenticateWithPasskey() — and the host drives Android's FIDO2 / Play Services and iOS's ASAuthorizationPlatformPublicKeyCredentialProvider (or opens an ASWebAuthenticationSession for the auth step). Associated Domains the host controls bind the passkey to your site. One integration, every engine, a real hardware-backed sign-in.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| WebAuthn API | Missing / inconsistent | Uniform bridge |
| Android path | WebView has no WebAuthn | FIDO2 / Play Services |
| iOS path | WKWebView: navigator.credentials absent | Native ASAuthorization |
| Domain binding | Host app, not your site | Host-controlled Associated Domains |
| Conditional UI | Not in WebView | Native |
| Observability | Silent client fail | Backend-visible |
A native app signs in with a passkey on every device. A stock WebView signs in on almost none. A runtime gives the page one authenticator — and a real, hardware-backed login at the end of it.
Sources
- Corbado — Passkeys in In-App Browsers: why logins break — embedded WebViews give inconsistent WebAuthn; conditional UI unsupported; passkeys scoped to the host app; analytics blind.
- AgeKey docs — Mobile apps — explicitly: Android WebView and iOS WKWebView "don't support WebAuthn"; use Custom Tabs /
ASWebAuthenticationSession. - Stack Overflow — Ionic/Capacitor passkey on iOS —
navigator.credentialsonly inSFSafariViewController/ASWebAuthenticationSession, not WKWebView ("WebAuthn not implemented on iOS"). - Yubico — WebAuthn compatibility matrix — FIDO on Android requires Google Play Services; support is not uniform across engines.
- Google — Android FIDO2 API attestation change — Android FIDO2 / passkeys depend on Play Services; SafetyNet → hardware-backed key attestation (2025).
