おはようございます ritouです。
前の投稿でも取り上げたWebAuthnとかFIDO認証って呼ばれてる認証方式のお話です。
今回は、FIDOアライアンスからUXのガイドラインが出ているので紹介します。
一言で言うと
MacとかiOSとかAndroidとかWindowsの生体認証が使えるデバイス上でWebアプリを使ってるユーザーに対して、新規登録/ログインフローのなかでをどうやってデバイスを登録させてFIDO認証を使わせるか
っていうお話です。
今回のターゲットとしては一般的なユーザーが使いつつ、強固なセキュリティが求められる銀行のWebアプリケーションのようなところを想定しています。FIDOにより一番平和になって欲しい世界のお話です。
これまでtoCのサービスでも、FIDO認証を取り入れる際には「YubiKeyのようなセキュリティキーを用意させるよりも "デバイス自体" を登録してWindows/Mac OS/iOS/Androidそれぞれで提供されている生体認証をする方が使われるようになるだろう」というのは以前から言われていました。
しかし、実際にどのようにデバイスの登録を求めるかと言ったあたりは先行して導入するサービスがそれぞれ探り探りやっているような部分があったので、このUXガイドラインによりその辺りの迷いが解消されることに期待せざるを得ません。
構成
UXガイドラインは3つのコンセプトとして User journey, Process steps, Use Case の3つがあります。
- User journey : エンドユーザーがFIDOのAuthenticatorを登録し、そしてログインするまでの処理が対象です
- Process steps: “sign in(ログイン)” とか “detect device eligibility(デバイスの適合性の検出)” みたいな細かい処理をまとめて “awareness” とか “consideration” と言ういくつかのゴールを表現し、目的を達成するためにこうしたら良い！ってのが整理されています
- Use Case: 銀行のWebアプリを想定してます
- Biometric sign-in or FIDO sign-in: 生体認証もしくはデバイスアンロック手段を用いたFIDO認証を利用することを想定しています
(3つと言いつつ4つ書いてあるじゃないか)
ゴールとProcess Stepsの関係はこんな感じで図示されています。
- Awareness : このサービスはFIDO認証に対応してるよと伝える
- Consideration : ログイン中のユーザーをAuthenticatorの登録に誘導する
- Registration : Authenticator を登録する
- Sign-out (post registration) : Authenticatorを登録してからそれでログインしたりログアウトしたり
と言う感じですが、まずは細けぇことはあまり気にせず画面ごとの要件を拾っていければ十分でしょう。
テストサイト
このUXガイドラインの参照実装として、テストサイトが用意されています。
- メールアドレスや電話番号などは不要
- ユーザー名、パスワードで登録
- 登録したユーザー情報は30日で消滅
となっているので気軽にお試しいただけます。が、どうせみんな見ないでしょう。 IDの技術なんてそんなもんです。「後で読む」「後で見る」IDおじさんは知っています。なので動画をとりました。
これは「iPadでもちゃんと動いた！(けどAuthenticator登録完了時に必ずエラー出るな！)」って言う動画です。
ガイドラインにもこのサイトのスクリーンショットが掲載されています。 この後の説明でも実際に動作させた自分用のスクリーンショットを載せていきます。 では見ていきましょう。
UXガイドラインの内容紹介
Awareness: Sign in Pre-FIDO Registration
目的 : 自サービスでFIDO認証が可能であることを複数の方法で宣伝する
最初に、FIDO認証をサポートするデバイスを利用するユーザーに対して、永続的/一時的なメッセージングによりRelyingParty(FIDO認証を利用するサービス)がFIDOに対する認知度を高めることが説明されています。ユーザー調査によると、登録(Authenticator登録の意味かも?の)前に何度もFIDOの概念について触れる必要がありそうとのこと。
まず、未ログイン状態のログインフォームを見てみましょう。
ここにはFIDOと言う文字は出て来ません。プラットフォーム毎の生体認証っぽい画像を表示することでこのサービスは生体認証に対応してるんだな〜ってのを認識させようと言うのが狙いです。(私の環境はChrome on Mac OSなのでTouchIDっぽい指紋認証のアイコンが表示され、マウスオーバーで説明が出て来ます。Android や Windows 環境の時はそれぞれのプラットフォームの中で使われている生体認証の画像を使うという細かい出しわけが紹介されています。)
この後に出て来ますが、うちのサービスはFIDO認証に対応してるんだ！ではなく、生体認証に対応してるんだよってアピっていくと言うのがポイントですね。
Because the FIDO brand is not yet familiar to most consumers...
謙虚！
他にも
- セキュリティ設定変更機能からいつでもAuthenticatorを登録/削除できるようにする
- eメールのチャンペーンやメール配信、ソーシャルメディアで生体認証が可能であることを通知する
- CSに教育する
みたいな涙ぐましい努力をしながら、FIDO認証を促進していかなければなりません。
Consideration: Targeted invitations
目的 : FIDO認証をサポートするデバイスにログイン中のユーザーを、Authenticatorの登録画面へと案内する
Chrome on Mac OS や Safari on iPad OSなどでテストサイトに登録して再度パスワードを用いてログインし、ログイン状態になったら、画面に案内用のメッセージが表示されます。
ここでの"FIDO認証をサポートするデバイス" ってのはいわゆる Platform Authenticator の利用が可能なブラウザのことであり、WebAuthnの仕様でいうところの "isUserVerifyingPlatformAuthenticatorAvailable()メソッド"を使って判断をしているように見えます。
なので、例えば同じPCでも生体認証が動かないブラウザの場合はこれは表示されません。
あと、ガイドラインにはもう一つ "Spotlight" page takeover invitation format for Mac users ってのが載ってます。 どっかの広告のように全面に主張してくる感じなんだと思いますが、どこで出るんやこれは...
その他、
- パスワード認証に代わる安全な認証方式だという価値を示す
- 案内のメッセージは "シンプル(シンプルな認証方式を利用できるよ)" もしくは "オプショナル(安全な認証方式を追加できるよ)" が効果的
- 対象デバイスの場合は何回も案内しよう！けど設定は必須にせず、ユーザーの制御可能にしておく(ウザがられたらダメ。要はバランス...)
- Authenticator登録ページにたくさんリンクさせる
などが記載されています。
Registration
目的 : 対応デバイスを利用しているユーザーにFIDOについての教育を行い、Authenticatorを登録させる
先ほどのトースト通知から "Register now" に進んでいくと、Authenticator 登録のための説明画面に遷移します。
- この設定は必須ではないので右上の "×" から取り消すこともできる。ユーザーが制御可能なように
- アニメーション画像で生体認証の流れを説明
- 既にコンピュータのアンロックに使っている方法でアカウントにログインできることを説明
- "Learn more" を押すとFIDOの説明が展開
- FIDO CERTIFIEDなロゴ表示
ここぞとばかりにFIDOの説明してますが、これぐらいしないとユーザーは何だか分からなくて使わないってことなんでしょう。 ちなみにFIDOのロゴ利用についてはこの辺りを確認しましょう。
Organizations that wish to use the FIDO logo on websites must adhere to the terms of our FIDO Trademark and Service Mark Usage Agreement for Websites license. You can download our logo files here.
Authenticate
目的 : Windows HelloやApple Touch IDでログインできるようにAuthenticatorを登録する
いわゆるAuthenticatorの登録処理です。 WebAuthnの仕様でいうところの "navigator.credentials.create()" を呼び出すところですね。
先ほどの画面から "REGISTER" を選ぶと処理が始まります。
成功すると画像も成功っぽくなってます。
失敗の場合もそれっぽく変わります。Platformごとの生体認証の画像に続いてこの辺りは芸が細かいなーと思ってしまいますが、現代のUXとしてはそれぐらいやらんといけないってことなのでしょうね。
ちなみにテストサイトでは Authenticator登録直後に100%の確率でIBMのなんたらエラー画面が出てウワッてなりますが、一旦心を落ち着けてトップのURLにアクセスしなおせば何事もなかったかのように続けられます。。
FIDO Sign-in
目的 : 登録済みのデバイス上でユーザーをFIDO認証する
最後に登録済みのAuthenticatorを用いてログインさせる部分です。 WebAuthnの仕様でいうところの "navigator.credentials.get()" を呼び出すところですね。
テストサイトでは、ログアウトした後に
- ユーザー名
- "SIGN IN" ここからWebAuthnのログインが始まる
- FIDO CERTIFIEDロゴ
- ユーザー変更リンク : 空のパスワード認証フォームへ
- パスワード認証への切り替え : ユーザー名が保管されたパスワード認証フォームへ
といった構成の画面になります。
これなら一回でログイン処理が走りますが、ここで注目なのは"ログアウト" してもユーザー名が保存されているということでしょう。
我々はつい "ログアウト" というと完全にセッションデータを吹き飛ばし、フォームに何もない状態からのやり直しを想像してしまいますが、そこからこの処理を行う場合は一度ユーザーを特定する必要があります。
この辺りは
- 最後にログインしていたユーザーのユーザー名を記憶しておく
- そのユーザーがFIDO認証を利用可能な状況(環境+デバイス)ならばログイン画面からすぐに開始できるようにしておく
というあたりを意識していく必要があるのかなと思います。 昔から "最後にログインした方法" "最後にログインしたユーザー" を記憶しておくみたいなアイディアはあるので、この辺りはもう少し整理しようと思います。
ちなみに後から気づきましたが、このテストサイトは Console Log に処理途中のデータもいくつか流しているのでWebAuthnの具体的な実装を見たいときにも参考にできそうです。
(ログアウト状態でも最後に利用したユーザー名が保存されているあたり)
(WebAuthnのログインが行われる時もログが吐かれるあたり)
それ以外にも、Authenticatorの管理もできるようになっているので、この辺も参考にできそう。
と言ったあたりで一連の流れに沿ってガイドラインの内容を紹介しました。
感想
今回のガイドラインには
アカウント登録 -> Authenticator登録 -> ログアウト -> FIDO認証でログイン
の流れに沿ってどのようなUXにしたら良いかというのが書かれています。 また、FIDOアライアンスからはいわゆる "アカウントリカバリー" のために複数のAuthenticatorを登録させるためのホワイトペーパーも出されていたりするので、今回のと組み合わせて参考にしながら実装してユーザーに提供する必要がありそうです。
すでにいくつかのサービスでFIDO認証は使われ始めていますが、開発者向けのサービスより一般的なユーザーに向けての啓蒙となるとより詳しい説明が必要になるでしょう。
ちなみに、個人的にこの前ちょっとハマったのが
- SMS番号やメアドを入力
- ユーザーの登録状態によって分岐
- Authenticator登録済みユーザーならWebAuthnの認証フロー開始
- Authenticator未登録ユーザーならSMS認証
みたいな処理をレガシーなフォーム送信を使って実装しようとしたら、iOS/iPad OSのSafariでうまく動かないと言う挙動にハマり苦戦しました。 理由はちょいと細かい話で、Safariはユーザーの明示的なアクションが起こらないとWebAuthnの処理が行われないようになっており、"ユーザーのクリック"をトリガーにする場合は問題ないものの、"ユーザーのSubmitボタンによるレガシーなWebアプリのフォーム送信"ではWebAuthnのフローが開始できないみたいな癖があります。Chromeでは問題なし)
今後作るときは、今回のUXガイドラインを参考にしたいと思います。
ではまた。
