パスキーのフォールバックとリカバリー：識別子ファーストアプローチ

1. はじめに#

パスキーは従来の認証方法に代わる実用的な代替手段に成長しており、デバイスの95%近くがパスキーに対応しています。しかし、最も高度なシステムであっても、パスキーにアクセスできない（フォールバック）、あるいは紛失した（リカバリー）シナリオに対処するために、効果的なフォールバックおよびリカバリー戦略が必要です。本ガイドでは、フォールバックやリカバリーが必要となる様々なシナリオを探り、考えられるソリューションの具体的な形について議論します。

フォールバックとリカバリーの方法を考える際、それらの強度が主要な認証方法の強度と一致していることが重要です。このガイドでは、パスキーの様々な使用方法を区別し、特にパスキーが自己完結型のMFAとして使用される状況に焦点を当てて、フォールバックとリカバリーの方法を適切に調整します。

重要な質問:

• どのようなフォールバックのシナリオが存在するか？ パスキーシステムで発生する可能性のあるフォールバックシナリオにはどのようなものがあり、セキュリティを維持するためにはそれらをどのように処理すべきでしょうか？
• リカバリーはどのように処理すべきか？ パスキーの使用パターン、特にMFAを使用する環境において、セキュリティを確保するためにリカバリープロセスをどのように設計すべきでしょうか？

これらの質問を探求することで、このガイドはプロダクトマネージャーや開発者がパスキーシステムを効果的に設計、実装、管理し、ユーザー体験を犠牲にすることなくセキュリティを確保するために必要なインサイトを提供します。

2. 定義：識別子、セキュリティレベル、フォールバックとリカバリー#

フォールバックおよびリカバリー戦略を深く掘り下げる前に、ここで使用するいくつかの基本的な用語について明確に理解しておくことが重要です。

2.1 識別子：メール、電話番号、ユーザー名#

ビジネスおよび消費者向けシステムの大部分において、認証はメール、電話番号、ユーザー名という3つの主要な識別子に依存しています。

特にWebベースのアプリケーションでは、大多数のシステムが主要な識別子としてメールを使用しています。一方、モバイルファーストやアプリファーストのプラットフォームでは、SMSベースのOTP（ワンタイムパスコード）を自動的に挿入・事前入力しやすいという理由から、識別子として電話番号を使用することが好まれます。場合によっては、主に独自の表示名を必要とするプラットフォームで、これらの識別子に加えてユーザー名の設定が求められることもあります。また、特に大規模なプラットフォームでは、柔軟性を高めるためにメールと電話番号の両方を使用できるようにする傾向が高まっています。

初期登録時に、これらの識別子は通常、確認リンクやOTP（メールの場合）、またはOTP（電話番号の場合）によって検証され、その識別子が正しい人物のものであることが確認されます。アクセスを失った場合、以前に検証されたメールまたは電話番号の制御を証明するだけで、通常はアカウントへのアクセスを回復するのに十分です。これらの識別子はユーザーとの最も信頼性の高い通信手段であるため、電話番号はMFA（多要素認証）の目的で収集されることが多く、SMSが2番目の要素としてよく使用されます。

ユーザー名は、ソーシャルメディア、フォーラム、特定の専門プラットフォームなど、公開向けの識別子が必要なシステムにおいて、ユーザーアイデンティティの追加レイヤーを提供するためによく使用されます。認証における機能的な役割はメールや電話番号と同じではありませんが、ユーザー名はパブリックまたはピアツーピアのコンテキストでユーザーに認識可能なアイデンティティを提供します。しかし、ユーザーは頻繁にこれらを忘れる可能性があり、ほとんどの場合、ユーザー名の横に別の識別子が必要になるため、さらなる複雑さをもたらします。したがって、この記事ではユーザー名には焦点を当てません。

