Native App Passkeys: Native vs. WebView Implementation

Modern mobile platforms give you two main approaches to integrate passkeys into an app: via fully native implementation or using a WebView embedded in the app. Let’s first clarify the differences and see how the two approaches compare in terms of user experience, security and development effort.

A native passkey implementation provides the best user experience, with authentication flows built directly into your app's UI. Users benefit from platform-native dialogs, seamless biometric verification and the fastest possible login times.

Platform Requirements for Native Passkeys:

Before diving into platform specifics, understand that native passkey integration requires cryptographic trust between your app and web domain. Without it, the OS will reject all WebAuthn operations. Both platforms require:

1. App-Domain Association Files:
   • iOS: Host apple-app-site-association at /.well-known/ with your Team ID and Bundle ID
   • Android: Host assetlinks.json at /.well-known/ with your app's SHA256 fingerprint
2. Correct Relying Party ID: Your WebAuthn RP ID must match your web domain (not an app:// URL)
3. Platform-Specific Capabilities:
   • iOS: Enable Associated Domains with webcredentials:yourdomain.com
   • Android: Declare association in your app's manifest

The benefit is that passkeys created on your website work in your app and vice versa.

Implementing passkeys natively on iOS involves Apple's AuthenticationServices framework, which provides an API for WebAuthn operations:

Key Components:

• ASAuthorizationController: Manages the authentication flow
• ASAuthorizationPlatformPublicKeyCredentialProvider: Creates passkey requests
• Three distinct UI modes to handle passkey logins:
  • Textfield login: Traditional username field with passkey login starting on button submit
  • Passkey modal overlay: OS dialog listing available passkeys
  • Conditional UI: Passkey suggestions in the QuickType bar above the keyboard

Development Tips

• AASA Caching: Apple caches the AASA file aggressively (up to 24 hours), which can frustrate testing. Solution: Enable Developer Mode on your test device and append ?mode=developer to your AASA URL to force fresh fetches
• Performance Testing: Test with iCloud accounts containing hundreds of credentials to observe real-world latency. The system overlay might show a slight delay with many stored passkeys
• Version-Specific Bugs: iOS 17.4 had a bug ignoring excludeCredentials (allowing duplicate passkeys). Fixed in 17.5, but highlights the need to test across iOS versions

Android's native passkey implementation uses the Credential Manager API (or the older FIDO2 API for backward compatibility):

Key Components:

• CredentialManager: Central API for all credential operations
• CreatePublicKeyCredentialRequest: For passkey registration
• GetCredentialRequest: For passkey authentication
• Two primary UI modes:
  • Textfield login: Traditional username field with passkey login starting on button submit
  • Passkey modal overlay: OS dialog listing available passkeys

Note: Android currently lacks iOS's Conditional UI keyboard suggestions in native apps (though Conditional UI works in web apps)

Implementing passkeys natively has important challenges and lessons learned: Integrating at the OS level can surface issues across different devices and OS versions.

1. For example, our team encountered issues like Apple's aggressive caching of the apple-app-site-association file (used for app/web credential linking) and subtle UI differences in certain Android OEM biometric prompts.
2. Moreover, consider that in some enterprise scenarios, managed devices may have passkey syncing disabled by policy. In corporate environments where iCloud Keychain or Google Password Manager sync is turned off, passkeys become device-bound and won't roam – an important scenario to plan for (e.g. ensuring users can still log in if they get a new phone).
3. Additionally, third-party credential manager apps can influence the flow. For instance, if a user has a password manager like 1Password set as an active credential provider, it will often intercept passkey creation and storage, taking priority over the platform's native credential manager.

While you can implement passkeys using raw platform APIs, purpose-built SDKs significantly accelerate development by handling WebAuthn complexity, edge cases and providing built-in telemetry. SDKs also offer mockable interfaces for unit testing (crucial since you can't test biometrics in simulators).

Recommendation: For native implementations, we recommend using the Corbado SDKs (iOS Swift Passkey SDK, Android Kotlin Passkey SDK) which handle the numerous edge cases discovered through production deployments, provide additional telemetry and testing.

When developing a mobile app, going fully native for passkeys is ideal for UX but it isn't always possible or practical, especially if you have to support existing authentication methods. In scenarios where your app still needs to accommodate password logins or federated SSO (e.g. an OAuth2-based workflow), a full native passkey integration may not cover all use cases. In such cases, using an in-app WebView to handle authentication can be a viable alternative. A WebView is essentially an embedded browser window within your app. It allows you to leverage web-based passkey flows (just as on a website) while keeping the user inside your app's UI shell.

WebViews act as a bridge, embedding your web login pages directly inside the app and providing a browser-like experience. This is particularly useful if your current solution already has a web-based login (with passwords or social logins) or if you rely on third-party IdPs. For example, if you are an OAuth2 provider or use SSO/social login providers like Google or GitHub, you often must handle those flows via web pages. In these cases, a WebView becomes necessary to display those web authentication screens. The WebView route ensures you can still introduce passkeys without rebuilding your entire auth stack natively – the web code (which could use WebAuthn JavaScript for passkeys) runs inside the WebView. The user experience is slightly less seamless (it feels more like a browser interaction), but it keeps all login methods in one place.

In essence, while native passkey implementations offer the most integrated experience, they require your app to be ready for a passwordless paradigm. WebView implementations provide flexibility and let you piggy-back on a web passkey flow inside the app. This is why many apps choose WebView as a stepping stone: it allows adding passkey support relatively quickly by reusing web logic, at the cost of a UX trade-off (the embedded browser context). Notably, major tech companies have taken this approach initially – for example, Google and GitHub added passkey login to their apps via WebView overlays on their existing web auth pages. This approach works well as an interim solution when a fully native rebuild of auth flows is not feasible upfront.

If you decide to implement passkeys via a WebView in your app, you'll need to choose the type of WebView carefully. Both iOS and Android offer multiple WebView components, each with its own characteristics. It's important to use a WebView that supports WebAuthn/passkeys properly and provides a good balance of security and user experience.

On iOS, you generally have three options for displaying web content in-app:

• WKWebView is a customizable WebView that is part of the WebKit framework (introduced in iOS 8). It gives you a lot of control over the web content's appearance and behavior.
• SFSafariViewController is a view controller provided by Apple that acts as a lightweight Safari browser within your app. It uses Safari's engine and shares Safari's data like cookies, keychain, etc., to provide a seamless experience.
• SFAuthenticationSession / ASWebAuthenticationSession are specialized web authentication sessions (available since iOS 11/12) intended specifically for OAuth/OpenID or other secure login flows. These also leverage Safari under the hood, but are focused on auth flows and automatically handle things like shared cookies and Single Sign-On (SSO).

On Android, the main choices are:

• Android WebView is the standard WebView widget (android.webkit.WebView), which is essentially a mini browser that can be embedded in your activities. It's highly customizable but runs in your app's process.
• Chrome Custom Tabs (CCT) is a feature that opens a Chrome-powered tab within your app context. Custom Tabs appear as part of your app but are powered by the Chrome browser (if installed) with features like pre-loading, shared cookies, and the familiar URL bar for user trust.

In the following sections, we'll delve a bit deeper into these WebView types for iOS and Android, and discuss which might be best suited for passkey authentication flows.

Apple's platform provides the three WebView options listed above. Your choice will affect how smoothly passkeys can be used inside the app:

For testing the different WebView behavior in iOS, we recommend the app WebView - WKWebView and UIWebView rendering.

WKWebView is a versatile WebView component for iOS. Developers can embed a WKWebView to render web content with a high degree of control over the UI and behavior. WKWebView uses the same rendering engine as Safari, so it's very performant and supports modern web features. In theory, WKWebView can handle WebAuthn (and thus passkeys) if configured correctly, but note that some advanced browser features might be restricted for security. One thing to watch out for is that WKWebView by default does not share cookies or keychain data with Mobile Safari. Users might have to log in afresh because their WebView session is isolated from Safari's session. Also, because WKWebView content can be fully customized by the app, the user doesn't see an address bar or Safari UI – which is great for branding, but it means the user has fewer cues to verify the page's legitimacy (a concern for anti-phishing). Some apps have even abused WKWebView to inject scripts or alter content (e.g. TikTok was noted to inject tracking JS via their in-app browser), so one must be careful to use WKWebView in a safe, user-trustworthy manner.

SFSafariViewController provides an in-app Safari experience. When you open a URL with SFSafariViewController, it's almost like opening it in the real Safari browser, except the user stays within your app's UI. The advantage for passkeys is huge: because it's essentially Safari, the user's iCloud Keychain, saved passkeys, cookies, and other Safari data are accessible. This means if the user already has a passkey for your site, Safari can find it and even display the Conditional UI autocomplete for easy login. SFSafariViewController is less customizable (you can't change its toolbar much), but it automatically handles a lot of security and privacy features. The URL bar is shown, complete with the padlock icon for HTTPS, which gives users confidence they're on the correct domain. In general, SFSafariViewController is considered more secure than a raw WKWebView and is simpler to implement (Apple provides it as a drop-in). The main trade-off is you sacrifice some control over the look & feel. For an authentication flow, that's usually acceptable. The priority here is security and ease of login, which SFSafariViewController excels at by using Safari's context.

SFAuthenticationSession / ASWebAuthenticationSession – These classes (the latter being the newer Swift-friendly name) are built specifically for login flows like OAuth or OpenID Connect. When you need to authenticate a user via a web page (perhaps to an external IdP), these sessions are the recommended choice on iOS. They are very similar to SFSafariViewController in that they utilize the Safari browser under the hood and share cookies/storage with Safari. The key difference is that SFAuthenticationSession will always prompt the user that the app wants to authenticate using a webpage (for user awareness) and it will automatically use the user's existing Safari session if available.

Ephemeral Mode Considerations: ASWebAuthenticationSession includes a prefersEphemeralWebBrowserSession property. When set to true, it creates an isolated browser session with no access to Safari's cookies or saved credentials. This is useful for sign-out flows or guest checkouts where you explicitly don't want SSO, but it means passkeys stored in iCloud Keychain won't be available. The trade-off: enhanced privacy vs. convenience. Most passkey implementations should keep this false (the default) to enable seamless authentication.

The benefit is a seamless SSO experience – if the user is already logged in to the provider in Safari, this session can use that cookie to avoid another login. For passkeys, this is important because it means any passkey credential stored in Safari/iCloud Keychain can be used here as well. Apple's official guidance is to use ASWebAuthenticationSession for anything that looks like a login flow. The pros are enhanced privacy (your app never sees the credentials or cookies, Safari handles it) and built-in SSO support. The con is that it's limited to auth flows (you wouldn't use it to just render arbitrary web content in your app). In summary, if your app falls into Group B (see Section 5) and you choose a WebView approach on iOS, ASWebAuthenticationSession is typically the best choice for implementing passkeys because it's secure, shares state with Safari (so passkeys work), and is purpose-built for authentication.

On Android, the WebView decision is between the classic WebView and Chrome Custom Tabs:

For testing the different WebView behavior in Android, we recommend the app WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) is a component that lets you embed web pages in your activity layout. It's similar to WKWebView in that it gives you full control: you can intercept navigation, inject JavaScript, customize the UI, etc. It also runs within your app's process. Using a WebView for passkeys means your app loads your web login page, and that page can initiate a WebAuthn passkey ceremony. Modern Android WebView does support WebAuthn (provided the device's WebView implementation is up to date via Android System WebView or the Chrome component). One major consideration: by default, an Android WebView does not share cookies or stored credentials with the user's Chrome browser. So any passkey created or used in the WebView might not be known to Chrome, and vice versa. This isolation can be good for security (your app can't read browser cookies), but it might force users to log in again if they've already authenticated in Chrome. Another issue is trust. A plain WebView doesn't show the URL or SSL lock icon, so users have to trust your app completely not to phish them. Google has even forbidden use of WebView for Google OAuth sign-ins due to potential phishing risks. Performance-wise, WebViews are fine, but they can be slower or more memory-intensive than using the user's default browser, especially if loading heavy pages.

Chrome Custom Tabs (CCT) are a hybrid approach. They allow your app to open a Chrome-rendered page that looks like it's part of your app. You can customize the toolbar color, add an app logo, etc., but the content is rendered by Chrome in a separate process. For passkeys, CCTs have several benefits: they share the user's cookies and credentials with Chrome, meaning if the user has a passkey saved via Chrome (Google Password Manager), the Custom Tab can access it. The user will also see the actual URL and security indicators, which builds trust. Performance is often better – Chrome can be "warmed up" in the background for faster loading. And importantly, security is strong: because it's essentially the Chrome app, things like Google Safe Browsing protect the session, and your app cannot inject arbitrary scripts into the page (preventing certain attacks).

2025 Update - Ephemeral Custom Tabs: Chrome now supports Ephemeral Custom Tabs via CustomTabsIntent.Builder().setShareState(CustomTabsIntent.SHARE_STATE_OFF). This creates an incognito-like session with no cookie persistence – useful for guest flows or explicit sign-outs. However, like iOS's ephemeral mode, this means stored passkeys won't be accessible. Use standard (non-ephemeral) Custom Tabs for passkey authentication to maintain access to saved credentials.

The downside is that it requires the user to have Chrome (or a supported browser) installed and up-to-date. Most Android users do, but on some devices in certain regions, this could be an issue. Overall, if you go with an embedded web approach on Android, Chrome Custom Tabs are recommended for passkey flows, as they provide a good balance of integration and security. In fact, they are analogous to iOS's SFSafariViewController/ASWebAuthSession in many ways – leveraging the default browser for auth.

(Aside: Apple's WKWebView vs SFSafariViewController and Android's WebView vs CCT have many parallels. Both Safari VC and Chrome Tabs share browser state and provide better security, whereas WKWebView/Android WebView give more control but isolate the web content. For passkeys, sharing state (cookies, credential stores) is usually desirable so that the passkey can be accessed and created seamlessly.)

Passkey behavior changes significantly on managed devices where Mobile Device Management (MDM) policies control credential storage. For a deep dive into testing passkeys on native apps and handling enterprise considerations, please refer to our dedicated articles:

• How to Test Passkeys in Native iOS and Android Apps
• Passkeys on Managed iOS & Android Devices: A Guide to Enterprise Testing

The best path for implementing passkeys depends heavily on your app's existing authentication architecture. The primary question to ask is: Does my app use a native login screen or a WebView-based login? Answering this will guide your implementation choice.

If your app already features a native login experience, it is best practice to also implement passkeys natively. This ensures a consistent, seamless and fast user experience. Users expect a native feel, and adding passkeys via the platform's native APIs meets that expectation.

For a new native app or a native-first app, going 100% passwordless with a native implementation is the ideal goal. While you can use the raw platform APIs (Apple's AuthenticationServices, Android's Credential Manager), we strongly recommend using the Corbado SDKs to accelerate development:

• Corbado iOS SDK: Wraps Apple's AuthenticationServices
• Corbado Android SDK: Handles Credential Manager complexity and multi-provider scenarios
• Benefits: Production-tested edge case handling, built-in telemetry, mockable testing interfaces

Using an SDK can reduce integration time from months to weeks, abstracting WebAuthn complexity while leveraging official platform APIs to deliver a simple biometric login that delights users.

If your app currently uses a WebView to handle user authentication, you can leverage this existing infrastructure to introduce passkeys. The first step is to add WebAuthn support to your web-based login flow. Then, ensure your app loads this flow using the correct type of WebView to enable passkey access:

• On iOS: Use ASWebAuthenticationSession. It shares cookies and credentials with Safari, allowing access to passkeys stored in the iCloud Keychain.
• On Android: Use Chrome Custom Tabs (CCT). It shares state with the user's Chrome browser, enabling access to passkeys stored in the Google Password Manager.

This approach allows you to roll out passkeys quickly with minimal changes to your native app's code.

While your current architecture is the main driver, your long-term strategy might differ if you're building a new app versus updating an existing one.

For New Apps: We strongly recommend building a native login from day one and implementing passkeys natively. This sets you up for the best possible user experience and avoids a future migration from WebView to native.

For Existing Apps (especially with WebView login): A phased migration can be a pragmatic approach.

• Phase 1: WebView Passkeys - Start by adding passkey support to your existing WebView-based login, as described above. Companies like Google and GitHub started here.
• Phase 2: Native Intercept - Enhance the experience by adding a native passkey check before showing the WebView. KAYAK's app exemplifies this: it attempts native passkey authentication first, falling back to the WebView only if needed. This provides a fast, biometric login for passkey users while maintaining backward compatibility.
• Phase 3: Full Native - Over time, you can aim to remove the WebView for passkey users entirely, keeping it only for legacy authentication methods or account recovery.

Key Requirements for a Hybrid or WebView Approach:

• Use ASWebAuthenticationSession (iOS) and Chrome Custom Tabs (Android) to ensure the WebView shares cookies and credentials with the system browser.
• Set up your app-domain association files (AASA/assetlinks.json) correctly. This is crucial for the native intercept in Phase 2.
• Test thoroughly with managed devices and third-party credential managers.
• Use the same Relying Party ID across your web and native platforms.

Finally, consider an opportunistic enrollment strategy. Some apps prompt users to create a passkey after they've successfully logged in with a traditional method like a password. For example, TikTok reportedly implemented a flow to "collect" a passkey post-authentication. If the user declines or their device doesn't support it, the app falls back silently. This allows you to gradually convert users to passkeys without a disruptive change to the login flow, making it a great strategy for existing applications.

Passkeys in native apps are used at scale in production. Deciding how to implement passkeys in your native app - via a pure native integration or an embedded WebView - is a crucial design choice that impacts security, user experience and development complexity. There is no one-size-fits-all answer.

If you can, go native sooner rather than later. A native passkey login offers the most seamless UX. With iOS and Android now providing first-class support for passkeys, and real-world successes demonstrating high adoption, the native approach is a proven best practice. The tooling (including open-source SDKs and platform libraries) has matured to make native integration achievable in reasonable time frames. And while you must be mindful of things like device management policies, cross-device sync, and third-party providers, these challenges can be managed with careful engineering and testing. The end result is an app login that delights users with its ease and speed, while significantly upping security.

On the other hand, if constraints require a WebView approach initially, that's perfectly valid. It enables you to support passkeys with minimal disruption, leveraging your existing web implementation. Just be sure to use the recommended WebView types (ASWebAuthenticationSession and Chrome Custom Tabs) to ensure compatibility with passkey autofill and security best practices.

Ultimately, passkeys in native apps represent a huge leap forward in both user convenience and security. Whether implemented via WebView or fully native, they eliminate phishing risks and password management burdens for your users. With careful planning (and the right partners or tools), you can offer passwordless, biometric logins in your app that truly realize the vision of passkeys: simple, safe and user-friendly authentication for everyone.

If passkeys aren't working in your native app, check these common issues:

Association File Issues:

• Files served over HTTPS with valid certificate
• Correct MIME type: application/json
• No redirects on .well-known path
• iOS: Team ID and Bundle ID match exactly
• Android: SHA256 fingerprint matches your signing certificate

Credential Manager Errors:

• iOS: Associated Domains capability enabled in Xcode
• Android: Digital Asset Links declared in manifest
• Relying Party ID matches your domain (no protocol, no port)
• User has screen lock enabled (biometric or PIN)

Third-Party Provider Issues:

• Check if user has non-default credential provider active
• Verify provider supports passkeys (not all do)

Origin Validation:

• WebAuthn origin for native: https://your-domain.com (not app://)
• No trailing slashes in RP ID
• Subdomain handling: RP ID "example.com" works for "auth.example.com"

For detailed debugging, see our article on Relying Party IDs in native apps.

Corbado Native SDKs:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

Platform Documentation:

• Apple: Supporting Passkeys
• Google: Credential Manager

Validation Tools:

• Apple AASA Validator
• Google Digital Asset Links Generator