おはようございます。ritou です。
builderscon tokyo 2018 にて WebAuthn のさわりの話をした時に、「OAuth / OpenID Connect」 との関係について質問がありました。 この質問に限った話ではありませんが、"認証のための技術" なんていうと、認証方式、認証状態のセッション管理、ID連携まで広範囲に渡るため、話が混乱してしまうものです。 ここでは OIDC で言うところの誰が WebAuthn で言う所の誰になるとどうなるのか、みたいな話を書きます。
前提
FIDO と Identity な標準化技術は "補完関係"
結構前ですが、もっと詳しい方が書いたものを紹介します。 https://www.jstage.jst.go.jp/article/itej/70/5/70_481/_pdf
上記FIDOの技術仕様は、認証の領域にのみ注力しています. 近年, 認証や認可などの技術を含むアイデンティティ(Identity, 本人性)管理と呼ばれる技術領域において標準化が進められてきました. それらの標準的技術(例えば, SAMLやOpenID Connectのようなアイデンティティ連携技術仕様)と協調的で互いに補完関係になるように配慮しています.
"補完関係" です。 いつだったかの idcon のタイトルもこんな感じでしたね。 使っていきましょう。
OIDC
OpenID Connect は、(OAuth 2.0のAPIアクセスの仕組みの上で)異なるサービス間であるユーザーの認証情報を渡す仕組みです。
OpenID Connectの登場人物で言うと
- OpenID Provider (OP) : あるユーザーの認証情報をRPに提供
- Relying Party (RP) : あるユーザーの認証情報をOPから取得
があるので、これらを OIDC OP, OIDC RPと呼びます。 ソーシャルログインの普及により、数でいうと OIDC OP < OIDC RP というようになります。 懐かしのSNSのように、OIDC OP かつ OIDC RP なやつとかいますが、一旦置いておきます。
WebAuthn
登場人物として
- Authenticator : 生体認証などを提供
- Relying Party : 生体認証などを利用
がいます。
Authenticator が OIDC... ってなるとちょっとイメージが難しくなりそうなので、今回は Relying Party を WebAuthn RP と呼び、これがOIDC OP/RPのどちらになったらどうなるかって話をします。
組み合わせ方
OIDC OP == WebAuthn RP
OpenID Connect の OPである Google や Yahoo! JAPAN とかが WebAuthn の RP になって生体認証とかでログインできるようになるケースです。 一般的に、ユーザー規模が比較的大きく、2段階認証的なのを早い段階から実装していることが多い印象がある OpenID OP なので、実現しそうな予感がプンプンします。 メリットを考えてみましょう。
- OIDC OP のサービス単体として割と多くのユーザーが WebAuthn の恩恵を受けられ、パスワード認証からの移行を進めることで安全性を高められる
- OpenID OP を利用している OpenID RP も、OIDC OP で WebAuthn を利用するユーザーについて追加実装なしで安全性を高められる
- ユーザーに紐づく Authenticator の管理等を比較的数の少ない OpenID OP 内で完結できるので、ユーザーの負担は抑えられる
全体で見た時のデメリットと言うか迷うところでいうと、"OpenID OP が WebAuthn で認証したユーザーだと言うことを OpenID RP に教えてもらえないと辛い"というのはありそうです。
これはソーシャルログインを流行らせようとしてた頃からずっと言ってますが、OpenID OPから WebAuthn 使ってる人とパスワード使ってる人が一緒に OIDC RP に流れてくる可能性があるわけです。
OIDC RP がユーザーの認証レベルを意識して必要ならば追加の認証をさせようなどと思った時に、ハンドリングするための情報が欲しくなるでしょう。
例えば Google の OIDC ID Token を見てみましょう。 OpenID Connect | Google Identity Platform | Google Developers
ID Token の claims のところを見てみると...
おきまりの "iss" とかに加えて、"email" や "profile" とかがあって...
認証方式とか、そう言うのはなさそうです。 これだと、OIDC RP 側でこのユーザーはどんな認証をしてきたんや、どんな人生を歩んできたんやと言うのがわかりません。 OIDC RP側がきっちりポリシー決めて、追加認証とか入れようと思っても辛いです。
では、念のため Yahoo! JAPAN の ID 連携の方も見てみましょう。 Yahoo! ID連携:ID Token - Yahoo!デベロッパーネットワーク
Payloadのところです。
「本当に世の中の文字は小さすぎて読めなーい！でしょう？」
"amr" claim があれば、ユーザーの認証方式がわかります。これは便利。 いずれはここに FIDO 2.0 / WebAuthn 関連で追加されることでしょう。 さらに、認証した日時までもらえます。
これがあれば、OpenID RPも認証強度が適切かどうかを自分たちのポリシーに照らし合わせて判断し、場合によっては追加認証を求めたりもできそうです。
素晴らしいですね。
あとはYahoo! JAPAN が FIDO 2.0 / WebAuthn に対応すれば良いわけです。と言うところで
ヤフー株式会社（以下、ヤフー）は、生体認証などの次世代認証の標準化を提唱する業界団体FIDO（ファイド）アライアンスの新たな規格「FIDO2」の認定を、2018年8月に世界で初めて開催された「FIDO2」認定テストにおいて、このたび取得したことをお知らせします。国内企業では唯一の認定取得となります。 ...
ヤフーは、近日中にFIDO認証に対応し、ますますパスワードレスで安全なログインの普及に努めてまいります。
Yahoo! JAPAN FIDO 2.0 Ready 状態っぽいので、上記の組み合わせが実現する日も近そうです。(褒めまくったので何かくれ)
OIDC RP == WebAuthn RP
続いて、OpenID Connect の RP が WebAuthn RP になるパターンです。 現在、世の中の OpenID Connect の RP は OP のアカウントと連携しつつも、独自にパスワードを設定させる事例が多くありますが、これではパスワードレスな世の中は実現できません。 また、OIDC OPに障害が発生している時など、OIDC RP 側で身動きが取れなくなる可能性もあります。 そのような場合に、やはり独自で認証方式を持たなければならない、となった時に、WebAuthn も候補に上がるでしょう。
メリットとしては"OIDC OP が WebAuthn に対応していなくても、全てのユーザーに WebAuthn の利用を強制できる"と言うあたりでしょうか。 逆にいうと、作りによってはOIDC OP/RP 双方で WebAuthn の認証を求められて辛い、ということにもなりそうです。 なので、やはり OIDC OP 側の方がしっかりしないといけない雰囲気ですね。
あとは、数の観点からユーザーがいろんなサービスに Authenticator を登録する必要がでてくる可能性があるところでしょう。 パスワード認証よりも認証方式そのものがセキュアであるとはいえ、今までのクレデンシャル管理の歴史を思い返すとなかなか辛いですね。
これは差別かもしれませんが、OIDC OP/RP が WebAuthn を追加するのにどっちが安全な実装ができるだろうかと考えたときに、やはり OIDC RP 側は結構頑張らないといけなそうな雰囲気がします。 信頼できるライブラリを使う、Auth0 のように認証機能を代行してくれる外部サービスを使うのも良いでしょう。
あとは、これからだんだん見えてくるであろう、WebAuthn の登録/認証フローにおけるベストプラクティスを実装していくことが重要になるでしょう。
どちらの組み合わせでも必要なベストプラクティス
OIDC OP/RP いずれが WebAuthn を実装することになっても、やることは一緒です。
- 新規/既存ユーザーと Authenticator の Public Key の紐付け
- 認証
- Authenticator の管理(追加、削除)
この辺を詰めていく必要があります。 もっと言うならば、あるユーザーに対して Authenticator が追加/変更/削除 されたことをサービス間で伝搬させるような仕組みが重要になるかもしれません。 セキュリティイベントの通知みたいな感じですかね。これは別途考えたいところです。
まとめ
- OIDC の OP/RP のそれぞれが WebAuthn の RP となる未来を想像した
- どっちもアリ
- ベストプラクティスは詰めていかねばならん
といったところでしょうか。 そういえば、来週は WebAuthn 関連のイベントがありますね。
私も参加予定です。 ではまた！