認証アプリ（TOTPコードを生成する）など他の2FAオプションは、識別子に依存しませんが、平均的なユーザーにとって設定がより複雑になることがよくあります。また、パスキーは識別子なしで機能する可能性（ユーザーネームレス認証）を導入し、この機能は暗号資産スペースでますます人気が高まっています。しかし、消費者向けおよびビジネス向けソリューションのどちらにおいても、フォールバックやリカバリーの目的でユーザーと（多くの場合メール経由で）通信する必要があるため、ユーザーネームレスシステムはあまり実用的ではありません。

2.2 セキュリティレベル：単一要素認証（SFA）と多要素認証（MFA）#

**単一要素認証（SFA）**システムは、ユーザーの身元を検証するために1つの認証形式に依存するシステムです。一般的に、この単一の要素はパスワードですが、ソーシャルログイン、メールOTP、あるいは1種類の証明のみを必要とするあらゆる方法である可能性もあります。今日のWeb上のほとんどのシステムはSFAシステムです。しかし、セキュリティとの間にはよく知られたトレードオフがあります。パスキーを統合する場合、これらは通常、従来のパスワードのアドオンまたは代替として機能し、システムの利便性を向上させます。そのようなシステムでは、メールOTPやソーシャルログインなどのフォールバックオプションを許可し続けるのが一般的であり、これによりパスワードを減らしてユーザー体験は向上しますが、システムのセキュリティがSFAを超えて向上することはありません。

**多要素認証（MFA）**は、ユーザーの身元を検証するために2つ以上の独立した要素を含みます。これがSFAよりも安全である理由です。これらの要素には、ユーザーが知っているもの（パスワードやPIN）、ユーザーが持っているもの（セキュリティトークンや携帯電話のアプリ）、およびユーザー自身の特性（指紋や顔認識などの生体認証）が含まれます。MFAシステムは、フィッシング攻撃やパスワード侵害など、SFAシステムでは防御できない特定の脆弱性から保護するように設計されています。MFAシステム内でパスキーを使用する場合、一般的には自己完結型のMFAオプションとして利用されます。このようなケースでは、フォールバックやリカバリーの方法がパスキーと同等のセキュリティレベルを維持することが不可欠です。

2.3 フォールバックとリカバリー#

フォールバックは、複数の認証方法が共存するすべてのシステムで使用されます。主要な方法が利用できない場合に使用されます。ユーザーは多くの場合、登録時に最初に（例：ソーシャルログインとパスワードの）どちらでサインアップするかを選択できます。フォールバックには、メール経由のOTP、パスワード、一致するメールによるソーシャルログイン、ネイティブアプリのプッシュ、QRコード、セキュリティキーなどの代替認証戦略が含まれる場合があります。これらのフォールバック方法はそれぞれセキュリティの品質が異なり、ユーザーの利便性とセキュリティ要件のバランスを取る上で、適切なフォールバックオプションを選択することが重要です。

多要素認証（MFA）システムの一部としてパスキーを利用する環境では、これらのフォールバック方法がパスキーに匹敵する多要素セキュリティを提供できるように慎重に検討する必要があります。リカバリープロセスは、ユーザーが要求されるセキュリティ基準（SFAまたはMFA）を満たすすべての確立された認証手段へのアクセスを失った場合に重要になります。これは、単一要素システムではそれほど重要ではありません。単一要素システムでは、メールOTPによるパスワードのリセットなど、複数のリカバリーオプションが利用できる場合があり、これによって関連付けられた識別子に対するユーザーのコントロールが効果的に検証されます。しかし、2FA/MFAシステムでは、検証のために本質的に複数の要素に依存しているため、リカバリーは特に困難です。ユーザーがモバイルのオペレーティングシステムを（例：iPhoneからAndroidスマートフォンに）変更し、関連付けられたパスキーと電話番号を失うようなシナリオでは、残りの要素（例：パスワードのみ）では2FAの要件を満たすことができません。このような場合のリカバリーには、手動によるサポートリクエストや、後述するより革新的なソリューションを含む新しい身元証明の作成が必要になる場合があります。

3. パスキーログインのフォールバック：手動パスキーログインと自動パスキーログイン#

