oauth2の「状態」パラメーターを使用して、ユーザーを識別するためにセッションCookieを使用することを回避できますか
https://tools.ietf.org/html/rfc6749#section-4.1.1 の状態：
4.1.1。承認リクエスト」
"状態"
推奨。リクエストとコールバックの間の状態を維持するためにクライアントが使用する不透明な値。認可サーバーは、ユーザーエージェントをクライアントにリダイレクトするときにこの値を含めます。セクション10.12で説明されているように、クロスサイトリクエストフォージェリを防止するためにパラメータを使用する必要があります（SHOULD）。
承認フローのプロバイダーコールバックでユーザーを識別するために、CSRF保護のほかにOAuth2承認リクエストで（_uuid/v4_）を生成する「状態」パラメーターを使用しても安全ですか？したがって、oauth2フローを「ステートレス」にし、ロードバランサーに「スティッキーセッション」を必要としません。
現在、ユーザーがOAuth2フロー（ログインページにアクセス）を開始すると、一意の_auth-request-id_とstateを作成してRedisに格納し、_auth-request-id_をCookieに送信します。
ユーザーがコールバックリクエストでプロバイダー（GoogleまたはFacebook）にログインした後、Redisで_auth-request-id_ Cookieからユーザーのセッションを検索し、セッションが存在するかどうか、および受信したstateが送信したものと一致するかどうかを検証します（CSRF攻撃に対して）。
疑問に思って、_auth-request-id_ Cookieの作成をスキップして、stateによってコールバックでユーザーを識別できますか？一致するstateがない場合のロジックを指定しますRedisにあり、状態が無効であり、stateに保存されているすべてのRedisの有効期限が5分間であると想定します。
あなたはこれを安全に行うことができないと思います。
悪意のある俳優がアプリケーションを使用してリダイレクトを自由に取得する可能性があります。ここで、彼が無防備な犠牲者にリダイレクトアドレスを開かせることができた場合、犠牲者はあなたのアプリケーションがアクセスを要求しているのを見るでしょう。彼がアクセスを許可すると、彼はあなたにリダイレクトされます。もしあなたが彼を特定するために州だけを使用しているなら、あなたはあなたのアプリの悪意のある俳優アカウントに犠牲者のリソースを割り当てました。