ネイティブアプリのパスキー：ネイティブ実装とWebView実装の比較

この記事では、ネイティブアプリ（iOS + Android）にパスキーを実装する方法を解説します。パスキー認証に推奨されるWebViewの種類についても学べます。

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. ネイティブアプリにおけるパスキー実装の選択肢#

認証は、ユーザーデータを保護し、ネイティブアプリ内での安全なやり取りを保証する番人のような存在です。パスキーの登場は、この分野に革命をもたらし、堅牢でユーザーフレンドリーな認証メカニズムを提供しています。ネイティブアプリにパスキーを統合するには、ネイティブ実装とWebView経由の2つの主要な方法があります。まず、この2つの方法を比較してみましょう。

1.1 ネイティブ実装：優れたUX#

ネイティブ実装は、アプリ内で最高のユーザーエクスペリエンスを提供すると見なされることが多いです。iOSであれAndroidであれ、オペレーティングシステムの環境に正確に合わせた、スムーズで統合された、一貫性のあるユーザーインタラクションが特徴です。100%ネイティブ実装の要件は、100%パスワードレス化し、真にパスキーネイティブになることです。このアプローチにより、ネイティブアプリと（WebView経由で表示される）ウェブコンテンツ間を移行する際の潜在的な摩擦から解放されます。

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 WebView実装：ブラウザライクな体験#

ネイティブアプリを開発する際、完全にネイティブ化する道が常に可能とは限りません。パスワードベースの認証をOAuth2を利用してサポートし続ける必要があるシナリオでは、完全なネイティブ統合は現実的ではない場合があり、WebView実装が唯一の実行可能な代替案となります。WebViewは橋渡し役として機能し、ウェブコンテンツをアプリ内に直接埋め込み、ウェブページをナビゲートしながらブラウザのようなUXを提供します。これは、自身がOAuth2プロバイダーである場合、基盤となる認証ソリューションがOAuth2ベースである場合、またはログインソリューションがGoogleやGitHubなどのサードパーティ経由のソーシャルログインを使用している場合に特に重要です。これらのケースでは、ウェブコンテンツとの対話や様々なユーザー認証フローの管理、特にネイティブアプリの関連付けが必要な場合に、WebViewの採用が不可欠となります。

要するに、ネイティブ実装は比類のないスムーズなユーザーエクスペリエンスを提供しますが、特にパスワードベースやOAuth2ベースの認証ソリューションと組み合わせる場合には、常に実行可能な選択肢とは限りません。一方、WebView実装は、ウェブコンテンツを統合し、アプリ内でユーザー認証を管理するための、柔軟ではあるものの、ややシームレスさに欠ける経路を提供し、様々な認証フローやサードパーティログインの複雑さを乗り越えることを可能にします。

この記事の次のセクションでは、WebView経由の実装に焦点を当てます。ネイティブのパスキー統合について詳しく知りたい場合は、こちらをご覧ください。

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

2. WebViewオプションの概要#

ネイティブアプリにおける認証の複雑な世界をナビゲートする中で、開発者やプロダクトマネージャーは、パスキー認証をネイティブで実装するか、WebView経由で実装するかという極めて重要な決定に直面します。後者を選択した場合、iOSとAndroidの両プラットフォームは、それぞれ独自の特徴と潜在的なユースケースを持つ2つの異なる種類のWebViewを提供します。

2.1 iOSのWebView#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession（特にOAuth / OpenID Connectベースの認証フロー向けに調整）

以下のセクションでは、これらのWebViewタイプをさらに深く掘り下げ、最終的に、ネイティブアプリでパスキー認証にどのWebViewを採用すべきかについて、情報に基づいた決定を下すための指針を示します（純粋なネイティブ実装が代替案でない場合）。

Subscribe to our Passkeys Substack for the latest news.

3. iOSのWebView#