パスキーソリューションを実装する際、最初に行う決定事項の1つはパスキーログインのアプローチです。 ユースケースによっては、小規模なプラットフォームでは手動ログインで十分な場合もありますが、UXを重視する大規模な企業には、主要な識別子（多くの場合メール）が入力された後にパスキーログインを提案する識別子ファーストアプローチ（Identifier-First Approach）が推奨されます。

3.1 手動パスキーログイン：ユーザー主導アプローチ#

3.1.1 ユーザー主導アプローチとは？#

小規模なプラットフォーム、またはパスキーのログイン率を高めることに重点を置いていないプラットフォームでは、ユーザー主導アプローチには独立した「パスキーでサインイン」ボタンが含まれます。このアプローチでは、パスキーを使用する責任は完全にユーザーに委ねられます。アカウントにパスキーを追加した後、ユーザーはそれを使ってログインするために、「パスキーでサインイン」をクリックすることを覚えておかなければなりません。

スクリーンショットは、手動パスキーログインアプローチを使用しているhttps://my.gov.auのパスキー実装を示しています。このアプローチは、バックエンドがパスキーログインが可能かどうかを判断する必要がないため実装が容易ですが、通常はパスキーのログイン率が大幅に低くなります。これはユーザーの主体性に大きく依存しており、消費者は自分のパスキーがどのプラットフォームやクラウドストレージにあるかを覚えていなかったり、確信が持てなかったりする可能性があるためです。このアプローチはユーザーに考えさせることになります。次のセクションでは、このアプローチに存在するフォールバックの機会を見てみましょう。

3.1.2 フォールバック#

パスキーへのアクセスが失敗する可能性があるシステムでは、フォールバックが不可欠です。手動パスキーログインアプローチでは、すべてのログインオプションが同時に表示され、パスキーはユーザーの判断で選択されるため、ダイアログとフォールバックを個別に管理することはできません。これにより、いくつかの課題が生じます。

• 直感的でないエラー: パスキーが利用できない場合や正しく設定されていない場合にユーザーが遭遇するエラーメッセージは、不明確であることが多く、混乱を招く可能性があります。ユーザーはなぜパスキーを使用できないのか、あるいは何が問題だったのかを理解できず、フラストレーションにつながる可能性があります。
• 行き止まり: ユーザーは、先へ進めない行き止まりに陥る可能性があります。パスキーが見つからないかアクセスできない場合、ユーザーに進行方法やアクセスの回復方法に関する明確なガイダンスが提供されず、ログインプロセスを諦めてしまう原因となります。
• ガイダンスの欠如: これらの状況において、システムは代替の認証方法へとユーザーを導く有用な指示を提供できません。ユーザーは自分で問題を解決する方法を見つけ出すしかなくなり、ユーザー体験が低下します。

上記の例は、プラットフォームオーセンティケーターでパスキーが見つからない場合の、Windows 11のエラーメッセージがいかに混乱を招くかを示しています。システムは、パスキーがセキュリティキーや別のデバイス上にあると想定する場合があります。このプロセスは、そのような認証フローに慣れていないユーザー、特にセキュリティキーを使用したことがない、またはパスキーを作成したことがないユーザーにとって、混乱を招く可能性があります。

プラットフォームオーセンティケーターにパスキーが見つからない場合、オペレーティングシステムとブラウザはパスキーが他の場所に存在すると想定するため、ユーザーがまだパスキーを作成していない場合はさらに混乱を招きます。 Conditional UIは既存のパスキーを表示することで役立ちますが、これはパスキーが実際に存在する場合にのみ役立ちます。最高のパスキー体験を得るには、ユーザーが主要な識別子を提供した後にパスキーログインをトリガーすべきかどうかをバックエンドが決定する必要があります。

3.2 自動パスキーログイン：識別子ファーストアプローチ#

3.2.1 識別子ファーストアプローチ（Identifier-First Approach）とは？#

