Skip to main content

ウェブサイト上で作成したパスキーを使用してアプリにサインインする(アプリからウェブサイトの場合も含む)

概要

トピック:コンシューマー、パスキー、WebAuthn、ネイティブ・モバイルアプリ
カスタマージャーニー認知 > 検討 > 登録 > 管理 > 認証
作成日:2024年5月24日

ユーザーが同じパスキーを使用して、ウェブサイトとネイティブ・モバイルアプリ間でアカウントにサインインできるようにします。

ウェブサイト上で作成したパスキーを使用してアプリにサインインする(アプリからウェブサイトの場合も含む)機能を追加する

  • 自動入力を利用してデータの入力プロセスを効率化し、エラーやタイプミスの可能性を減らす。
  • ネイティブ・モバイルアプリからウェブ、またはウェブからネイティブ・モバイルアプリへ移行する際に、ユーザーがパスワードを手動で入力したり、追加の認証ステップを実行したりする必要性を排除する。
  • ウェブサイトとネイティブ・モバイルアプリ間で一貫性のある直観的な認証フローを確保する。
  • 再認証やパスキー再設定の必要なしに、ウェブとネイティブ・モバイルアプリ間の切り替えを可能にする。

結果

  • ウェブサイトとモバイルアプリ間で同じパスキーを使用し、シームレスかつ一貫性のあるユーザー認証を行って、全体的なユーザーエクスペリエンスを効率化する。
  • パスワードの代わりにパスキーを利用することで、ユーザー名やパスワードを記憶して入力する必要がなくなるため、ウェブサイトからネイティブ・モバイルアプリへの移行成功率が向上する。一部のサービスプロバイダーは、ネイティブ・モバイルアプリの導入に関する主要な業務指標を有しており、パスキーはこの指標にプラスの影響を与える可能性がある。
  • 複雑なパスワードを記憶して入力する必要がなくなることで、利便性が向上し、パスワードの煩わしさを軽減する。
  • 一貫した堅牢なセキュリティ態勢を維持し、バックアップとリカバリーを向上させながら、ウェブサイトとネイティブ・モバイルアプリ間でパスキー本来の高いフィッシング耐性を有するセキュリティ上の利点を活用する。
  • 初回サインイン成功率の向上。自動入力を利用してデータの入力プロセスを効率化し、エラーやタイプミスの可能性を減らす。
  • ユーザーはより便利で一貫性のあるサインインを主要手段に用いる傾向にあるため、広範囲なパスキーの導入と普及が促進される。

ウェブサイトとアプリで同じパスキーを使用する場合の方法を示すUXアーキテクチャ図

フロー:ウェブサイトからアプリ

ウェブサイトからアプリへ

ユーザーがウェブブラウザでパスキーを作成します。その後、アプリでも同じパスキーを使用できるようになります。

フロー:アプリからウェブサイト

ユーザーがアプリでパスキーを作成します。その後、ウェブでも同じパスキーを使用できるようになります。

コンテンツ

このパターン向けの独自コンテンツはありません。

UXリサーチ

ユーザーエクスペリエンスに関するリサーチでは、参加者の最初のパスキー登録手段(例えば、パスキーがアプリまたはウェブサイトで作成される)は、パスキーに対する使用範囲(ウェブサイトのブラウザを介したパスキーでのサインインなど)の期待に影響していることが分かりました。モバイルアプリを通じてパスキー登録を行った参加者は、パスキーを使用してモバイルブラウザにサインインすることを想定する傾向にありました。この結果によると、参加者はモバイルアプリがモバイルデバイスとより緊密に統合されていると認識し、認証手段がウェブサイトとネイティブ・モバイルアプリ間をシームレスに移行することを期待している可能性を示唆しています。

「最初にウェブサイトでサインアップしていたら、おろらく認証コードが送られて来たと思いますが、すでに生体認証を設定していたため、ウェブサイトとアプリを行き来するのは非常に簡単でした。」

— フェーズ2 - 参加者3(40歳)、Android (Chrome)

「そうですね、『パスキーを使用したアプリやウェブサイトでのサインイン』の標準のようなものだと感じます。同じアカウントなので、そのようになることを期待します。」

— フェーズ2 - 参加者4(31歳)、iPhone (Safari)

リサーチによると、参加者はウェブサイトとネイティブ・モバイルアプリ間でアカウントへのアクセスを効率化するパスキーを使用できることを好意的に捉えていました。参加者はパスキーによるサインイン・エクスペリエンスについて、シンプルで分かりやすく、かつモバイルアプリとブラウザ全体で一貫性があったと述べています。しかしながら、一部の参加者は、ウェブサイトとネイティブ・モバイルアプリ間で異なるサインイン手段を用いることに対して、必要性が低く、かつその手段が使い慣れている限りは問題ではないと語っています。

「その一貫性が気に入っています。ただ正直に言うと、これに関しては、おそらくブラウザを使うことはないでしょう。多分、アプリだけを使用すると思います。ただ、同じ方法でサインインする機能があるのは有益です。スマホ上はシームレスですから。覚えておく必要のないパスワードよりもシンプルです。」 — フェーズ2 - 参加者5(53歳)、iPhone (Safari)

「ただし、非常に特別であるとは思いません。これが一回だけのことであれば、さらにいくつかのステップが増えても、気にならないでしょう。」

— フェーズ3 - 参加者5(21歳)、Android (Chrome)

