本記事は 2024年9月11日 に公開された「All You Need To Know About Passkeys at Auth0!」を機械翻訳した記事となります。
パスキーに関する情報はたくさんあり、各ベンダーそれぞれが標準規格を実装しています。もしまだパスキーについて詳しくない場合は、こちらのブログ記事をお勧めします。
それでは、Auth0 におけるパスキーについてよく寄せられる質問にお答えします。
無料プランでもパスキーは利用できますか？
まず最初に、最も気になる点について明確にしておきましょう。パスキーはすべてのプランに含まれており、無料プランでも追加費用なしでご利用いただけます。私たちはパスワードレスの未来を目指しており、パスキー認証はその取り組みの一環です。
パスワードからパスキーへの移行
業界全体がパスワードレスの未来へと向かっており、Auth0 も同じ目標に取り組んでいます。
Auth0 はパスワードを完全に廃止しますか？
現時点ではそうではありません。現在は、パスワードに加えてパスキー認証をオプションとして提供しています。ユーザーは、状況に応じてパスキーまたはパスワードのいずれかを選択できます。
ユーザーはログインにパスキーのみを使用できますか？
はい、使用できます。エンドユーザーは、パスキーのみでサインアップやログインができるため、完全なパスワードレス体験が可能です。パスキーは、アカウント認証のための堅牢な 1 番目のプライマリの認証要素として機能し、セキュリティ向上とユーザーフレンドリーな体験を提供することを目指しています。最終的な目標は、パスワードを置き換えることです。
ユーザーはサインアップやログインに引き続きパスワードを使用できますか？
はい、使用できます。設定でパスキーが有効になっている場合でも、エンドユーザーはパスキーかパスワードのどちらでサインアップやログインするかを選択できます。
パスワードを利用している既存のユーザーはどうなりますか？
Auth0 ダッシュボードでプログレッシブ登録 (Progressive Enrollment) を有効にすると、パスワードを利用している既存のユーザーは、以降のログインでパスキーを登録するよう促されます。
パスキーのみのフロー (パスワードを一切利用しない) をサポートしていますか？
現時点ではサポートしていません。パスキーに加えて、パスワードを併用する選択肢を残しているのは、パスキーをサポートしていない古いデバイスやブラウザとの互換性の問題がまだ存在するためです。パスワードは引き続き現実的な認証方法です。
つまり、現時点ではデータベース接続においてパスワードの無効化はサポートしていません。
どのデバイスとブラウザがパスキーに対応していますか？
パスキーは、オペレーティングシステムやブラウザによって対応レベルが異なります。最新のデバイスやブラウザでのサポート状況については、passkeys.dev デバイスサポート (W3C WebAuthn Community Adoption Group および FIDOアライアンス のメンバーによって維持管理されています) をご確認ください。
Oktane 2023 の セッション でパスキーの詳細や実際の動作を確認できます。
Auth0 テナントでパスキーを有効化
パスキーは単にトグルを切り替えるだけで有効化できます。Auth0 でのパスキーを使ったサインアップやログインの流れについては、ドキュメントを参照してください。ここでは、パスキーの有効化に関する具体的な質問にお答えします。
ユーザーに対してパスキーを有効にするにはどうすればよいですか？
パスキーは Auth0 ダッシュボードのデータベース接続設定のセクションから有効化できます。具体的には、Auth0 ダッシュボードにログインし、Authentication -> Database -> 対象の接続 -> Authentication Methods -> Passkey の順に選択することで設定できます（下記のスクリーンショット参照）。
パスキーの有効化の詳細については、こちらのブログ記事もご参照ください。
パスキーを有効にするための前提条件はありますか？
はい、パスキーには以下の前提条件があります。
- New Universal Login の有効化: パスキーのような新機能は New Universal Login でのみ提供されているため、切り替えを推奨します。
- カスタムログインページの無効化: カスタムログインページを有効にしている場合、New Universal Login が Classic に戻り、上記の要件を満たせなくなります。
- Identifier First Login の有効化: 最初にログイン識別子を入力し、その後パスキーまたはパスワードのいずれかを選択できるフローを有効にします。
- 「Requires username」の無効化: 柔軟な識別子が有効になっていない接続では、ユーザー名を利用できません。パスキーをユーザ名と一緒に使用する場合は、柔軟な識別子の属性を有効化する必要があります。
- 「Use my own database」の無効化: パスキーは外部のカスタムデータベースには保存されず Auth0 内に保存する必要があります。「Import Users to Auth0」を有効にしない限り、「Use my own database」は無効にする必要があります。（つまり自動移行が有効な場合は例外となります。） 上記のいずれかの要件が満たされていない場合、パスキーを有効にしようとすると、下記のようなチェックリストが表示されます。:
パスキーを有効にする上で、他に重要な注意点はありますか？
重要な注意点として、パスキーの登録後に Relying Party) のドメイン名を変更しないようにする必要があります。パスキーは特定の Relying Party ドメイン名に対して作成されているため、ドメイン名を変更すると既存のパスキーがすべて無効になってしまいます。
パスキーでログインするための他の設定はありますか？
はい。エンドユーザーにパスキーの選択肢をどのように表示するかを選択することができます。パスキーでログインするには、パスキーボタンと自動入力の2つの選択肢があります。パスキーが有効にされるとデフォルトで両方の選択肢が有効になります。
FIDO UXガイドライン によると、FIDO のリサーチでは、専用のパスキーボタンと自動入力の成功率と満足度が調査されました。FIDO のテストでは、自動入力がパスキーでのサインインにおいて最も高い成功率になることが示されています。
ただし、自動入力がすべてのシナリオで機能するわけではないことに注意する必要があります。たとえば、ブラウザで自動入力が無効になっている場合、パスキーボタンが代替の UI となります。
Auth0 におけるパスキー設定
ローカル登録 (Local Enrollment) とは？
ローカル登録を有効にし、QR コードを用いてクロスデバイス認証を行う際、Auth0 はユーザーに 2 台目のデバイスでパスキーを登録するように提案します。ローカル登録により、安全で手間のかからないログインが可能になります。なぜなら、それ以降 2 台目のデバイスからのログインではパスキーが利用できるようになるからです。ユーザーは 2 台目のデバイスにログインするために何度も QR コードを使用する必要がなくなり、代わりにローカルのパスキーで簡単にログインできます。
プログレッシブ登録 (Progressive Enrollment) とは？
プログレッシブ登録では、パスワードでログインした既存ユーザーに対して、パスキーを登録するように提案します。これにより、それ以降のログインでパスキーが利用可能になります。
パスキーが選択された場合に CAPTCHA 検証をスキップするのはなぜですか？
パスキーはすでにフィッシング耐性のある認証方法を提供しています。高速でシームレスでかつ安全なログイン体験を実現するために、ログイン中に CAPTCHA のような摩擦を加えることは最適ではありません。したがって、CAPTCHA が表示された場合でも、ユーザーがパスキーでログインすることを選択すると CAPTCHA 検証はスキップされます。ただし、CAPTCHA が表示され、パスワードでログインすることを選択した場合には、CAPTCHA 検証を行う必要があります。
ユーザーが登録できるパスキーの数に制限はありますか？
はい。現時点では 1 ユーザーあたりパスキーの登録は最大 20 個までに制限しています。1 人のユーザーが複数のパスキーを持つことができるため、たとえば QR コードを使ってクロスデバイス認証を行うと、Apple デバイスと Google デバイスそれぞれでパスキーを登録することができます。
パスキーにおけるセキュリティと攻撃防御
攻撃者が QR コードを悪用しようとした場合はどうなりますか？
FIDO のクロスデバイス認証には、2 台のデバイス間の物理的な近接性を確認するために Bluetooth を利用した検証メカニズムが組み込まれています。このプロセスはユーザーにとってはシームレスですが、仮に攻撃者が QR コードを入手してリモートログインを試みても、クロスデバイス認証は遠隔接続では機能しないため、攻撃は阻止されます。パスワードのように世界中のどこからでも攻撃できるのではなく、攻撃可能な範囲は物理的に数メートル以内に限定されます。
クロスデバイス認証に Bluetooth は必須ですか？全体的なユーザー体験にどのように影響しますか？
はい。クロスデバイス認証における Bluetooth を使った近接性検証は、エンドユーザーにとってシームレスに行われます。Bluetooth を無効にしている場合、ユーザーがクロスデバイス認証のために QR コードをスキャンすると、Bluetooth を有効にするように促すプロンプトが表示されます。
攻撃防御機能はパスキーに適用されますか？
はい。不審な IP スロットリングなどの特定の攻撃防御機能は、パスキーにも適用されます。パスキーを使用する際には、パスワードが存在しないため漏洩パスワード検知 / クレデンシャルガードはスキップされます。ボット検知は、ログイン前の評価を行いますが、パスキーでのログインを選択した場合には CAPTCHA 検証ステップをスキップします。
フローで MFA (多要素認証) が有効な場合はどうなりますか？
MFA ポリシーは、パスキーを使ったログインにも引き続き適用されます。MFA 設定によっては、2 番目の要素が要求されることになります。パスキーが認証方法として使用された際に 2 番目の要素を要求しないようにしたい場合は、カスタムロジックを実装することで可能です。
パスキーを 2 番目の要素として使用できますか？
現時点ではできません。パスキーはアカウント認証の 1 番目のプライマリの認証要素であり、セキュリティを強化し、よりユーザーフレンドリーな体験を提供するために設計されています。最終的な目標は、パスワードを置き換えることです。
パスキーの管理と運用
テナントのログでパスキーをどうやって調査すればいいですか？
パスキーは追加の認証方法であるため、ログのイベントタイプコード で定義されている既存のイベントコードを利用しています。ただし、使用された認証方法を明確にするために、以下の項目を追加しています：
- サインアップ時: タイプ
のイベントには、サインアップ時に使用された認証方法を示すss
フィールドが追加され、値はdetails.authentication_method
またはpassword
のいずれかになります。passkey - ログイン時: タイプ
のイベントには、ログイン時にユーザーがパスキーを使用した場合はs
が含まれます。"performed_amr": ["phr"]
配列にはユーザーが辿ったプロンプトの一覧が記録されます。(details.prompts
は "phishing-resistant" の略で、amr (Authentication Method Reference) クレームにおけるパスキーの標準的な値です。)phr - プログレッシブおよびローカル登録: 登録が成功した場合は
、失敗した場合はgd_enrollment_complete
が記録されます。gd_webauthn_enrollment_failed
Management API でパスキーを利用できますか？
はい、Auth0 Management API を使用してパスキーの一覧取得や失効を行えます。詳細は、こちらのパスキー管理についてのブログ記事をご覧ください。
Actions でパスキーを利用できますか？
はい。例えば、Post-Login のトリガー 内では、ユーザーがパスキーで認証したかどうかを確認できます。
イベントオブジェクト内の
authentication.methodspwdpasskeyアカウント回復
ユーザーはパスキーをどのようにして回復できますか？
Auth0 は、認証に使用できるパスキーに関する公開情報（公開鍵など）のみを保存します。パスキー（秘密鍵などを含む）は、それぞれのプラットフォーム（Apple や Google など）内に保存され、Relying Party（Auth0 など）とは共有されないため、エンドユーザーは必要に応じてプラットフォームから直接パスキーを取得して回復する必要があります。
ユーザーはアカウントをどのようにして回復できますか？
アカウントを回復する手順はこれまでと同じで、ユーザーはまず受信したメール内のリンクをクリックしてメールアドレスを検証した後に、新しいパスワードを設定できます。
パスキーに関する FAQ が、パスワードから解放され、パスキーを導入するのに役立つことを願っています。他にも不明な点があれば、コメントにてご質問ください。担当チームが喜んでお手伝いします。