識別子ファーストアプローチでは、システムがパスキーログインが可能かどうかを判断する前に、メールや電話番号などの主要な識別子を提供するようユーザーに求められます。識別子が検証された後、システムは利用可能かつアクセス可能なパスキーを含め、最も適切なログイン方法を自動的に提案します。このアプローチは、ユーザーが「パスキーでサインイン」オプションを選択することを覚えておく必要をなくし、プロセスを合理化することで導入率を向上させるため、よりユーザーフレンドリーです。

Googleの識別子ファースト・サインイン

Googleのパスキー・サインイン

上のスクリーンショットは、macOSデバイスにパスキーが関連付けられているアカウントに対する、Googleログインの動作を示しています。 Googleも識別子ファーストアプローチに従っており、パスキーログインが非常に高い確率で可能であると判断しました。

1. パスキーのプラットフォームサポート: 基盤となるプラットフォームがプラットフォームオーセンティケーターをサポートしているため、ログインが可能になります。
2. パスキーのアクセス可能性: パスキーはmacOSシステムで作成されたため、このクライアント（macOS）でアクセスできる可能性が非常に高いです。

その結果、パスキーログインが自動的に開始され、可能な限り最高の体験へとユーザーを導きます。これは「私に考えさせないで」戦略に従っています。

3.2.2 パスキープラットフォームサポートの欠落またはパスキーへのアクセス不可#

システムはパスキーログインが可能かどうかを判断します。次のような場合：

• パスキーが存在しない: ユーザーがアカウント用にまだパスキーを作成していない。
• パスキーにアクセスできない: ユーザーが作成したパスキーは、このクライアントでは利用できない可能性が非常に高い（例：ユーザーがmacOSのパスキーのみを持っており、今回Windowsからログインしている場合）。
• パスキー認証がサポートされていない: 現在のクライアントはプラットフォームオーセンティケーターをサポートしておらず、QRコードを介したクロスデバイス認証をサポートする可能性も非常に低い。

決定としては、パスキーログインが成功する可能性は低いとされ、したがってパスキーログインをトリガーすることなくフォールバックオプションが自動的に提供されます。このアプローチは、ユーザーが「パスキーでサインイン」オプションを選択することを覚えておく必要をなくし、プロセスを合理化して導入率を高め、混乱を招く行き止まりがユーザーに表示されるという最悪のシナリオを回避するため、はるかにユーザーフレンドリーです。

上記の例では、クライアントがWindows 11デバイスでありmacOSのパスキーにアクセスできる可能性が低いため、ログインはパスワードにフォールバックし、アカウントのステータスとセキュリティに基づいてさらなる認証要素を引き続き要求します。認証システムのセキュリティ要件に応じて、このようなケースでどの認証方法をトリガーするか（例：直近で成功したパスキー以外の認証オプションなど）を完全に制御できます。

3.2.3 パスキーセレモニーの中止#

Webログイン中にユーザーが認証画面に遭遇したとき、特にパスキーベースの認証を初めて使用する場合などには、驚いたり圧倒されたりする可能性があります。これにより、エラーが原因ではなく、単に何が起こっているのか分からないために、ユーザーが認証プロセスを中止してしまう可能性があります。この行動を想定し、最初の中止はエラーではなく通常のイベントとして扱うことが重要です。

最初の中止画面では、何が起こっているのかを穏やかで安心できる方法で明確に説明し、ユーザーにプロセスの再試行を推奨する必要があります（上記のGoogleの例を参照）。この画面は不安を最小限に抑えるように設計し、中止をユーザー体験の通常の予想される一部として扱う必要があります。多くのユーザーは、単に認証画面を認識できなかったり、プロセスに不慣れであったりするために中止する可能性があります。したがって、再試行をデフォルトの提案とすべきです。

しかし、2回目の中止が発生した場合、状況は異なる方法で扱われるべきです。2回目の中止は、プラットフォームオーセンティケーターの問題、ユーザーが適切なパスキーを見つけられない問題、またはWebAuthnセレモニーの技術的障害など、何らかの事態が実際に間違って進んでいることを示している可能性があります。この時点で、システムは問題が発生したことを説明し、フォールバックオプションを少し強く提案する別の画面を提示する必要があります。

