WebAuthn RFC
このトピックでは、FIDO2 / WebAuthn 認証に関する Discourse プロジェクトの目標を文書化することを目的としています。
なぜ？
Discourse に WebAuthn サポートを追加することで、ユーザーアカウントのセキュリティが向上し、スマートフォンの指紋リーダーなどのデバイスの安全な機能を使用して、パスワードなしで簡単にアクセス可能なアカウントを可能にします。
認証方法
- WebAuthn を第 2 要素認証器として使用する（Google Authenticator の代替として機能）
- WebAuthn を第 1 要素認証器として使用する（ソーシャルログインの代替として機能）
- WebAuthn を多要素認証器として使用する（ユーザー名なしログイン）
WebAuthn を第 2 要素認証器として使用
これにより、すでにアクティブなアカウントを持っている Discourse ユーザーが、現在 TOTP のみをサポートしている WebAuthn を 2FA として使用できるようになります。
デバイス生体認証（Android の指紋ヘッダー、Windows Hello ラップトップ）、デバイスの安全なチップ（TPM、セキュアエンクレーブ）、またはハードウェアキー（Yubikey など）など、あらゆる WebAuthn 方式がここで機能します。
これは、以下でブラウジングするすべてのユーザーに利用可能です。
- Windows 上の Microsoft Edge（Windows Hello を使用：顔認識、指紋リーダー、または PIN）
- macOS 上の Chrome（Touch ID を使用）
- Android 電話
- ラップトップ/デスクトップ/電話 + 物理キー（Yubikey、Google Titan）
WebAuthn を第 1 要素認証器として使用（パスワードなしアカウント）
ユーザーは、パスワードの代わりに WebAuthn 認証を使用して Discourse アカウントにサインインできます。第 1 要素認証器が設定されている場合、ユーザーはパスワードの代わりに認証器を使用するように求められます。
第 2 要素認証と同じ認証方法（生体認証、安全なチップ、ハードウェアキー）が第 1 要素認証でも機能します。
登録フロー
パスワードフィールドなし
ログインフロー
WebAuthn を多要素認証器として使用（ユーザー名なしログイン）
WebAuthn 入力のみを促す代替ログイン方法を公開します。登録されたセキュリティキーは、ユーザー ID 情報を Discourse サーバーに追加で渡します。
この認証方法は、現在、現代の認証キー（例：Yubikey 5）と Google Chrome 76 以降が必要です。これは「居住キー」と呼ばれる機能に依存しています。認証器にデータを保存するため、制限がある場合があります。例えば、Yubikey 5C は最大 25 個までしか保存できません。
登録フロー
これらのフローは、パスワードなしログイン用のフローの進化であり、別個のログインフローではありません。これにより、反復的な実装が可能になります。
パスワードフィールドなし、居住キーの使用に関する追加チェックボックス
ログインフロー
ユーザー名が空白の場合、認証器から
user_id を取得しようとします
参考文献
デモ
https://webauthndemo.appspot.com/
https://webauthn.io/dashboard
リソース
https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285
「いいね！」 22
この RFC をありがとうございます。非常に網羅的で素晴らしい内容です！ただ、通常のユーザー名とパスワードでのログイン時に、WebAuthn を第 2 要素認証（2FA）として使用するフローについて一点考えました。
TOTP を 2FA として設定している場合、ログイン時にはこのモーダルが表示されます：
ユーザーが TOTP コードと WebAuthn 認証子の両方を有効にしている場合、フローはどのようになるでしょうか？このモーダルでユーザーが WebAuthn か 2FA トークンのどちらを使用するかを選択するのでしょうか？それとも、それが負担になりすぎるでしょうか？
もしかすると、Discourse はユーザーが WebAuthn を設定しており、ブラウザが対応している場合はデフォルトで WebAuthn を要求し、それができない場合に 2FA にフォールバックするといった仕組みにしてもよいかもしれません。
既存の実装例
Twitter:
Github:
Google アカウント:
「いいね！」 6
はい、WebAuthnの実装においてそれが標準的な方法になりつつあるように思えますし、ログインフローもとても気に入っています。私たちもここで同様の方向に進むことになると思います。
「いいね！」 7
ジェフ、ありがとうございます。なるほどです。さらに調査した後の今日の追加の考えをいくつか共有します：
ファーストファクター認証
- ユーザーが WebAuthn をファーストファクター認証方法として Discourse アカウントにサインアップした場合、後からパスワードに変更することは可能でしょうか？可能であれば、設定した WebAuthn 認証は、ユーザーが削除したいと望むまで、通常の 2FA 方法として機能し続けるのでしょうか？
- WebAuthn がファーストファクター方法として使用された場合、UI のセカンダリファクター設定に表示されますが、削除できないのでしょうか？
- ユーザーが 2FA を有効にしている場合にソーシャルログインの設定が制限されるのと同様に、ユーザーがソーシャルログインを設定できないと考えるのは妥当でしょうか？
- パスワードリセットメールが送信されるユーザー設定のセクションも、ファーストファクターとしてパスワードを使用しないため、変更されると思います：
「いいね！」 6
sam
(Sam Saffron)
5
テキスト面では、「Web Authn」という用語の使用は好ましくありません。エンドユーザーにとって混乱を招く可能性があるため、「セキュリティキー」などの表現に置き換えるべきだと考えます。
また、ここでは「ファーストファクター/パスワードレス認証」といった概念を考慮すること自体を極力避けたいです。この機能をリリースし、3〜4ヶ月間運用してみてから、その後の検討を行うべきだと考えます。
すでにメールでのログインをサポートしているため、技術的にはパスワードを忘れることも起こり得ます。
同意します。フローとしては、APIとWebAuthnキーが利用可能な場合はまずWebAuthnを試すものの、ユーザーが回避策を選べるようにすべきです。また、複数のWebAuthnデバイスを持つ場合もあるため、Googleがこの問題をどう扱っているかを参考にしてください（「別のオプションを選択」リンクなど）。
長期的な別タスクとして、@pmusaraj さん、Discourseアプリを2FAに活用できるのであれば、それは非常に素晴らしいアイデアだと思います。これにより、2FAの利用がより一般的になるでしょう。
「いいね！」 14
Falco
(Falco)
6
はい、同意します。モックアップに記載されている「webauthn」は単なるプレースホルダーです。
とはいえ、「セキュリティキー」という表現だけでは、ユーザーがラップトップやスマートフォンの指紋認証やカメラを利用できるという事実が伝わらないという問題があります。
そうですね。提示された3つの実装方法は、1が最もシンプルですが、2と3の基盤となるため、この順序で実装される予定です。
「いいね！」 6
Rafe
(Rafe)
8
「WebAuthn を最初の認証因子として使用する」に関する件ですが、この標準のレベル2において、これに伴うプライバシーへの影響について言及するべきだという議論があります：https://github.com/w3c/webauthn/pull/1250/
セキュリティキーの命名に関する件については、RubyGems.org の PR で述べられている理由に賛成です。
また、その中で、セキュリティキーのニックネームに加えて「最終ログイン日時」のタイムスタンプを追加することを提案しました。これにより、キーの識別を明確にし、潜在的な悪意のある活動を検知しやすくするためです。
「いいね！」 8
riking
(Kane York)
9
職場（高セキュリティ環境です）では、セキュリティキーが90日間未使用の場合にメールで通知を受け取るアラート機能も備わっています。これにより、キーを使用するか、アカウントから削除するかの選択を促されます。
これを360日に設定して実装するのは良いアイデアだと思いますが、いかがでしょうか？
「いいね！」 7
Falco
(Falco)
10
素晴らしいアイデアですね。インターバルが短すぎると、無限セッションを利用しているため不便になります。また、多くの人は日常的に使うキーに加えて、引き出しに予備のキーを保管していると思います。複数のデバイスに内蔵されたセキュリティキーは含めません。
「いいね！」 6
この機能に関する PR をマージしたことをお知らせできることを嬉しく思います。したがって、まもなく WebAuthn のテストを始めることができます！
「いいね！」 8
Falco
(Falco)
12
Android の指紋認証、NFC 経由の Yubikey、USB-C 経由の Yubikey を追加しました。Chrome Android と Firefox Desktop で試しましたが、現時点では問題なく動作しています。
重大なバグです @Martin_Brennan @featheredtoast、モバイルビューではログインできません：
デスクトップビューでは正常に動作します：
「いいね！」 10
sam
(Sam Saffron)
13
いくつかのフィードバック 
これは適切に見えません：
ここでは、Composer に従って「キャンセル」ボタンのマージンと色を合わせるべきです。
「パスワードリセットメール」という表現は、ここには少し不自然に感じられます。
代わりにどうでしょうか？
続ける キャンセル
パスワードをお忘れですか？ ← 薄いグレー
パスワード入力欄のフォントが大きすぎます。もう少し小さくすべきです。
ここは「削除」または「消去」とすべきだと思います。
既に追加済みの YubiKey を追加しようとすると、意味不明なエラーが表示されます。
全体的に 
「いいね！」 9
あら、レビューでルートを見落としていたと気づいていました。よく見つけましたね 
ずっとこうだったと思いますが、確かに良い変更ですね。
同意します。良い変更です。
もしかして、Chrome の組み込みコピーを再利用できるかもしれません。「このセキュリティキーは既に登録されています。再度登録する必要はありません。」という明確なコピーが良いですね。
「いいね！」 9
@Falco さん、@sam さん、フィードバックをありがとうございます。モバイルログインには別のルートがあることも知りませんでした！今夜、これらの修正、パスワードのラベルやボタンの変更に取り組む予定です。できれば、修正のための新しい PR を提出できることを願っています！
「いいね！」 7
Android でも動作してくれたのは本当に嬉しいです（モバイル表示は正しく機能していませんが）——私にはテスト用の Android 端末がなかったのです。
「いいね！」 6
Xiaomi Mi 9をおすすめしてもよろしいでしょうか？
「いいね！」 3
Androidに戻れるかどうかまだ確信が持てません──iPhone 8があまりにも大好きなので 
「いいね！」 5
「戻す」って誰が言ったの？それは古い時代の考え方！現代人は複数のデバイスを持ってるんだから 
「いいね！」 8
