今回は多要素認証の話です。
ソーシャルIDなどの外部IdPと連携をする際、外部IdP側がパスキーに対応している場合もあり、基本的にRP側はIdPの認証結果を信じて何もしないという文字通り「Relying」な感じで構成されることが多いと思います。
しかしながら、本当にそれでいいの？とうケースも存在すると思うので、少し深掘りしてみましょう。
中々難しい話だと思いますが、IdP側（例えばGoogle）で認証を強化するか、RP側（例えばECサイト）で認証を強化するか、もしくは両方か、についてユーザ体験の妥当性を含めて考えていかないといけないところです。
IdPもRPもそれぞれ責任範囲が異なるので基本的に自分の責任範囲を守る目的で多要素認証を要求していますが、ユーザから見るとなぜ別々に、、という形に見えてしまうことも事実です。
この問題を根本的なところは先に書いた通り責任範囲の話を理解する必要があるのですが、ツール（技術面）とルール（契約を含め責任論）を合わせてみていかないといけません。この辺りをトラストフレームワークと言われるもので表現をしていくことになります。
まずは技術的な話
まずは簡単な話として、技術の話をしていきましょう。（本来はルールの話をした上で技術の話をするのが良いのですが、読者層を考えるとまずは目に見えるところから入るのが良いと思っています）
本来はIdPがacrやamrで認証手段（例えばパスキーで認証したよ）という情報を渡してあげればRP側はその結果を見て追加でパスキーを要求するべきかどうかの判断をしていくのが良いと思います。ただRPを作ったことがある方はわかると思いますが、
- IdPによって返すacr/amrが異なる
- IdPによっては返ってこないこともある
などの事情があるので、特に複数のIdPとのID連携を行う場合は中々面倒臭いことになります。
例えば、GoogleのOpenID Connectのサポート状況を見るとドキュメントを見る限りacr/amrに関する記載はありません。
Entra IDは一応amrの値を返しますが"pwd", "mfa"の２種類しか返せないのでパスキーで認証されても、OTPで認証されても"mfa"になると思います。
Oktaの例は56さんが試してくれていますがEntraよりは少しマシな程度っぽいですね。
ということで外部IdPの認証手段までを厳密かつ標準的に取得して利用するのは現時点では結構ハードルが高そうです。
この辺りは学術認証フェデレーションでは議論が進んでいるのですが、ある程度閉じたコミュニティの中だからできる議論でもあるので、パブリックなIdPだと難しいと思います。
そもそも論として、なぜ外部IdPと連携するのか？
また、そもそも論として各IdPをどこまで信じるのか？というか何のために外部IdPを使うのか？というところに遡ってしまいます。
単に、利便性（プロフィール入力の手間の削減、パスワード登録をさせない）を提供することでドロップ率を下げましょう、という場合もありますし、本気で外部IdPの認証結果に依拠しましょう、という場合もあります。
登録時にプロフィール入力を自動化してドロップ率を下げましょう、という話だけなら認証まで外部に依存する必要は本来ないと思います。パスワード登録をRP側でさせることでドロップ率が〜〜〜という話であればパスキーを使うなりなんなりしてパスワードに依存しない認証手段を用意すれば良いと思います。
（認証まで外部IdPに依存することでログインの都度外部IdPにリダイレクトされるとなると外部IdPが落ちていた場合に発生する機会損失などのリスクもありますし）
認証手段をRPが自前で持つことがリスクという考え方をする方もいるのは事実なので、その場合は外部IdPに頼ってしまうこととのリスクとの天秤で考えるしかないと思います。
（外部IdP側でアカウント侵害が起きたらどうするの？とか）
というあたりで外部IdPとの責任問題の話になってきたところで今回は終わりです。
ある程度答えは見えていると思いますが、次回以降で主要なIdPがどこまで責任を取ってくれるつもりなのか？について少しずつ調べてメモしていこうと思います。
0 件のコメント:
コメントを投稿