2回目の中止画面では、ユーザーに代替の認証方法への切り替えを促す必要があります。ユーザーがさらなるフラストレーションを感じることなく、ログインを成功できるようにする必要があります。上の画面でわかるように、Googleは依然として「再試行」を提案していますが、同時に何らかの問題が発生した可能性が高いことをユーザーに示しています。

3.3 パスキー実装アプローチの比較#

次の表は、最も重要な特徴を要約することにより、様々なアプローチを比較するのに役立ちます。

DIY（自作）アプローチは通常手動パスキーログインアプローチに従い、Conditional UIとユーザーによるパスキーへのオプトインに依存するため、パスキーのログイン率は非常に低くなり、ユーザーのフラストレーションを招きます。識別子ファーストアプローチでは、Conditional UIの上に綿密に考え抜かれたデバイスロジックを確立する必要があり、この点でCorbadoが役立ちます。独自のデバイスロジックとパスキーインテリジェンスを構築することは推奨されません。このルールセットは、新しいデバイス、新しいWebAuthn、クラウド同期機能（例：GPMパスキー）に合わせて継続的に微調整や調整を行う必要があるためです。

4. パスキーのリカバリー#

パスキーのリカバリーは、ユーザーがパスキーへのアクセスを失った際にセキュリティとユーザー体験を維持するための重要な側面です。 これはMFAに依存するシステムにおいて特に重要です。MFAの場合、リカバリープロセスはユーザーがアカウントへのアクセスを回復できるようにしつつ、セキュリティが維持されることを保証する必要があります。リカバリーアプローチは、システムで使用される認証のレベルに基づいて調整されなければなりません。

4.1 単一要素リカバリーと多要素リカバリー#

SFAシステムでセキュリティを維持するため、リカバリーには一般的にメールアドレスや携帯電話番号などの識別子に対するコントロールを証明することが含まれます。

• メールOTP: OTPがユーザーの登録済みメールアドレスに送信されます。検証されると、ユーザーはアクセスを回復し、新しいパスキーを作成できます。
• SMS OTP: メールのリカバリーと同様に、OTPが登録済みの携帯電話番号に送信されます。ユーザーはこのOTPを使用してアカウントへのアクセスを回復できます。

これらの方法はわかりやすいですが、ユーザーの連絡先情報を最新の状態に保つことに依存しています。したがって、定期的なログイン時にユーザーにメールアドレスと電話番号の検証を定期的に促すことが不可欠です。

**多要素認証（MFA）**システムでは、リカバリーがより複雑になります。MFAは複数の独立した要素（パスキー、ソーシャルログイン、OTPなど）に依存しているため、1つの要素（パスキーなど）が利用できないという理由だけで、ユーザーがアクセスを失うべきではありません。

• 代替要素の使用: パスキーを紛失した場合、ユーザーはパスワード＋SMS OTPや認証アプリなど、他の2つの要素を使用して認証できます。認証されると、新しいパスキーを作成できます。
• 他のパスキーの使用: ユーザーがパスキーを持つ他のデバイスを所有している場合、適切なヒント（例：iPhoneからのパスキーの使用を要求する）があれば、それらを使用してアクセスを回復できる可能性があります。
• 新しいパスキーの作成: リカバリー方法で認証した後、MFAのセットアップが損なわれないように、ユーザーは新しいパスキーを作成するよう案内されるべきです。

SFAシステムとMFAシステムの両方において、重要なのは、ユーザーの摩擦を最小限に抑えながら、リカバリープロセスが堅牢で安全であることを保証することです。

4.2 スマートMFAリカバリー：MFAリカバリーコストのデジタル化#

機密性の高い個人データを扱うシステム、規制対象産業、または政府のサービスにおいて、標準的なメールOTPおよび携帯電話番号OTPは、リカバリーに常に十分であるとは限らず、利用できない場合もあります。そのような場合、スマートMFAリカバリーメカニズムが、高いセキュリティ基準を維持しつつ、ユーザーにシームレスな体験を提供する高度なアカウント復旧方法を提供します。

