Native App Passkeys: Native vs. WebView Implementation

1. Native App Passkey Implementation Choices

    1.1 Native Implementation: Great UX

    1.2 WebView Implementation: Browser-Like Experience

2. Overview WebView Options

3. WebViews in iOS

    3.1 WKWebView

    3.2 SFSafariViewController

    3.3 SFAuthenticationSession / ASWebAuthenticationSession

4. WebViews in Android

    4.1 Android WebView

    4.2 Chrome Custom Tabs (CCT)

5. Recommendation for Passkeys Implementation in Native Apps

6. Conclusion

1. Native App Passkey Implementation Choices

Authentication stands as the sentinel, safeguarding user data and ensuring secure interactions within native apps. The advent of passkeys has revolutionized this space, offering a robust and user-friendly authentication mechanism. There are two major ways to integrate passkeys into native app, either via native implementation or via WebView. Lets first have a look and see how the two ways compare.

1.1 Native Implementation: Great UX

A native implementation is often seen as providing the best user experience within an app. It's characterized by its smooth, integrated, and cohesive user interactions, tailored precisely to the operating systems environment, whether it be iOS or Android. The requirement for a 100% native implementation is to go 100% passwordless and be truly passkey-native. This approach frees you from the potential friction of transitioning between the native app and web content (displayed via a WebView).

1.2 WebView Implementation: Browser-Like Experience

When developing a native app, the path to go fully native is not always possible. In scenarios where you still need to support password-based utilizing OAuth2, a full native integration may not be feasible, making WebView implementations the only viable alternative. WebView acts as a bridge, embedding web content directly within your app, providing a browser-like UX while navigating through web pages. This is particularly pertinent if you are an OAuth2 provider yourself, your underlying authentication solution is OAuth2-based or if your login solution uses social logins via third parties, such as Google or GitHub. In these cases, employing a WebView becomes inevitable due to the necessity of interacting with web content and managing various user authentication flows, especially when native app associations are required.

In essence, while native implementations offer an unparalleled, smooth user experience, they may not always be a viable option, especially when coupled with password-based or OAuth2-based authentication solutions. On the other hand, WebView implementations provide a flexible, albeit slightly less seamless, pathway to integrate web content and manage user authentication within your app, ensuring you can navigate the complexities of various authentication flows and third-party logins.

The next sections of this article focus on the implementation via WebView. To learn more about native passkey integration, please see here.

2. Overview WebView Options

Navigating through the labyrinth of authentication in native apps, developers and product managers encounter a pivotal decision: to implement passkey authentication natively or via WebView. If decided for the latter, both iOS and Android platforms offer two distinct kinds of WebViews, each with its unique attributes and potential use cases.

iOS WebViews:

• WKWebView
• SFSafariViewController
• SFAuthenticationSession / ASWebAuthenticationSession (specifically tailored for OAuth / OpenID Connect-based authentication flows)

Android WebViews:

• WebView
• Chrome Custom Tabs (CCT)

In the following sections, we delve deeper into these WebView types and ultimately guiding you towards an informed decision on which WebView to employ for passkey authentication in your native apps (if pure native implementation is no alternative).

3. WebViews in iOS

iOS WebViews are either WKWebView or SFSafariViewController (if working with OAuth / OIDC, its SFAuthenticationSession / ASWebAuthenticationSession).

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

3.1 WKWebView

WKWebView is a powerful and versatile WebView option available for iOS developers. Introduced with iOS 8, it allows developers to embed web content directly within an app, providing a wide array of customization and configuration options. WKWebView is renowned for its performance, utilizing the same web rendering engine as Safari, and offering a rich set of APIs for interacting with web content, managing navigation, user interactions, and more.

3.2 SFSafariViewController

SFSafariViewController is a WebView that allows developers to leverage Safaris capabilities directly within their apps. It provides a seamless user experience by utilizing the users Safari settings, such as saved passwords, passkeys, cookies, and more, ensuring consistent web browsing, because it actually runs as Safari application. SFSafariViewController is not as customizable as WKWebView but offers enhanced security features and ease of use, making it a preferred choice for displaying straightforward web content within apps.

3.3 SFAuthenticationSession / ASWebAuthenticationSession

SFAuthenticationSession and ASWebAuthenticationSession are WebViews specifically tailored for OAuth / OpenID Connect-based authentication flows. They provide a secure and isolated space for user authentication, safeguarding user credentials and ensuring that private information is not inadvertently shared with the app. These sessions share cookies and website data with Safari, providing a consistent and seamless user experience, especially during authentication processes.

Pros:

• Dedicated Authentication: Specifically designed for OAuth / OpenID Connect-based authentication flows, ensuring a streamlined authentication process.
• Privacy Protection: Ensures user data privacy by not sharing cookies or website data with the app.
• SSO Support: Supports Single Sign-On, providing a convenient user experience.

Cons:

• Limited Use Case : Primarily focused on OAuth / OpenID Connect authentication, which might not be suitable for all use cases.

When the primary task is user authentication, especially when implementing SSO or interacting with OAuth providers, you should use SFAuthenticationSession / ASWebAuthenticationSession instead of SFSafariViewController.

4. WebViews in Android

Android WebViews are either WebView or Chrome Custom Tabs (CCT). For testing the different WebView behavior in Android, we recommend the app WebView vs Chrome Custom Tabs.

4.1 Android WebView

WebView on Android is a comprehensive component that allows developers to display web content as part of the apps UI. It is versatile, offering a wide range of customization options and providing developers with the flexibility to configure the WebView to suit various needs. WebView provides a rich set of APIs for interacting with web content, managing user interactions, and even handling JavaScript dialogs, client certificates, and permission requests.

4.2 Chrome Custom Tabs (CCT)