iOSのWebViewは、WKWebViewまたはSFSafariViewControllerのいずれかです（OAuth / OIDCを扱う場合は、SFAuthenticationSession / ASWebAuthenticationSessionとなります）。

iOSでの異なるWebViewの動作をテストするには、アプリ「WebView - WKWebView and UIWebView rendering」をお勧めします。

3.1 WKWebView#

WKWebViewは、iOS開発者向けに提供されている強力で多機能なWebViewオプションです。iOS 8で導入され、開発者はウェブコンテンツをアプリ内に直接埋め込むことができ、幅広いカスタマイズと設定オプションを提供します。WKWebViewは、Safariと同じウェブレンダリングエンジンを利用することでそのパフォーマンスで知られており、ウェブコンテンツとの対話、ナビゲーションの管理、ユーザーインタラクションなどのための豊富なAPIセットを提供します。

3.2 SFSafariViewController#

SFSafariViewControllerは、開発者がSafariの機能をアプリ内で直接活用できるWebViewです。保存されたパスワード、パスキー、Cookieなど、ユーザーのSafari設定を利用することでシームレスなユーザーエクスペリエンスを提供し、実際にはSafariアプリケーションとして実行されるため、一貫したウェブブラウジングを保証します。SFSafariViewControllerはWKWebViewほどカスタマイズ可能ではありませんが、強化されたセキュリティ機能と使いやすさを提供し、アプリ内で単純なウェブコンテンツを表示するための好ましい選択肢となっています。

	WKWebView	SFSafariViewController
ユーザーエクスペリエンス	- ネイティブ感：開発者がアプリのデザインに合わせてルック＆フィールをカスタマイズできるため、ユーザーはウェブコンテンツがアプリのネイティブな一部であると感じるかもしれません。 - 自動入力： Safariからのデータによる自動入力が可能です。	- シームレス：ユーザーのSafari設定を使用し、ネイティブアプリとブラウザ間で一貫したウェブブラウジングを保証するシームレスなユーザーエクスペリエンス。
開発者エクスペリエンス	- 高度にカスタマイズ可能：広範なカスタマイズと設定が可能。 - 柔軟：ウェブコンテンツと対話するための多くのAPI。	- 中程度のカスタマイズ性：特にWKWebViewと比較して、カスタマイズオプションが限られています。 - シンプル： WKWebViewと比較して実装が簡単です。
パフォーマンス	- 比較的遅い：実装やウェブコンテンツによっては、読み込み速度を最適化できますが、カスタム機能やインタラクションの追加処理のため、SFSafariViewControllerに比べて遅くなる可能性があります。	- 比較的速い： Safariエンジンを活用するため、通常はより良いパフォーマンスを提供します。Safariエンジンは速度と効率のために最適化されており、ウェブページの高速な読み込み時間を実現します。
信頼性と認知度	- URL表示は必須ではない： WKWebViewはURLを表示しないことが多く、ユーザーがウェブページを確認するのが難しくなります。悪意のあるアプリがこの動作を模倣して認証情報をフィッシングする可能性があります。	- ブラウザライクな体験： Safariを使用してウェブページをレンダリングし、「ブラウザライク」な体験を提供します。ユーザーはURLを確認し、Safariの自動入力機能にアクセスできるため、見慣れたインターフェースにより信頼性が高まる可能性があります。
分離	- 分離されている： CookieとセッションはSafariから分離されています。ユーザーはWKWebViewに自動的にログインされません。	- 分離されている： CookieとセッションはSafariから分離されています。ユーザーはSFSafariViewControllerにも自動的にログインされません。
脆弱性	- 安全： Appleのアプリサンドボックスにより本質的に安全ですが、動作とセキュリティはアプリの実装に依存します。正しく実装されていない場合、潜在的な脆弱性があります。	- より安全：フィッシング対策や悪意のあるウェブサイトの警告など、Safariに組み込まれたセキュリティ機能の恩恵を受けます。これらの機能とユーザーがSafariに慣れていることから、一般的にWKWebViewよりもウェブコンテンツを表示する上で安全だと考えられています。
その他	- 利用できない機能：一部のブラウザ機能（例：WebAuthn）は、セキュリティ上の懸念やWKWebViewがアプリケーションコンテキストで実行されるため、完全にはアクセスできない場合があります。 - JavaScriptインジェクション： TikTokなどの一部のアプリは、アプリ内WKWebViewに追跡用のJavaScriptを注入したり、ユーザーコントローラーを制限したりします（例：Facebook）。 - プライバシー問題：プライバシーに関するコミュニティからのフィードバックがより多くあります。	- JavaScriptインジェクションなし：アプリからのJavaScriptの実行を許可しないため、セキュリティとプライバシーが向上します。また、JavaScriptのアラートや確認をサポートしていないため、特定のウェブページでのユーザーエクスペリエンスに影響を与える可能性があります。 - リーダーモード：記事をクリーンで読みやすいバージョンで表示するリーダーモードを提供します。

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSessionとASWebAuthenticationSessionは、OAuth / OpenID Connectベースの認証フローに特化して調整されたWebViewです。これらはユーザー認証のための安全で隔離されたスペースを提供し、ユーザーの認証情報を保護し、個人情報が誤ってアプリと共有されないようにします。これらのセッションはSafariとCookieやウェブサイトデータを共有し、特に認証プロセス中に一貫性のあるシームレスなユーザーエクスペリエンスを提供します。

