Web Authentication APIはsecurity keyを用意する前にaccountの復旧と利用範囲を決める

Web Authentication APIを使うときは、security keyや指紋を読める機器を選ぶ前に、どのaccountへ使うのか、端末を失った利用者をどう戻すのか、serverが何を確認するのかを決めます。認証器を一つ登録できても、利用者と公開鍵の対応、ログインを許可する条件、失効させる手順がなければ、運用は続きません。新しい認証方法は、passwordを入力する画面だけを置き換える仕事ではありません。

Web Authentication APIは、web applicationがbrowserを通じて認証器を使い、siteごとの公開鍵の認証情報を作成し、利用するためのAPIです。Credential Management APIへPublicKeyCredentialを加え、認証器が作った公開鍵と利用者の関係をserverが保存します。認証時はserverがchallengeを出し、browserと認証器を通じて得た署名をserverが確認します。 Chrome Developersの解説

認証器を使うこととaccountを管理することは別である

Web Authentication APIで使う認証器には、USBで接続するhardware tokenや、端末に組み込まれた認証機能があります。利用者が認証器で操作したことは、accountの権限、登録メール、契約上の担当、退職した利用者の停止までを自動で決めるものではありません。siteの管理画面へ入れる人を増やすなら、どのaccountにどの権限を渡すかを先に決めます。

たとえば、管理画面を扱う担当者へ二段階の確認を加えたい場合を考えます。最初に必要なのは、誰が管理者accountを持つか、誰が公開作業だけを行うか、誰が利用者を停止できるかを分けることです。そのうえで、どのaccountに認証器を登録するかを決めます。全員が同じ管理者accountと一本のsecurity keyを共有すると、操作した人を分けにくく、紛失時に誰の利用を止めるべきかも曖昧になります。

認証器は、利用者が自分のaccountを確認するために使います。accountそのものは、siteのserverと管理する側が扱います。この二つを混ぜると、keyを渡しただけで担当の交代が済んだと考えたり、退職した人のaccountを残したままkeyだけを回収したりします。利用者、account、認証器、権限、停止の判断を別に記録してください。

登録では公開鍵と利用者の対応をserverへ残す

Web Authentication APIでは、siteがchallengeを作り、browserへ新しい認証情報の作成を求めます。認証器は利用者の確認を受けた後、鍵の組を作り、公開鍵などをweb applicationへ返します。web applicationは公開鍵をserverへ渡し、serverは利用者の識別子と対応させて保存します。秘密鍵をsiteが受け取って保管する仕組みではありません。

この流れから分かるのは、登録画面を表示するだけでは足りないということです。server側には、どの利用者がどの公開鍵を登録したかを保存し、あとで停止または追加するための管理場所が要ります。登録を受けた日時、対象account、登録した認証器を区別できる情報、登録を承認した人を、必要な範囲で残します。認証に使う情報と、利用者を案内する連絡先を同じ欄へ無造作に集めません。

説明用の仮例として、会員だけが資料を読むsiteを考えます。利用者Aが認証器を登録したら、serverは利用者Aのaccountと公開鍵の認証情報を対応させます。利用者Bが同じ端末を使う場合でも、利用者Aのaccountへ入れる理由にはなりません。新しいaccountを作る処理、認証器を登録する処理、資料を読む権限を渡す処理は、画面が近くても別の処理です。

認証時はchallengeの作成とserverの照合を分ける

認証時にも、browserだけで完結するわけではありません。siteのserverはchallengeを作り、対象利用者に登録された認証情報をbrowserへ渡します。browserは認証器へ署名を求め、認証器が利用者の確認を受けて署名を返します。web applicationはその結果をserverへ渡し、serverが検証して初めて認証の成否を決めます。

この順序では、challengeを毎回作ることと、以前の認証結果を再利用しないことが重要になります。画面に「認証に成功しました」と出す処理と、serverが署名を検証してsessionを開始する処理を一つの結果として扱わないでください。通信が途中で失敗した場合や、serverが利用者を停止している場合に、どこでログインを止めるかを分けておく必要があります。

開発を頼む場合は、「security keyでloginできるようにする」だけでは不足します。対象domain、使うaccountの種類、登録時に保存する情報、challengeを作るserverの処理、検証に失敗したときの画面、管理者が認証情報を止める場所、記録を確認する人を渡します。認証器との通信を作る仕事と、siteの利用者を管理する仕事は、同じ担当が行っても設計上は分けます。

紛失した認証器を前提に復旧手順を作る

security keyや端末を失った利用者は、いつか出ます。そのとき、認証器を持っていない人を誰が本人だと確認し、どの条件で新しい認証器を登録させるかを決めていなければ、便利な認証方法が利用停止の原因になります。逆に、連絡を受ければ誰でも新しい認証器を登録できるなら、認証を追加した意味が薄くなります。

復旧の方法は、accountの重要度で分けます。一般の会員accountと、全利用者を削除できる管理者accountは、同じ手順にしません。管理者accountなら、別の管理者による確認、記録済みの連絡先、作業を止める間の連絡先などを先に決めます。会員accountなら、利用者本人へ連絡を返す窓口、復旧時に無効にする認証情報、新しい登録を許可する条件を決めます。どの方法でも、復旧を決める人と実際に登録を行う人を分けて記録します。

予備の認証器を登録する場合も、単に本数を増やす話ではありません。どのaccountに何本あるか、誰が保管するか、使わなくなった認証器をいつ止めるかを把握します。制作会社や社内の担当者が交代したときに、前の人の認証情報が残っていないかを確認する項目へ入れます。認証器の購入と、利用者の変更を管理する責任は別です。

最初は一つの利用範囲で試す

Chrome 67 Betaでは、desktopでUSB transportを使うU2FまたはCTAP 1の認証器によるWeb Authentication APIが案内されています。より多くのtransportや後のprotocolを前提に、全利用者のlogin方法を一度に替えません。実装するなら、最初は対象account、使うbrowser、認証器、登録、認証、紛失時の連絡先を小さく決めます。

試験用のaccountでは、少なくとも次の状態を別に確認します。新しい認証器を登録できるか。登録済みの認証器でchallengeへ応答できるか。serverが照合に失敗したときにloginを許可しないか。認証器を失った利用者を、決めた担当者が復旧できるか。使わなくなった認証情報を停止したあと、その認証器では入れないか。確認結果は「動いた」とだけ残さず、対象account、browser、認証器、日時、担当、失敗した場合の画面を結び付けます。

試験で使った設定を本番へ移すときも、利用者のaccountと登録した公開鍵を混ぜません。試験用の利用者を消すのか残すのか、testの認証器を本番で使うのか、serverの保存先が分かれているかを確認します。試験の成功と、本番で全利用者へ案内できる状態は別です。

Web Authentication APIだけで復旧や権限は決まらない

Web Authentication APIは、認証器を通じて公開鍵の認証を行うためのAPIです。site内の担当交代、利用者の招待、権限の変更、退会、紛失時の本人確認、問い合わせ対応の決定までは行いません。技術を入れる前に、accountの一覧、認証情報の一覧、復旧の決定者、停止作業の記録を作る方が先です。

最初の一手は、認証を加えたいaccountを一種類だけ選びます。そのaccountができる操作、登録する認証器、serverへ残す対応、紛失時の連絡先、停止する人を書きます。この五つが決まってから、試験用accountで登録と認証を確かめます。認証器を導入することと、siteを引き継げる状態にすることを別に扱えば、担当が替わっても判断をたどれます。