最も効果的な方法の1つが、ライブネスチェックを伴うセルフィー認証です。このプロセスでは、ユーザーが身分証明書の写真を撮影します。さらに、セルフィーのライブネスチェックによってセルフィーがリアルタイムで撮影されていることが確認され、ユーザーが物理的に存在し、撮影された身分証明書と一致することが確認されるため、静止画像や盗まれた身分証明書を使用した詐欺を防止できます。使用される技術に応じて、ライブネスチェックはカメラまでの距離を変えたり、頭を180度回転させたりする短い動画の録画（例：Apple Face ID）のいずれかによって行われます。

この方法は、メールやSMS OTPなどの従来のリカバリー方法が利用できない、または古くなっている場合にも特に役立ちます。例えば、以下はセルフィーを撮影し、続いてOnfidoのライブネスチェックを行う例です。

例：Onfidoによるライブネスチェック付きセルフィー認証

• 政府システム、規制対象産業、または大規模な商用サービスは、身分証明書で利用可能な情報を検証するために使用できる個人データを持っています。生年月日などが利用できない場合は、身分証明書を介して収集された情報を手動リカバリープロセスにおける要素として使用できます。

さらに、他のスマートリカバリー方法には以下のようなものがあります。

• クロスデバイスリカバリー: ユーザーが信頼できるセカンダリデバイスを持っている場合、QRコードをスキャンしてアカウントを復旧できます。
• 既知の環境: 過去に正常に使用した同じデバイスにまだアクセスできるユーザーは、このデバイスを使用して追加の保証要素を提供し、手動リカバリープロセスを支援するために、同じデバイス、プロバイダー、および場所から行動しているという証拠を提供できます。GoogleがGmailアカウントの復旧に使用しているアプローチです。
• Digital Credentials API: IDウォレットの普及に伴い、このAPIを介した直接検証が、安全でユーザーフレンドリーなアカウント復旧においてますます重要な役割を果たすことが期待されています。

スマートMFAリカバリー方法は、特に機密性の高い情報や規制対象の情報を扱う際に、ユーザーがアカウントへのアクセスを取り戻すための安全で直感的な方法を提供することを目的としています。これらのアプローチは、メールや電話によるリカバリーなどの従来の方法が利用できない場合でも、ユーザーが安全かつ効率的にアクセスを回復できることを保証します。スマートリカバリーは、MFAリカバリーのコスト削減に役立ちます。

4.3 MFAリカバリーの頻度：電話番号とパスキー#

パスキーはクラウドで同期されるため、36ヶ月の期間におけるMFAリカバリーのコストははるかに低くなります。これは、携帯電話番号の変更は、AppleからAndroidへの切り替え（またはその逆）よりもはるかに頻繁に発生するためです。電話や電話契約の変更があった場合でも、パスキーは復元されます。

したがって、同期されたパスキーへのアクセスを失うことは、携帯電話番号へのアクセスを失うことよりも頻度が低くなります。携帯電話番号の喪失は、従来の消費者向けMFAシステムにおけるリカバリーの苦痛のほとんどを引き起こしています。

それでも、ユーザーベースの拡大に伴い、そのようなケースは依然として多大な手動サポートコストを引き起こすため、デジタルソリューションで処理する必要があります。これについては次のセクションで見ていきます。

5. プロダクトマネージャーと開発者への推奨事項#

パスキーを認証システムに統合する際は、高いセキュリティレベルを維持しながらシームレスなユーザー体験を確保するために、フォールバックオプションとリカバリー戦略の両方を慎重に計画することが重要です。パスキーログインのログイン率を最大化するには、次の推奨事項を考慮してください。