長所：

専用の認証： OAuth / OpenID Connectベースの認証フロー専用に設計されており、合理化された認証プロセスを保証します。
プライバシー保護： アプリとCookieやウェブサイトデータを共有しないことで、ユーザーデータのプライバシーを確保します。
SSOサポート： シングルサインオンをサポートし、便利なユーザーエクスペリエンスを提供します。

短所：

限定的なユースケース： 主にOAuth / OpenID Connect認証に焦点を当てており、すべてのユースケースに適しているわけではありません。

主なタスクがユーザー認証であり、特にSSOを実装したり、OAuthプロバイダーと対話したりする場合には、SFSafariViewControllerの代わりにSFAuthenticationSession / ASWebAuthenticationSessionを使用すべきです。

Want to find out how many people use passkeys?

View Adoption Data

4. AndroidのWebView#

AndroidのWebViewは、WebViewまたは**Chrome Custom Tabs (CCT)**のいずれかです。Androidでの異なるWebViewの動作をテストするには、アプリ「WebView vs Chrome Custom Tabs」をお勧めします。

4.1 Android WebView#

AndroidのWebViewは、開発者がウェブコンテンツをアプリのUIの一部として表示できる包括的なコンポーネントです。多機能で、幅広いカスタマイズオプションを提供し、開発者に様々なニーズに合わせてWebViewを設定する柔軟性を与えます。WebViewは、ウェブコンテンツとの対話、ユーザーインタラクションの管理、さらにはJavaScriptダイアログ、クライアント証明書、権限リクエストの処理のための豊富なAPIセットを提供します。

4.2 Chrome Custom Tabs (CCT)#

**Chrome Custom Tabs (CCT)**は、ウェブコンテンツをアプリに直接、シームレス、安全、かつ効率的に統合する方法を提供します。Chromeの機能とセキュリティ機能を活用することで、CCTは一貫性があり、高性能なユーザーエクスペリエンスを提供します。

CCTはChromeブラウザのコンポーネントであり、Androidフレームワークと統合するように設計されており、アプリが軽量で専用のプロセスでウェブコンテンツを開くことを可能にします。特筆すべきは、従来のブラウザよりも速く開き、ウォームアップコールを介してプリロードされると、WebViewを上回るパフォーマンスを発揮する可能性があることです。JavaScriptを実行しますが、独自のプロセスで動作するため、悪意のあるコードの実行からアプリを保護します。さらに、CCTのUIはアクションバーを提供し、URLと安全なページ用のSSL検証ロックアイコンを表示することで、読み込まれているページの信頼性とセキュリティをユーザーに保証します。

