同期パスキーのtoC向けデプロイケースのホワイトペーパーを読んだメモ
はじめに
こんにちは。この記事が投稿される時刻はまだ #passkeysweek 中でしょうか。おそらく日本標準時（UTC+9）は無理でもハワイ標準時(UTC-10)までには投稿できているでしょう。たぶん。
この記事ではFIDOアライアンスから発行された以下のホワイトペーパーを読んで各章/節の興味深かったポイントをまとめます。このホワイトペーパーは2024/3/31に発行された時点でコンシューマ向けサービスに同期パスキーのデプロイケースをまとめたものです。
このホワイトペーパーは、実装や技術仕様のドキュメントと実際にサービスに導入までの設計の間の知識を補完するものとして個人的にとても好きなドキュメントです。本記事から原文の方を参照する方が増えるといいなと思います。
ただ、一点注意としてこのホワイトペーパーの概要でも述べられていますが、発行時点から新たに導入された機能によって事情が変わっている箇所があります。
ホワイトペーパー読んだメモ
目次
このホワイトペーパーの目次は以下です。トピックを大きく分けると2~6章の5つのトピックで構成されています。
- introduction
- パスキーのタイプ
- パスキーの登録
- パスキーの認証
- パスキーの管理画面
- パスキーのアクセシビリティ
- conclusion
この記事では個人的主観より2~5章を重点的に読んだメモを残します。
2.パスキーのタイプ
パスキーには「同期パスキー（Synced Passkey）」と「デバイス固定パスキー（Device-Bound Passkey）」のタイプがある。また、OSやブラウザなどのユーザ環境によって利用できる機能が異なる。
原文のTable1
2.1 パスキーの種類がユーザとRPに与える影響
ユーザにとって同期パスキーならデバイス紛失/デバイス変更時に他のデバイスに同期されたパスキーを引き続き使い続けることができる。一方でデバイス固定パスキーはこれらのケースに対してユーザ自身がパスキーのバックアップをする必要がある。
RPにとって同期パスキーはユーザのアカウント復旧成功率が高まるメリットがある。ただし同期/デバイス固定パスキーの種類に関わらず、RPはユーザのパスキーロスト時に備えて代替認証手段やアカウント復旧手段を用意すべき。
2.2 なぜパスキー紛失時に備える必要があるのか
以下のようなケースでパスキーをロストをする可能性があるため。
- デバイス固定パスキー
- パスキーを登録したデバイスを紛失するケース
- 同期パスキー
- パスキープロバイダアカウントのBANされるケース
- パスキープロバイダアカウントに認証ができなくなるケース
- ユーザがパスキープロバイダがサポートしていないデバイスを利用するケース
- ユーザがパスキー移行をせずにパスキープロバイダを変更したケース
2.3 RP側でパスキーの種類を検出する方法
RPはbackupEligibilityフラグを用いて登録されたのが同期パスキーorデバイス固定パスキーかどうかを判定できる。もしここでデバイス固定パスキーだった場合、追加の認証方法の設定や他のデバイスのパスキーの登録の推奨をすることができる。
3.パスキーの登録
3.1 パスキー登録の訴求方法
- アカウント作成時/高セキュリティ要件の機能利用時にパスキーを強制登録させる
- この訴求はフィッシング攻撃を防ぐのに最も効果的
- パスキー登録できない/したくないユーザがドロップしてしまう
- （memo: 例えば、メルコイン取引機能はパスキーの登録が必須になっています）
- アカウント関連の操作時にパスキーの登録を訴求する
- FIDOアライアンスのUXガイドライン（memo:今はDesignGuidelines）で推奨されている
- アカウント関連の操作中はパスキー登録を提案されても煩わしさを感じづらいため
- しかし、これらのタイミングは少ないため登録数の影響は小さい可能性がある
- （memo: 例えば、TikTokのiOSアプリ, Amazonではアカウント管理画面で訴求されていた（2024/06時点））
- サインイン後にパスキーの登録を訴求する
- 多くのユーザに訴求できる機会がある
- しかし、パスキーの登録を望まないユーザにとっては煩わしく感じるリスクもある
- （memo: 多くのサービスがこれらの形態をとっているように思える。マネーフォワードはこの訴求はやめたとのこと。）
3.2 パスキーの表示名は何を設定するか？
RPはuser.nameやuser.displayNameを用いてユーザが作成するパスキーの表示名を設定できる。この値はAutofillのUIやパスキープロバイダの管理画面上で利用されている。
（memo: 以下Chromeでの例）
autofillの例
パスキープロバイダの管理画面の例
(memo: ここまで)
| ケース | 例 | 理由 |
|---|---|---|
| RP上でユニークかつ不変なもの | アカウント名 | RPとパスキープロバイダ間でズレが発生しないので混乱しづらい。 しかし全てのRPがこの識別子をもっているわけではない。 |
| RP上でユニークかつ可変なもの | メールアドレス,電話番号 | ユーザがこの値を変更した場合、RP側からパスキープロバイダ上のデータを更新できずにズレが発生してしまう |
| 非ユニークかつ可変なもの | マスクされたメアド,ニックネーム | AutofillUI上で表示された場合にユーザが混乱してしまう可能性がある。非推奨（not recommend） |
3.3 パスキー登録前の再認証は必要か？
| ケース | 特徴 |
|---|---|
| 再認証不要で登録が可能 | ユーザが簡単にパスキーを登録できる アカウントハイジャックのリスクを許容できるいくつかのRPで採用されている。 |
| フィッシング耐性のない認証で再認証を要求 | フィッシングリスクを低減しつつパスキー登録のUXを実現できる。 多くのRPではパスキー登録前に再認証を要求する。しかし、フィッシング攻撃は完全に防ぐことはできない。 |
| フィッシング耐性のある認証で再認証を要求 | フィッシングリスクを防げる。これはフィッシング攻撃を重大なリスクと捉えているRPで採用されている。 |
3.4 RPは同期パスキー/デバイス固定パスキーの登録を強制すべきか？
| ケース | 特徴 |
|---|---|
| 同期パスキー、デバイス固定パスキー両方を受け入れる | パスキーを登録できるユーザが増えるメリットがある。 デバイスやプラットフォームによって登録できるパスキーは異なるので多くのユーザデバイスをサポートする場合は両方受け入れるべき。 このケースでは多くのユーザがパスキーを利用できるようになる一方、デバイス固定パスキーユーザがパスキーをロストした際のCS対応コストが上がる可能性がある。 |
| 同期パスキーのみ受け入れる | パスキーロストの確率が下がるため利便性が上がる。 パスキー登録時の再認証要求など、パスキーをロストしたときの影響が大きいRPではこのケースが適している可能性がある。 |
| デバイス固定パスキーのみ受け入れる | RPにとってより高いセキュリティ強度を維持できる。 高いセキュリティレベルを要求するサービスではパスキープロバイダの認証強度に依存しないように、この方針となる場合がある。しかし、デバイス固定パスキーが作れないデバイスも存在するため注意が必要 |
3.5 異なるプラットフォームデバイスでパスキーを登録する方法
同期パスキーにおいて異なるプラットフォーム間で同期できないケースもある。
その場合はCross-device Authentication(CDA)を用いることで、すでにサインイン済みのデバイスを通じて他デバイスのパスキーを登録することができる。
しかし、一般的なユーザにとって他のデバイスでパスキーを登録する操作は複雑に感じられることがある。その場合、RPはWebAuthnAPIの「authenticatorAttachment」パラメータに「platform」を設定することで操作中のデバイスでのみパスキーを作成させることができる。
| ケース | 特徴 |
|---|---|
| authenticatorAttachmentに「platform」を指定する | パスキー作成時に表示されるオプションが減りユーザの混乱を低減できる。 toCサービスにおいてセキュリティキーを利用するユーザは少数のためこのケースの採用は適している。 もしまだパスキーを登録していない別デバイスで登録したい場合は他の認証でサインインした後、パスキーを登録させる必要がある。 |
| authenticatorAttachmentを指定しない | プラットフォーム認証器（デバイスに搭載された認証器や3rdパーティマネージャ）だけではなくCDA経由やセキュリティキーでのパスキー登録もサポートできる。 |
| RPのWebページでのインタラクション後にauthenticatorAttachmentの値を変化させる | パスキー作成の前にパスキーを作成するデバイスの種類をUI上でユーザに指定させる。その指定によってauthenticatorAttachmentの値を変更する。※ |
※memo: Googleの例(「別のデバイスを使用」で「closs-platform」、「パスキーを作成」で「platform」の値になる)
4. パスキーの認証
4.1 パスキーでの認証におけるサインインUI
| ケース | プロセス | 特徴 |
|---|---|---|
| 識別子(ユーザID)入力優先アプローチ | サインイン画面にはユーザID入力フォームのみが存在する。パスキーAutofillが利用できるユーザはパスキーでサインイン可能。利用できないユーザはユーザID入力後に表示される利用可能な認証方法でサインインを行う。 | FIDOアライアンスのUXガイドラインで推奨されている。Autofillは識別子入力も省略できるため良いユーザ体験を提供できる。 ただし、Autofillに対応していないユーザ環境は利用できない。 |
| ユーザID + PWアプローチ | サインイン画面にはユーザIDとパスワード入力フォームが存在する。パスキーAutofillが利用できるユーザはパスキーでサインイン可能。利用できないユーザはID + PWでサインインを行う。 | ID+PWの入力画面に慣れているユーザの混乱を抑えられる。PWを引き続きサポートしているサービスではこれが最適なケースもある。 |
| 認証方法優先アプローチ | サインイン画面ではID連携など様々な認証方法の選択肢が表示される。その中の「パスキーでログイン（Sign in with Passkey）」を選択すると、サインインするアカウント一覧が表示され、ユーザが選択をするとサインインができる。 | 従来のサインイン画面にパスキーでの認証を追加する形で実現できる。パスキーを持っていないユーザが認証に失敗してしまう可能性がある。また、パスキーを作成したことを認識していないユーザが選択しない可能性がある。 |
memo:
ここで紹介されたアプローチは組み合わせて提供されているケースが多いと思う。
2024/11時点で各社サービスのサインイン画面をみていると以下に分けられる気がする。
| 初回入力フォーム | パスキーログインボタン あり |
パスキーログインボタン なし |
|---|---|---|
| ID入力のみ | TOKYU ID | MoneyFoward ID, MIXI M, Amazonアカウント |
| ID+PW | ニンテンドーアカウント, pixiv | - |
| なし(認証手段選択のみ) | - | - |
4.2 パスキー利用時のUserVerificationを強制すべきか
「authenticatorSelection.userVerification」を指定することでパスキー利用時にデバイス内での認証（TouchID, 画面ロック解除など）を要求することができる。
| userVerificationの値 | 特徴 |
|---|---|
| required | 2要素認証であるとみなせる※。デバイスを盗まれた場合でもUserVerificationを突破できなければ不正利用されない。しかし、TouchIDを持たない古いMac（memo: クラムシェルモードでも）ではよくないUXとなる可能性がある。 |
| preferred | UserVerificationが必須ではないため実施できない端末などでもパスキーの認証が利用できる。 |
| discouraged | UserVerificationを省略できるためFIDO U2Fのように2要素目の認証として利用されるケースがある。 |
(memo: パスキーは本当に２要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。にあるように必ずしもクライアント側で2要素認証が実施されたかどうかを担保する仕組みはない点に注意 )
4.3 パスキーでの認証時に追加の認証は必要か？
パスキーでの認証だけで多要素認証であるといえる（ケースもある）。しかし、同期パスキーではパスキープロバイダのアカウントにサインインできればパスキーを同期できるため、プロバイダ自体のセキュリティレベルに依存してしまう。よってRPはサービス自体のセキュリティ要件とユーザビリティのトレードオフを把握する必要がある。
| ケース | 特徴 |
|---|---|
| パスキーの認証のみでOKなケース | 多くのRPではこのケースでセキュリティ要件を満たせる。特にソーシャルログインを導入している場合、外部IdPに依存する状態なのでセキュリティレベルに大きな差はない。 |
| SMS OTP/TOTPを追加で認証するケース | 追加で認証を行うため、パスキープロバイダアカウントが侵害されてもサービスのアカウントは守ることができる。特にソーシャルログインを導入していないRPでは効果がある。常にこの認証を要求するのはユーザビリティ視点でマイナスなのでリスクベースで判断する必要がある。 |
| パスワードを追加で認証するケース | セキュリティ観点でのメリットは小さい。パスキープロバイダはパスワードも管理していることがほとんどであるため。 |
4.4 パスキーを持っていないデバイスでサインインする方法
パスキーを持っていないデバイスでパスキーでのサインインする場合はCross-Device Authentication（CDA）が利用できる。しかし、ユーザにとってこの方法は難しい。サインインしたいデバイスで表示されたQRコードを、パスキーを持つデバイスで読み取る必要がある。
| ケース | 特徴 |
|---|---|
| 代替の認証手段にフォールバックするケース | パスキーによるCDAよりも従来のPW + SMSの方がユーザにとってはわかりやすいケースがある。そこでサインインに成功した後、そのデバイスでパスキーを登録を訴求することができる。多くのRPではこちらを採用している。 |
| CDAでパスキーのログインをさせるケース | パスキーでの認証を強制しているケースではこちらを採用する。その場合RPはCDAの操作方法をユーザに案内する必要がある。 |
また、OSによってはCDAの挙動が異なる点に注意が必要。例えばAndroid 13以下はQRコードの読み込みにGoogle Lensなどアプリが必要。また、iOSではパスキーの認証に失敗するとCDA用のQRコードが強制的に表示される。
これらを踏まえたガイドを提供しても依然としてユーザにとってわかりづらいという課題がある。
5. パスキー管理画面
5.1 パスキーを識別するための名前
(memo:)
Googleでのパスキー管理画面に表示されるパスキーの名前
(memoここまで)
| ケース | 特徴 |
|---|---|
| パスキープロバイダ名 | 同期パスキーは異なるブラウザ/OSで利用できる。パスキープロバイダ名を表示することで識別できるようになる。 この対応はAAGUIDを用いることでRPが検出できる。しかしクライアント側で改ざんされていたり、認証器が提供しないパターンもあるので注意が必要。 |
| パスキー登録時のコンテキスト情報 UAから得たOS,ブラウザ,デバイス名 |
デバイス固定パスキーのみ登録されるケースならばこれでよい。しかし、同期パスキーは登録したデバイス以外でも利用できる。従来AAGUIDを活用されたのが近年（2023年時点）からのため、多くのRPではこちらを採用している。 |
| ユーザが設定した任意の名前 | 一部RPはパスキーの名前を設定できる機能を提供している。これによりRP側でAAGUIDを検出できないパスキーにも適切な命名ができる。しかし、ユーザが適切に命名するのが難しいこともある。特にセキュリティキーで作られたデバイス固定パスキーと違い、同期パスキーは実態がないので管理が難しい。 |
5.2 パスキー管理画面に必要な情報
ユーザはパスキー管理画面で登録した覚えのないパスキーや利用することがないパスキーの確認の削除をする。その際に参考になる情報を表示する必要がある。
| 表示する情報 | 理由 |
|---|---|
| 登録した環境 （memo:登録日,OS） |
他人に登録したパスキーかどうかを判別できる |
| 最終利用日 | 他人に登録したパスキーかどうかを判別できる もう利用していないパスキーかどうか判別できる |
| 最後に利用したデバイス名 | 他人に利用されたパスキーかどうかを判別できる |
| 同期の有無 | バックアップされているかがわかる |
| パスキープロバイダのアイコン | どこにパスキーが登録されたかわかりやすい |
5.3 パスキー管理画面で提供する機能
| 機能 | 理由 |
|---|---|
| 削除 | ユーザが疑わしいパスキーやもう利用してないパスキーを削除するため。 |
| 名前変更 | 登録されたパスキーをRP上で管理しやすくするため。 |
5.4 サーバとクライアントのパスキー登録状況の差分
RP側でパスキーを削除してもクライアント側でパスキーは削除されない。そのため、これらの更新をした際にクライアント側でも変更するようにユーザへ案内することも可能。
5.5 登録済みパスキーを使用できないユーザのリカバリ方法
ユーザがパスキーを利用できなくなった場合、多くのRPでは代替の認証手段でログインさせた後に新しいパスキーを作成させている。一方でパスキーの認証を強制しているセキュリティ要件の高いサービスではeKYCなどの堅牢な本人確認手段をもちいてアカウントリカバリをさせている。この際アカウントリカバリが脆弱なものだった場合、パスキーによって担保されていたセキュリティレベルを下げてしまうため。
“Recommended Account Recovery Practices for FIDO Relying Parties.”ではパスキーの認証器が利用不可/紛失/破損した際のアカウントリカバリ手段について述べられている。
おわりに
パスキーの設計を考える担当者にとっては考えるべきことが網羅的に説明されてあってとても良いドキュメントだなと思いました。Web上にはコードレベルの実装について良いドキュメントがありますが、設計視点でまとまったものはなかった認識だったので。
そして見えてきた課題として、このような設計ノウハウのアップデート頻度です。サービス設計はその時点で利用できる機能に依存します。このドキュメントは１年前のものでしたがすでにいくつかのアップデート項目がありました。もしパスキー担当者が新たに設計をする場合、このドキュメントのように包括的にまとまったものを読み、その上で差分をまとめていけると良いのかなと思いました。（そのためにこの記事を書いたといえなくもない...）
最後にもう一度原文のリンクを貼ります。もし間違っているところあったら教えてください。
Discussion