• 識別子ファーストアプローチを採用する: このアプローチはよりユーザーフレンドリーであり、ログインプロセスにおける摩擦を減らします。ユーザーに最初に主要な識別子（例：メールまたは電話番号）を入力するよう求めることで、システムはパスキーログインが可能かどうかを自動的に判断できます。これにより、ユーザーが手動でパスキーのオプションを選択することに頼ることなく、スムーズで直感的なログイン体験が保証されます。
• ユーザー体験を向上させるための分かりやすい中止画面を使用する: セキュリティを最優先すべきですが、ユーザーのパスキー採用を支援するプロセスを設計することも不可欠です。初回の中止が正常として扱われるようにし、再試行のための明確なガイダンスを提供してください。
• フォールバックおよびリカバリーオプションを安全に保つ: フォールバック方法（メールOTPやSMS OTPなど）が、主要な認証方法のセキュリティレベルと一致していることを確認します。たとえば、パスキーを使用するMFAシステムでは、同じセキュリティ基準を維持するために、フォールバックでも複数の要素を要求する必要があります。
• 定期的なリカバリーのプロンプトを自動化する: パスキーを使用する際にリカバリーオプションが最新の状態に保たれるよう、ログイン時に連絡先情報（メールアドレスまたは電話番号）の検証をユーザーに定期的に促します。これにより、古いリカバリー方法が原因でユーザーがアカウントから締め出される可能性が低くなります。
• セキュリティの強化とサポートリカバリーコストの削減のためにスマートリカバリー方法を検討する: 規制対象産業、またはオンライン認証と照合するための個人データにアクセスできるシステムの場合、ライブネスチェック付きのセルフィー認証のような高度なリカバリー方法を検討してください。この方法は、セキュリティ要件に応じて、リカバリープロセスを直感的かつユーザーフレンドリーに保ちながら、追加のセキュリティレイヤーを提供できます。

パスキーのログイン率を最大化できるかどうかは、これらの要素をどれだけうまく実装できるかにかかっています。スムーズなフォールバックおよびリカバリーオプションを確保することで、ユーザーは主な認証方法としてパスキーを使用することに自信を持てるようになります。

6. Corbadoができること：UIコンポーネントとパスキーインテリジェンス#

Corbadoは、完全な新しい認証システムを必要とするグリーンフィールドプロジェクト、および既存の認証システムにパスキーを追加する必要がある既存プロジェクトのどちらに対しても、識別子ファーストアプローチを実装するために必要なすべてを提供します。

6.1 様々なユースケース向けのUIコンポーネント#

どちらの製品も、ニーズに合わせて調整できるUIコンポーネントを提供しています。

1. Corbado Complete：パスキーファーストの認証でプロジェクトを開始
   これは当社の完全な認証システムであり、ログインプロセスを合理化するためのシームレスな識別子ファーストアプローチが含まれています。Corbado Completeは、ユーザーが識別子を提供した後にパスキーログインが可能かどうかを自動的に判断することで、安全でユーザーフレンドリーな体験を可能にします。これにより摩擦が減り、スムーズなログイン体験が保証されます。これはパスキーの導入を最大化するために不可欠です。
2. Corbado Connect：あらゆるアプリに移行なしでパスキーを追加
   すでに認証プロセスが確立されており、機能強化としてパスキーを追加したい企業向けに、Corbado Connectは単一要素および多要素戦略のアドオンソリューションを提供します。このアプローチは、パスキーを安全で便利なオプションとしてシームレスに統合することで既存のインフラストラクチャを補完し、現在のシステムを全面改修することなくユーザーがパスキー経由で認証できるようにします。たとえば、Corbado ConnectはAmazon Cognitoにシームレスに組み込むことができます。

私たちは、特に消費者向け企業に合わせて調整された、Googleやその他のビッグテック分野の著名なプレーヤーなどの業界リーダーと自社の方法を厳格に一致させています。

6.2 パスキーインテリジェンスが実現する識別子ファーストアプローチ#

私たちの目標は、パスキーの導入（つまりパスキーの作成）を最大化するだけでなく、これらのパスキーがアクティブに使用されて高いログイン率を促進する（したがってセキュリティを高め、SMS OTPのコストを削減する）ようにすることです。当社のUIコンポーネントは、識別子ファーストアプローチを念頭に置いて構築されており、クライアント環境と既存のパスキーに基づいてパスキーの可用性とアクセス可能性を決定するパスキーインテリジェンスに直接接続されています。これらは、議論されたすべてのフォールバックおよびリカバリー機能をサポートしています。次の画面は、当社の中止と再試行のロジックを示しています。