一般的に、iOSのWKWebViewとAndroidのWebView、そしてSFSafariViewControllerと**Chrome Custom Tabs (CCT)**は似ていると言えます。

機能	WebView	Chrome Custom Tab
ユーザーエクスペリエンス	- 柔軟性： JavaScriptダイアログや権限リクエストの処理を含む、ウェブコンテンツとの対話やユーザーインタラクションの管理のための豊富なAPIセットを提供します。 - 一貫性：特に多様なウェブコンテンツで一貫したUXを管理することは困難な場合があります。	- ブラウザ機能：データセーバーやデバイス間で同期されたオートコンプリートなどの機能を共有します。 - 戻るボタン：統合された戻るボタンでユーザーが簡単にアプリに戻れるようにします。 - 依存性： Chromeアプリに依存しており、すべてのユーザーデバイスで利用可能または更新されているとは限りません。 - ブラウザへのリダイレクト：特定の機能がユーザーをChromeアプリにリダイレクトし、ユーザーエクスペリエンスを中断させる可能性があります。 - 部分的なカスタムタブ：画面の一部のみをChrome Custom Tabに使用でき、残りの部分はネイティブアプリが表示されます。 - サイドシート：横向きモードや大画面デバイスでは、Chrome Custom Tabは画面の片側にのみ表示され、画面の残りの部分にはネイティブアプリが表示されます。
開発者エクスペリエンス	- 高度にカスタマイズ可能：広範なカスタマイズオプション/ニーズを提供します。 - インタラクティビティ：ウェブコンテンツとの対話やユーザーインタラクションの管理のための多数のAPIを提供します。	- カスタマイズ可能：ツールバーの色、アクションボタン、ボトムツールバー、カスタムメニュー項目、および出入りアニメーションのカスタマイズが可能です。 - コールバック：外部ナビゲーション時にアプリケーションにコールバックを配信します。 - セキュリティ機能：すぐに使える機能を提供し、リクエスト、権限付与、またはCookieストアを管理する必要がありません。
パフォーマンス	- 平凡なパフォーマンス： Chrome Custom Tabs (CCT)と同じレベルのパフォーマンスを提供しない場合があります。	- プリウォーミング：バックグラウンドでのブラウザのプリウォーミングとURLの投機的読み込みを含み、ページ読み込み時間を向上させます。 - 優先度： Custom Tabを起動するアプリの重要度を「フォアグラウンド」レベルに引き上げることで、使用中にアプリが強制終了されるのを防ぎます。
信頼性と認知度	- URLとSSLが非表示： URLとSSL情報はWebViewに本質的に表示されません。アプリ開発者がこれらの機能を実装しない限り、ユーザーは正しいウェブサイトにいるのか、フィッシングサイトにいるのかを知ることができません。	- URLとSSLが表示される：実際のChromeブラウザを使用してページをレンダリングします。ユーザーはURLとSSL証明書（接続が安全かどうかを示す）を見ることができます。これにより、ユーザーはフィッシングサイトにいないという自信を持つことができます。
分離	- アプリのプロセス内で実行：アプリに悪意のあるコード実行を許す脆弱性がある場合、WebViewが侵害されるリスクがあります。ただし、WebViewも更新を受け取りますが、その動作とセキュリティはそれを使用するアプリにより依存する可能性があります。 - Cookie/セッション共有なし：デバイスのメインブラウザとCookieやセッションを共有しないため、分離を提供しますが、ユーザーが再度ログインする必要があるかもしれません。	- Chromeのプロセス内で実行： Chromeの一部であるため、Custom Tabsは同じプロセスで実行され、Chromeと同じセキュリティ更新と機能を持ちます。 - 共有Cookieジャーと権限モデル：ユーザーがサイトに再サインインしたり、権限を再付与したりする必要がないようにします。 - Chromeの設定と環境設定： Chromeの設定と環境設定を利用します。
脆弱性	- 認証情報を盗むためのコールバック：潜在的な脆弱性には、JavaScriptが必要な場合があり、これにより他のアプリが悪意のあるコードを実行する扉が開かれることがあります。例えば、ユーザー名とパスワードを傍受しようとするコールバックを登録するなどです。 - フィッシング：さらに、悪意のあるアプリが、フィッシング目的でLinkフローを模倣した別のウェブページを開く可能性があります。	- Googleセーフブラウジング： Googleのセーフブラウジングを採用して、ユーザーとデバイスの両方を危険なサイトから保護します。 - 安全なブラウザ装飾：ユーザーが常に対話している正確なURLを確認し、ウェブサイトの証明書情報を表示できるようにすることで、フィッシングのリスクを低減します。さらに、カスタムタブはJavaScriptの注入を許可しません。
その他	- GoogleはGoogleアカウントへのログインにWebViewを禁止しました。

