1月28日に、「パスキーのすべて」という本を共著で出版させてもらうことになりました。

出版社の技術評論社のページに、本書の「はじめに」を掲載頂いています。1分で読み終わるので是非ご覧ください。
（この記事の投稿が遅れた分は、このまえがきで勘弁してください！）
また、数ページほど、本文からの抜粋もご覧頂けます。どういった内容が書いてあるのか、イメージをつかんで頂いて、購入をご検討ください。

諸先輩方のように、毎日ブログを書くことは私にはとても難しいので、3人で共著なのを理由にして、28日の発売まで、3日に1本ぐらいの感覚で、どこかのブログで記事を書き続けるチャレンジをしてみたいと思います。1ヶ月ぐらいならきっと続くことを祈ります。これは3本目。

このブログの内容は個人の見解です。優しいツッコミ歓迎します。
（正直思ったより書きづらかった・・・）

さて、前編では、パスキーのほかに複数の認証手段を組み合わせる場合、フィッシング耐性などのリスクに差があるので、セッションごとにログイン時の認証手段を覚えておき、それぞれどういった権限を許可するかについても考慮する必要がある（かもしれない）と述べました。

認証手段をセッションに紐付ける

ログイン時の認証手段をセッションに保存しておくには、特に決まった方法はないですが、もしかしたら、OpenID Connectを参考にできるかもしれません。
ただし、後で述べますが、必ずしも保存すべき認証手段は1つではないし、認証するタイミングも1回とは限らない点に留意です。

OpenID Connectの場合

ユーザの認証結果を(外部IdPに依拠する、しないに関わらず）OpenID Connectで連携する場合、IDトークンやUserInfoの中で、 amr (Authentication Method Rerefence) や acr (Authentication Context Reference) として、認証方法を受領することができます。（もちろん、IdPが対応している場合に限ります。）

詳細は、昨年のOpenID Summitでritouさんが講演されているのでご覧ください。

つまり、もし、IdPが、OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 に対応しており、パスキーによる認証がフィッシング耐性のある認証として、　phr という値を acrに入れて返してくれるかも知れません。

もしくは、RFC8176 Authentication Method Reference Valuesに対応したIdPは、パスキーによる認証がされた場合には amr で swk(software-secured key) を設定して返却するかも知れません。（RFC8176で定義された他の値としては、sms, otp, face, fpt(fingerprint) などがあります。)

認証手段ごとに何を調整する必要があるか

さて、現在のセッションにおいてユーザがどうやって認証したかが分かるようになったとして、それによって何を調整すればいいのでしょうか。
もちろん、それは各サービス次第です。

セッションの有効期間

セッションが継続している間は、ユーザが利用しているブラウザが信頼できるものであり、かつCookieの値が他人に漏洩する可能性が低いということが、暗黙の前提になっていると思います。
ですが、例えば、ユーザが共有端末でログインしたまま席を離れてしまったり、何らかの不正を受けてCookieの値が盗まれてしまった場合に、永遠にセッションが残るとユーザ本人以外がアカウントにアクセスしてしまうリスクが高まるので、各サービスごとに、セッションの有効期限を定めていることかと思います。
（例えば NIST SP800-63-3Bでは、リスクに応じて15分から30日の間で再認証が必要となる期間が定められています。）

認証方法が異なり、それによってリスクも異なるのであれば、セッションの有効期間も、それに応じて調節するという考え方もできます。
ここで、必ずしも強度が弱い認証手段であればセッションも短くするべきとは限らない点には注意です。例えば、リスクの高い取引は、認証強度を強くし、セッションの有効期限も短くすることが望まれます。逆に、リスクの低い取引であれば、認証強度も弱くて良いし、セッションの有効期間も長くて良いという考え方もあります。（現に、テレビでログインした場合に再ログインを求められることはめったに無いと思います。）

さらには、たとえ高いレベルでログインしたとしても、一定期間が経過したら、低いレベルと同等であるとすべきという考え方もあります。

権限

先ほど述べた通り、リスクの高い取引は、認証強度の高いもので認証した場合のみ許可するということができます。

ここで、パスキーを必ず設定しないと利用できない機能を作ると、パスキーを使えない環境にあるユーザがその機能を使えなくなってしまうので、各サービスのサービス性や、セキュリティポリシー、受容可能なリスクを踏まえ、バランスをとった判断をすることになります。

当人認証保証レベル (Authenticator Assuance Level: AAL)

ところで、数多くある認証手段ごとに、リスクを判断して、セッションの長さや権限をそれぞれ判定するのは、なかなか大変です。また、パスキーのように新たな認証手段が出てきた際には、再度考え直す必要が出てきます。
そのため、既存の認証手段を、いくつかのレベルに分けて、レベルごとにセッションの長さや権限を設定すると、新たな認証方式でも、どのレベルに該当するかを判断すればいいので、追加が簡単ですし、世の中の状況の変化に応じて、取引ごとに要求するレベルを調整しやすくなります。

つまり、レベル1の操作をするにはレベル1の認証、レベル2の操作をするにはレベル2の認証を必須とすると言ったポリシーを使って、取引ごとの要求レベルと、認証手段ごとに充足するレベルをそれぞれ定義し、紐付けるようにします。

何個のレベルに分割するかも、またサービス性とセキュリティのバランスになります。多すぎても煩雑で、それぞれのレベルの差が分かりづらくなるし、少なすぎても認証手段に差が付けられないとなります。（NIST SP800-63を例に取ると、フィッシングの危険があるOTP等を組み合わせた2要素認証とパスキーが同じレベル2として定義されているので、差がつかないのは困りものです。）
世の中を見てみると、現状、3つか4つぐらいにレベル分けするのが一般的のように見えます。

国内の例としては、NTTドコモが、3つのレベルの当人認証保証レベルを設定しています。

再認証

もし、ユーザがセキュリティレベルの低いログインを行った場合、もしくは、高いレベルのログインを行ったが、特定の取引を行うには時間が経ちすぎている場合には、同一セッションの中で、再度ユーザを認証する必要が出てきます。

つまり、同一セッションの中で、複数の認証が行われる可能性があるので、セッションに紐付ける認証手段・認証日時も、複数ある事を想定しなければ行けません。
（念のためですが、再認証をした場合にはセッションIDも振り直した方が良いでしょう）

まとめ

前編で述べた通り、フィッシング耐性のあるパスキーを導入したとしても、まだパスキーを利用できないユーザがいる限り、パスキー以外の認証手段を残さざるを得ません。そうなると、せっかくパスキーを使っていても、フィッシングから十分にユーザを守り切れない可能性があります。

そんな中でも、できる限りユーザを守るには、ユーザの認証手段ごとに、ユーザがどういった操作をできるのか、どのくらいの期間セッションを継続できるのかといった点を整理し、リスクの高い操作を、極力セキュリティレベルの低い認証手段で行えないように制限するといった方法が考えられます。

そして、取引ごとの要求セキュリティレベルと、認証手段ごとの充足セキュリティレベルをそれぞれ数段階で分類・整理することで、この制御をやりやすくすることが可能です。

レベル分けの際には、各サービスのサービス性や、セキュリティポリシー、受容可能なリスクを踏まえ、ユーザの利便性とバランスをとった判断が必要です。世の中の状況の変化によって、パスキーの受容度によっても、ユーザのリテラシによっても、バランスは変化しますので、つねに調整し続けることが求められます。

このブログの内容は個人の見解です。優しいツッコミ歓迎します。
（正直思ったより書きづらかった・・・）