Open ID Connectのnonceパラメータの意義についても整理してみる
前回OAuth2.0でのstateパラメータの役割について簡単にまとめましたが、OAuth2.0ではなくOpen ID Connectではstateパラメータに加えてnonceも利用されます。この二つのパラメータの違いが最初は理解しづらい部分もあったので、今回はこちらのnonceパラメータの役割についてもかいつまんで記載したいと思います。
Open ID Connectの流れ
OAuth2.0は「認可」を目的としたフレームワークということで、ユースケースで理解するのに苦労したのですが、Open ID Connectは認証に主眼が置かれている仕組みということもあり、もう少しオンライン寄りな例も可能かなと思います。
例えば昨今ニーズの増えているオンラインライブにLINEアカウント（外部IdP）のIDでログインしたいようなケースを考えてみます。
- 参加者はオンラインライブのサイトへアクセスします。
- 参加者がまだ認証されていないので、認証サーバ＝LINEの認証エンドポイントへリダイレクトされます。
- 参加者はLINEの認証画面で認証を実施します。
- LINEは参加者にコードを返却します。
- 返却されたコードとともにオンラインライブのサイトへリダイレクトされます。
- オンラインライブのサイトはコードをLINEへ送信します。
- LINEはそのコードを元にIDトークンをオンラインライブのサイトへ返却します。
ここまで終了すると、オンラインライブのサイトに対して参加者が誰か、という情報が伝わり、参加者マイページ等の表示が可能となります。
セキュリティリスク：IDトークンの横取り
しかし、こちらの図を見ていると、もし⑦のIDトークンを返却する際にこのトークンを通信を傍受されるなどをして横取りされた場合、正規の参加者のふりをして悪意あるユーザがログインできてしまうのではないか？という懸念があります。
ここで登場するのがnonceパラメータとなります。nonceパラメータは、②の認証サーバへリダイレクトされる際に発行され、最後⑦のIDトークンの中にもnonceパラメータの値が含まれています。
悪意あるユーザの横取りを防ぐ仕組みは下記のイメージです。
- 参加者Aさんが認証サーバへリダイレクトされる際、オンラインライブのサイトはAさんのセッションに紐づくnonceを発行します（①～②）。
- Aさんは外部IdPで認証を実施し、IDトークンが発行されます（③～⑦）。
- ここでIDトークンを悪意あるユーザが横取りします。が、同時にオンラインライブのサイトは認証完了時点でAさんセッションに紐づくnonceを破棄します。
- 悪意あるユーザがIDトークンをオンラインライブのサイトへ送信しますが、IDトークンに含まれるnonceはすでに破棄されているので一致が確認できず、認証が失敗します。
このようにnonceパラメータを正しく発行・検証することで安全に外部IdPを用いた認証が実現できます。
stateとの違い
前回書いたstateと今回のnonceはセキュリティに関するパラメータだとは理解しつつ、違いを理解するのが難しかったりしますが（nonceはOIDCで出てくる、くらいの認識だったり、CSRF攻撃を防ぐという目的は一緒だったり）
それぞれ役割だったり検証方法が違うものであるということがCSRF攻撃を防ぐという観点だけでもわかるかなと思います。
| 項目 | state | nonce |
|---|---|---|
| 防ぎたいこと | ユーザが攻撃者として認識されること（攻撃者のコードを使わされること） | 攻撃者がユーザとして認識されること（IDトークンを横取りされること） |
| 攻撃ポイント | アクセストークン発行前 | IDトークン発行後 |
| 方法 | クライアントが保存しているデータとパラメータの一致を検証 | クライアントが保存しているデータとIDトークン内のパラメータの一致を検証 |
OAuth2.0、Open ID Connectのセキュリティという面ではさらに実装ポイントもありますが、よく使う機会のあるstate、nonceに関して簡単にですがまとめてみました。
