どーもどーも、 ritou です。
この記事は 【ゆるゆるとパスワードレスなUXを検討】(1) WebAuthn Authenticator の登録 - r-weblife の続きです。
こいつ、既存アカウントへのAuthenticator の登録、ログイン、新規アカウント登録、決済みたいな重要な処理の前にどう扱うかまで書いたら、自分用の外部設計みたいな感じで使えるものができるはず、と密かに考えている https://t.co/L73L4kH0mz
— 秋田の猫 (@ritou) 2018年10月11日
ということで、しばらく続ける予定です。
WebAuthn そのもののログイン方法については詳しい方々の資料やデモなどがあるので、把握されている方も多いでしょう。
今回はレガシーなサービスのパスワード認証など、複数のログイン方法がある場合なども考慮しつつ、ユーザーが WebAuthn を用いたログインにどう出会うかみたいなとこを考えます。
前提
登場人物を振り返っておきます。
- あるサービス = WebAuthn の RP
- ユーザー = あるサービスに登録済みのユーザー
- パスワードを設定しているかもしれない
- 既に確認済のメアド / SMS番号を持っているかもしれない
- 1つ以上の User Verification 可能な Authenticator と紐づけられている(←new!!!)
- Authenticator : 生体とかPIN(UserVerification)で単体でユーザー認証が達成できるやつ
- 注意 : 今回の記事のスクリーンショットでは都合により YubiKey(User Present) を用いたものを載せています。ご了承ください。
既に Authenticator との紐付けは済んでおり、その後のログインで WebAuthn を使って行くあたりを考えていきます。
WebAuthn を絡めたログインフロー
WebAuthn のみのログインフロー
シンプルなUXでいうと、最初は
- WebAuthn でしかログインする方法がない
みたいなケースから見ていきましょう。
一番シンプルなのは、"Login" ボタンとかリンクを押すといわゆる navigator.credentials.get()
が呼ばれて WebAuthn のログインが始まるパターンかと思います。
Yubico の WebAuthn デモサイトで言うところの "Login without username" ですね。
これを使うには、Authenticator の登録で navigator.credentials.create()
を利用する時、requireResidentKey
を true
にセットする必要があります。(前の記事に追加しなければ...done)
2018/10/14 時点で、Chrome のバージョン: 最新版のGhrome Canary だと 71.0.3578.5(Official Build)canary (64 ビット)
を使うと動作確認もできます。
NotSupportedError: Resident credentials or empty 'allowCredentials' lists are not supported at this time.
というエラーが返されます。Official Build だとエラーにはなりません。
ユーザー名を入力しなくてもちゃっちゃと進みます。
現在の Chrome では単一のユーザーの情報が保存されている場合のみこれが使えると聞いた記憶がありますが、複数のアカウントからの選択、いわゆる Account Chooser みたいなUIをサポートしていれば、Authenticator に登録されているユーザーから選択する処理がブラウザ上で行われることになりそうです。 (Windowsでのアカウント選択画面については IdM実験室: Windows 10 October 2018 UpdateのEdgeでWebAuthnを試す で説明されてますね)
Windows Edge + Google 製のデモサイト + コンソールでちょちょちょっと作業すると、Account Chooser 的な UI が見えます。
- メリット : RP実装、ユーザーアクションが少ない
- デメリット : 他のUXに比べてエラーハンドリングは多少増えるかもしれない
こんなエラーの場合は新規登録に流すみたいなのも整理しないといけないんですが一通り揃ってから考えましょう。
ユーザーの設定を見て WebAuthn のログインフローに誘導
次は一度ユーザーの識別(特定?)を行ってから WebAuthn のログインが始まるという UX です。
- WebAuthn 以外にもログイン可能だけど、Authenticator と紐づいてるユーザーが優先度をあげている、もしくはデフォルトで WebAuthn でログインする
- WebAuthn のログインにて Resident Key を使わない
というあたりでしょうか。
現状で近い UX としては、Google へのログインでしょうかね。この前気づきましたがヤフーも同じ感じです。
ログインの際はまず、最初にメールアドレスを入力します。
サービス側はメールアドレスなどの識別子に紐づくユーザーが WebAuthn の対象であった場合に、WebAuthn のログインフローに誘導します。
この場合、いわゆる ResidentKey の機能に頼らずとも、navigator.credentials.get()
を呼び出すときに allowCredentials
-> id
として CredentialId を指定してやると実現できそうです。
と、実際はこの誘導についても
- そのまま
navigator.credentials.get()
を呼び出してエラーハンドリングしっかりやる - 環境により WebAuthn が利用できない可能性も考え、"WebAuthn でログイン" ボタンみたいなのを表示して WebAuthn 優先のUIにしつつも他の認証方式も利用可能にする
などの細かいやり方はありそうです。
先にユーザー識別を行うこの UX に対してはその識別子が有効かどうかわかってしまうのであれこれ、みたいな話は以前からあります。
WebAuthn を絡めても同じ話は残るので、そのあたりの考慮は必要そうですね。
- メリット : 他の認証方式からの移行時、複数の認証方式をサポートしている場合も利用可能
- デメリット : RPの作り込みがけっこう必要そう
ソーシャルログイン的に認証方式を選択
残ってるのは、最初からユーザーに認証方式を選ばせる UX です。
と言っても、"WebAuthn のみのログインフロー" と他の認証方式が並ぶイメージですね。
最初に実装する人が何も考えないで実装しちゃうと、文言が "Login with WebAuthn" とかになっちゃいそう。
その文字を見たときにユーザーの理解、大丈夫でしょうかね。大丈夫じゃなさそう。
ここまで行くためには FIDO 2.0/WebAuthn が、かなり普及されてないときつそうではあります。
そしてまたボタンが増える... Nascar Problem って知ってますか?懐かしいですね。
その他細かいこと
直接UXには関係ないところで気をつけるべき物をメモっときます。
- ユーザー認証ログを残そう : これは認証方式問わずやるべきですね
- 環境判定(初めての環境ならどうこうみたいな処理)を入れているならその辺りはパスワード認証と同様に続けるべき
- Authenticator紛失なども考慮して、ログインできるかどうかを制御できるようにするべき
まとめ
ログインの UX について考えてみました。
- Resident Key
- 他の認証方式やリカバリーフローへのフォールバック
あたりを考える必要がありそうです。
次回は新規登録やりますかね。
ではまた!