5. ネイティブアプリにおけるパスキー実装の推奨事項#

私たちのお客様からは、ネイティブアプリでパスキーをどのように実装すべきかについて継続的に質問が寄せられます。これらのお客様は、大きく異なるグループに分けることができます。

グループA：

ネイティブアプリをゼロから構築し始め、直接私たちのパスワードレス認証を使用できるお客様（レガシーなパスワードは存在しない）。

グループB：

既存のユーザーと既存の認証ソリューションを持つお客様。多くの場合、既存のウェブアプリも持っており、その認証プロセスにもパスキーを追加する必要があります。ここでは、多くの企業が2段階のプロセスを決定します。

既存のWebView認証フローにパスキーを追加する（これはGoogleやGitHubがネイティブアプリで実装した方法です）。
その上にネイティブ実装でパスキーを追加する。このネイティブパスキー実装は、古いWebView（例：ソーシャルログインやパスワード用）の前に、ユーザーがパスキーでログインできるかどうかをチェックします（これはKAYAKがネイティブアプリで実装した方法です）。

あなたのグループを決定する

ユーザーにネイティブアプリで最高のパスキー実装を提供するためには、現在の技術的な設定と、パスキーをどのように推進したいかに基づいて、自分がどのグループに属するかを決定する必要があります（この質問はグループBの企業に関連します）。

グループAへの推奨：ネイティブ実装

全く新しいアプリを構築している場合（グループA）、ネイティブのパスキー実装を採用し、すぐに完全にパスワードレス化することをお勧めします（つまり、いかなる種類のWebViewも使用しません）。iOSおよびAndroid用のネイティブSDKとAPIを使用してください（例：passkeys Flutterパッケージ経由）。また、Relying Party IDに関するこの記事もお読みください。

グループBへの推奨：まずWebView、次にネイティブ実装

何らかの理由で今日パスキーをネイティブに実装できない場合（グループB）、WebView実装から始めて、将来的にはネイティブのパスキー実装に移行することができます（これは、iOSアプリ用のapple-app-site-associationやAndroidアプリ用のassetlinks.jsonのようなアソシエーションファイルの作成を介して機能します）。WebView実装を選択する理由には、以下のようなものがあります。

すでにOAuth2ベースの認証を提供しており、ユーザーに提供し続けたい（OAuth2はネイティブでは機能しません。標準はこちらを参照してください）。
他の認証方法（例：パスワード、ソーシャルログイン、OAuth2）を提供するのと同じウィンドウ/画面でパスキー認証を提供したい。

これは、GoogleやGitHubが現在ネイティブアプリでパスキー認証を実装している方法です。パスキー認証のためにWebViewを正しく設定するための以下の推奨事項を参照してください。しかし、私たちはKAYAKが行ったようなネイティブのパスキー実装を検討し、直接ステップ2から始めることをお勧めします。

