OAuth 2.0 "state"とOpenID "nonce"パラメーターの違いは？なぜ状態を再利用できなかったのですか？
OAuth 2.0は、クロスサイト要求攻撃を防ぐために、クライアントが要求で送信する「状態」パラメーターを定義します。 「nonce」のOpenID仕様にも同じことが記載されています。 「nonce」がクエリパラメータの代わりにIDトークンで返されるという事実は別として、それらはまったく同じ目的を果たすように見えます。なぜ彼らが分離しているのかを説明できるなら
状態とナンスは似ているようです。しかし、深く掘り下げると、それらが異なる目的に役立つことがわかります。
Stateは、クロスサイトリクエストフォージェリ（CSRF）攻撃からエンドユーザーを保護するためにあります。 OAuth 2.0プロトコルから導入されました RFC6749 。プロトコルには、
エンドユーザーから承認が取得されると、承認サーバーは、エンドユーザーのユーザーエージェントを、 "state"パラメーター。バインディング値により、クライアントはバインディング値をユーザーエージェントの認証済み状態と照合することにより、リクエストの有効性を検証できます
そして、これは認可リクエストで使用されます。これにより、クライアントは、認証応答が変更されず、認証元のサーバーによって送信されていないことを検証できます。リクエストが送信されました。要するに、それはクライアントが認可リクエストとレスポンスをクロスチェックできるようにします。
Nonceは別の目的を果たします。トークンをクライアントにバインドします。これはトークン検証パラメーターとして機能し、 OpenID Connect仕様 から導入されます。
nonce-クライアントセッションをIDトークンに関連付け、リプレイ攻撃を軽減するために使用される文字列値。値は、認証リクエストからIDトークンに変更されずに渡されます。 IDトークンに存在する場合、クライアントは、ナンス要求値が認証要求で送信されたナンスパラメータの値と等しいことを確認する必要があります。認証リクエストに存在する場合、認可サーバーは、IDトークンにナンスクレームを含めなければならず、クレームバリューは認証リクエストで送信されたナンス値です。認可サーバーは、使用されるナンス値に対して他の処理を実行すべきではありません。ナンス値は大文字と小文字を区別する文字列です
ご覧のとおり、ナンス値は認証リクエストから発生し、クライアントによって生成されます。また、ナンスが含まれている場合は、トークンに存在します。そのため、クライアントは、受け取ったトークンを最初の承認要求に対して検証できるため、トークンの有効性が保証されます。
また、フロータイプによっては、nonceが必須パラメーターになる場合があります。暗黙のフローおよびハイブリッドフローのマンデートnonce値。両方の値は、クライアントアプリケーションによってgeneratedおよびvalidatedです。
なぜ状態を再利用できなかったのですか？
承認要求がキャプチャされると、悪意のある者は承認応答を偽造できます。これは、状態パラメーターを変更することで回避できます。