Chrome Custom Tabs (CCT) offers a seamless, secure, and efficient way to integrate web content directly into your app. By leveraging Chromes capabilities and security features, CCT provides a user experience that is both consistent and high-performing.

CCT is a component of the Chrome browser, designed to integrate with the Android framework, allowing apps to open web content in a lightweight, dedicated process. Notably, it opens faster than a conventional browser and, when preloaded via its warm-up call, potentially outperforms a WebView. While it executes JavaScript, it operates in its own process, safeguarding apps from running malicious code. Moreover, CCTs UI provides an action bar, displaying the URL and an SSL verification lock icon for secure pages, thereby reassuring users of the authenticity and security of the page being loaded.

In general, one can say that iOS WKWebView and Android WebView , as well as SFSafariViewController and Chrome Custom Tabs (CCT) are similar.

5. Recommendation for Passkeys Implementation in Native Apps

Our customers contiously ask us about how passkeys should be implemented in native apps. Largely those customers can be divided into different groups:

Group A:

Customers who start building their native app from scratch and can directly use our passwordless authentication (no legacy passwords exits).

Group B:

Customers with existing users and an existing authentication solution. Often they also have already an existing web app that also needs to add passkeys into its authentication process. Here many companies decide to go a two-step process:

1. Add passkeys to your existing WebView authentication flow (thats how Google and GitHub implemented it in their native apps)
2. Add passkeys via native implementation on top. This native passkey implementation checks before the old WebView (e.g. for social logins and passwords) if the user can login with a passkey (thats how KAYAK implemented it in their native app).

Determine your Group

To provide your users with the best passkey implementation in a native app, you need to decide to which group you belong, based on your current technical setup and how you want to push passkeys (this question is relevant for companies in group B).

Recommendation for Group A: Native Implementation

If youre building an entirely new app (group A), we recommend to go with a native passkey implementation and go completely passwordless right away (so no kind of WebView is used). Please use the native SDKs & APIs for iOS and Android (e.g. via the passkeys Flutter package). Please also read this article about Relying Party IDs.

Recommendation for Group B: First WeView, then Native Implementation

If you cannot natively implement passkeys today for whatever reason (group B), you can start with a WebView implementation and then also move in the future to a native passkey implementation (this works via the creation of association files, like apple-app-site- association for iOS apps and assetlinks.json for Android apps). Reasons to go with WebView implementation might include:

• You offer OAuth2-based authentication already and want to keep offering it to your users (OAuth2 doesnt work natively, see the standard here)
• You want to offer passkey authentication in the same window / screen, where you offer your other authentication methods (e.g. passwords, social logins, OAuth2)

This is the way that Google or GitHub have implemented passkey authentication in their native apps currently. Please see the recommendation below for setting up WebViews correctly for passkey authentication. However, we recommend to consider a native passkey implementation like KAYAK did and start directly with step 2.

If you belong to group B and cannot implement passkeys natively, our recommendation leans towards utilizing SFAuthenticationSession / ASWebAuthenticationSession for iOS and Chrome Custom Tabs for Android (otherwise passkeys will not work anyways).

In the following, we state the reasons for this recommendation:

1. Shared Cookies & Data with Browser:

SFAuthenticationSession / ASWebAuthenticationSession share cookies and website data with Safari, providing a seamless user experience during authentication processes. The same applies for Chrome Custom Tabs on Android.

Users benefit from their saved passwords, auto-fill data, and other stored information in the browser, making the authentication process smoother and faster.

2. Enhanced Security:

SFAuthenticationSession / ASWebAuthenticationSession on iOS and Chrome Custom Tabs on Android provide a secure and isolated space for user authentication, ensuring that sensitive user credentials are safeguarded and not inadvertently shared with the app or other websites.

They adhere to Apples and Googles stringent security protocols, ensuring that user data is handled securely and privacy is maintained.

Moreover, this design choice benefits from Safaris and Chromes ongoing security updates and enhancements, ensuring that it adheres to the latest security standards and protocols.

3. User Experience:

SFAuthenticationSession / ASWebAuthenticationSession on iOS and Chrome Custom Tabs on Android provide a consistent and familiar user interface, as users are accustomed to the browsers user experience. Besides, Safaris and Chromes user settings and preferences are applied.

It provides a smooth transition between app content and web content, ensuring that users are not jarred by the shift between interfaces.

4. Performance:

Chrome Custom Tabs leverage Chromes performance, ensuring a smooth and responsive user experience, which is particularly crucial during authentication processes to prevent user frustration or abandonment.

The performance of CCT is often superior to Android WebView options (same with SFAuthenticationSession / ASWebAuthenticationSession on iOS), ensuring that web content and authentication flows are handled swiftly and smoothly.

See also this comparison by Google to feel the performance differences betweenChrome Custom Tabs , Android WebView and the standard Chrome browser .

5. Dedicated for Authentication Flows:

SFAuthenticationSession / ASWebAuthenticationSession is specifically designed to handle OAuth / OpenID Connect-based authentication flows, ensuring a streamlined and secure process for these widely-used authentication protocols. Its also the recommended way for WebAuthn / passkey authentication.

On Android, there is no dedicated class for authentication flows but similar behavior can be implemented with Chrome Custom Tabs and Android App Links.

Furthermore, we expect more apps to introduce passkeys like TikTok by just collecting them when the user is authenticated. This can be done natively (TikToks implementation) or via a WebView implementation. A suitable approach is to trigger Conditional UI natively. If it does not work, you display the WebView implementation.

6. Conclusion

In the modern landscape of digital authentication, the implementation of passkeys via WebView in native apps emerges as a beacon of secure and user- friendly practice. While the journey through choosing the optimal WebView might be intricate, it is pivotal to align technological choices with user experience and security.