最初のパスキー中止

2回目のパスキー中止

パスキーの導入とパスキーの使用の両方に焦点を当てることで、セキュリティとユーザー体験のバランスを取り、ユーザーが摩擦のない方法でパスキーに関わり続けられるように支援します。

7. 結論#

このガイドでは、認証システムへのパスキーの統合に伴う様々なフォールバックおよびリカバリー戦略を探りました。導入部で提起された重要な質問には、全体を通して対処しました。

• どのようなフォールバックのシナリオが存在するか？ 特定のデバイスでパスキーのサポートがない、またはパスキーにアクセスできないなど、いくつかのフォールバックシナリオが発生する可能性があります。セキュリティを維持し、スムーズなUXを提供するために、パスキーログインが不可能な場合はメールやSMS OTPなどのフォールバックオプションを利用できるようにする必要があります。
• リカバリーはどのように処理すべきか？ リカバリープロセスは、認証システムのセキュリティレベルに一致するように設計する必要があります。SFAシステムではメールまたはSMS OTPで十分な場合がありますが、MFAシステムでは、アクセスを回復して新しいパスキーを作成するために代替要素を使用する必要があります。規制が厳しい、または機密性の高い環境では、ライブネスチェック付きのセルフィー認証などのスマートリカバリー方法が追加のセキュリティを提供します。

このガイドで概説されているベストプラクティスに従うことで、プロダクトマネージャーと開発者は、ユーザーに安全かつシームレスなログイン体験を提供する堅牢なパスキーベースの認証システムを設計できます。セキュリティがユーザー体験の代償としてもたらされる必要はありません。慎重な設計と計画により、その両方を達成することができます。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

Identifier-Firstアプローチでは、現在のデバイスでパスキーにアクセスできない場合、パスキーログインをどのように処理しますか？#

パスキーにアクセスできない可能性が高い場合（例：WindowsデバイスからmacOSのパスキーにアクセスする場合）、システムは自動的にパスキーのプロンプトをスキップし、代わりにパスワードやOTPなどのフォールバックオプションを提示します。これにより、「ユーザーに考えさせない」戦略に従い、成功する可能性が高い場合にのみパスキーログインをトリガーすることで、混乱を招く行き止まりを回避します。

ユーザーがパスキー認証のフローを途中で中止した場合はどうなりますか？#

初回の中止は通常のイベントとして扱い、ユーザーに再試行を促す穏やかな画面を表示する必要があります。多くのユーザーは単に認証画面に不慣れであるために中止するからです。2回目の中止が発生した場合は、プラットフォームオーセンティケーターやパスキーの可用性に問題がある可能性があるため、システムはフォールバックの認証オプションを提示する必要があります。

ユーザーがパスキーにアクセスできなくなった場合、MFAシステムにはどのようなリカバリーオプションがありますか？#

MFAシステムでは、パスワードとSMS OTPなどの2つの代替要素で認証するか、別の信頼できるデバイスのパスキーを使用してから新しいパスキーを作成することで、アカウントを復旧できます。従来のリカバリー方法が利用できない規制の厳しい業界では、ライブネスチェックを伴うセルフィー（自撮り）認証などのスマートな方法が、追加の安全なリカバリーパスを提供します。

手動の「パスキーでサインイン」ボタンによるアプローチは、Identifier-Firstアプローチに比べてなぜ導入率が低くなるのですか？#

手動によるアプローチでは、ユーザー自身がパスキーのオプションを覚えて選択する全責任を負うため、通常はパスキーのログイン率が大幅に低くなります。また、プラットフォームオーセンティケーターでパスキーが見つからない場合、ユーザーは不明確なエラーメッセージに遭遇し、フラストレーションを感じてログインを諦める可能性があります。