グループBに属し、パスキーをネイティブに実装できない場合、私たちの推奨はiOSにはSFAuthenticationSession / ASWebAuthenticationSessionを、AndroidにはChrome Custom Tabsを利用することに傾きます（そうでなければ、いずれにせよパスキーは機能しません）。

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

以下に、この推奨の理由を述べます。

5.1 ブラウザとのCookieとデータの共有#

SFAuthenticationSession / ASWebAuthenticationSessionはSafariとCookieやウェブサイトデータを共有し、認証プロセス中にシームレスなユーザーエクスペリエンスを提供します。同じことがAndroidのChrome Custom Tabsにも当てはまります。

ユーザーはブラウザに保存されたパスワード、自動入力データ、その他の保存情報から恩恵を受け、認証プロセスがよりスムーズかつ迅速になります。

5.2 強化されたセキュリティ#

iOSのSFAuthenticationSession / ASWebAuthenticationSessionとAndroidのChrome Custom Tabsは、ユーザー認証のための安全で隔離されたスペースを提供し、機密性の高いユーザー認証情報が保護され、誤ってアプリや他のウェブサイトと共有されないようにします。

これらはAppleとGoogleの厳格なセキュリティプロトコルに準拠しており、ユーザーデータが安全に取り扱われ、プライバシーが維持されることを保証します。

さらに、この設計選択はSafariとChromeの継続的なセキュリティ更新と機能強化の恩恵を受け、最新のセキュリティ標準とプロトコルに準拠していることを保証します。

5.3 ユーザーエクスペリエンス#

iOSのSFAuthenticationSession / ASWebAuthenticationSessionとAndroidのChrome Custom Tabsは、ユーザーがブラウザのユーザーエクスペリエンスに慣れているため、一貫性のある親しみやすいユーザーインターフェースを提供します。さらに、SafariとChromeのユーザー設定と環境設定が適用されます。

アプリコンテンツとウェブコンテンツ間のスムーズな移行を提供し、ユーザーがインターフェース間の切り替えによって不快な思いをしないようにします。

5.4 パフォーマンス#

Chrome Custom TabsはChromeのパフォーマンスを活用し、スムーズで応答性の高いユーザーエクスペリエンスを保証します。これは、ユーザーの不満や離脱を防ぐために認証プロセス中に特に重要です。

CCTのパフォーマンスは、多くの場合Android WebViewオプションよりも優れており（iOSのSFAuthenticationSession / ASWebAuthenticationSessionも同様）、ウェブコンテンツと認証フローが迅速かつスムーズに処理されることを保証します。

Chrome Custom Tabs、Android WebView、および標準のChromeブラウザのパフォーマンスの違いを体感するには、Googleによるこの比較も参照してください。

5.5 認証フロー専用#

SFAuthenticationSession / ASWebAuthenticationSessionは、OAuth / OpenID Connectベースの認証フローを処理するために特別に設計されており、これらの広く使用されている認証プロトコルのための合理化された安全なプロセスを保証します。これはWebAuthn / パスキー認証にも推奨される方法です。

Androidには認証フロー専用のクラスはありませんが、Chrome Custom TabsとAndroid App Linksで同様の動作を実装できます。

さらに、TikTokのように、ユーザーが認証されたときにパスキーを収集するだけでパスキーを導入するアプリが増えることを期待しています。これはネイティブ（TikTokの実装）またはWebView実装を介して行うことができます。適切なアプローチは、条件付きUIをネイティブにトリガーすることです。それが機能しない場合は、WebView実装を表示します。

6. 結論#

現代のデジタル認証の状況において、ネイティブアプリでのWebViewを介したパスキーの実装は、安全でユーザーフレンドリーな実践の指標として浮上しています。最適なWebViewを選択する道のりは複雑かもしれませんが、技術的な選択をユーザーエクスペリエンスとセキュリティに合わせることが極めて重要です。