「もっと多くのアプリやウェブサイトでこのような機能があればと思います。」

— フェーズ2 - 参加者1(27歳)、Android (Chrome)

既存のエコシステムに関する知識

note

これは、サービスプロバイダーのシステムでSSOオプションを提供する場合のユーザーエクスペリエンスにのみ影響します。

ユーザーへの調査では、パスキーがクレデンシャル・マネージャーに関連付けられ、密接にリンクしていると想定していたのは少数でした(「Googleパスキー」または「Appleパスキー」とも呼ばれる)。そのため、参加者はGoogleやAppleのシングルサインオン(SSO)オプションを選択してパスキーを使用し,これが使用できないと、混乱や当惑を招くこともありました。

Googleのクレデンシャル・マネージャーやAppleパスワードとの関連性を想定させる要因は、複数考えられます。

  • サインインの認証資格情報の保存と管理に関して、参加者がすでにクレデンシャル・マネージャーを使っており、信頼している。これらのエコシステムに慣れており、パスキーなどの安全かつ便利な認証エクスペリエンスと関連付けている。
  • 参加者がGoogleアカウントやApple Accountを使用してウェブサイトやアプリにサインインすることに慣れており、多くの場合、それぞれのクレデンシャル・マネージャーから保存された認証資格情報を活用している。
  • パスキーにおいて基盤となる技術とエコシステムに関し、参加者の理解が限られている。パスキーは個別で独立した認証手段であることを認識していない可能性がある。
  • セットアップのプロセス中に、参加者は明示的なアクションなしに、パスキーがクレデンシャル・マネージャーに自動保存されるのを観察した。この自動保存により、パスキーはこれら既存の認証資格情報管理システムと本質的にリンクしているという思い込みを強化した可能性がある。

「なぜなら、Googleで続行する場合、たとえGoogleが何も要求しなかったとしても(本当はしてほしいですが)、私はそれを選択すると思います。それがGoogleパスキーであれば、最初に表示されるべきだからです。また、メールアドレスを入力するのは、Googleにアクセスするよりも時間がかかります。なので、あまり好きではありません。『パスキーを使用する』というオプションがあればいいのにと思いますが,Googleは私がパスキーを持っていることを自動認識しているはずです。よく分かりませんが,少し混乱してしまいますね。」

— フェーズ3 - 参加者4(43歳)、Android (Chrome)

「私はおそらくAppleで続行するを選択すると思います。それが、通常行っているiPhoneやスマホアプリへのサインイン方法ですから。」

— フェーズ3 - 参加者1(33歳)、iPhone (Safari)

コンテキストガイダンスを記載することは、ネイティブ・モバイルアプリとウェブサイト間でパスキーを使用する機能(さらにはクロスデバイス・サインインにも適用)についての理解を促すのに効果的です。パスキーに関するコンテキストガイダンスを提示する方法は、いくつかあります。

  • パスキーが使用可能な場合は、「サインイン」ページから従来のパスワードフィールドを削除する。この視覚的な合図によって、パスキーがパスワードの必要性をなくすという概念を強調できる。
  • パスキーの自動入力機能を実装し、ユーザーがサインインするときにパスキーの認証資格情報を自動入力できるようにする。
  • 例えば、パスキーアイコンなどの視覚的インジケーターを使用して、パスキーが持つクロスデバイスの性質について伝える。
  • ユーザーがパスキーオプションの上にマウスを移動させたり、それらオプションを選択したりしたときにパスキーに関する詳細情報が提供できるよう、コンテキストツールチップや情報のオーバーレイを実装する。

展開戦略

  • 主要なKPIとネイティブ・モバイルアプリの使用増加が関連しているサービスプロバイダーにとっては、まずウェブサイトとネイティブ・モバイルアプリの新規アカウント作成時にパスキーによるサインイン機能を実装するのも一つの案です。ユーザー名やパスワードを記憶したり、パスキーを入力する必要がないため、ウェブサイト・エクスペリエンスからアプリ・エクスペリエンスへの移行を断念する顧客の割合を減らすことができます。
  • パスキーのサポートを実装するアプローチは、サービスプロバイダー独自のニーズと望ましい顧客エクスペリエンスに基づいて策定する必要があります。状況に応じて、これにはウェブサイトブラウザ、ネイティブ・モバイルアプリ、またはその両方を優先させることが含まれます。

エコシステム

  • パスキーには、ユーザーのデバイス上で特定のハードウェアまたはソフトウェアサポートが必要になる場合があります。ユーザーがパスキーの使用に必要な互換性要件を認識していることを確認し、互換性のあるデバイスとブラウザに関するガイダンスを提供してください。
  • ネイティブのモバイルアプリでは、パスキーを使用したサインインと長年利用されてきた生体認証によるサインイン・エクスペリエンスは異なります。パスキーを使用したサインインでは、追加のタップが必要です。

セキュリティ

独自の安全・業務ニーズに従って、UX計画を策定してください。本ガイドラインでは、同期パスキーを使用するFIDOに特有のUX概念に焦点を当て,全体を通じて、さまざまな形式の身元確認とFIDO以外の認証例を記載しています。本ガイドラインは、身元確認やその他の非FIDO認証メカニズムに関するセキュリティガイドラインの規定を意図するものではありません。これらのセキュリティガイドラインは、各サービス事業者 (RP) に合わせて、独自の業務ニーズと安全方針を基に策定されるものだからです。