#1の場合-認証コードフローを使用した3本足の認証。
アプリケーションが認証コードをアクセストークンと交換する場合、認証コードが提供される結果となったOAuthフローが実際に正当なユーザーによって開始されたことを確認する必要があります。そのため、クライアントアプリケーションがユーザーをプロバイダーにリダイレクトしてOAuthフローを開始する前に、クライアントアプリケーションはランダムな状態値を作成し、通常はサーバー側のセッションに保存します。次に、ユーザーがOAuthフローを完了するときに、状態値がユーザーのサーバー側セッションに保存されている値と一致することを確認します。これは、ユーザーがOAuthフローを開始したことを示します。
状態値は通常、疑似ランダムの推測できない値である必要があります。単純な値は、PHPのrand()関数を使用してintとして生成できますが、より複雑になって保証を強化することもできます。
この状態は、アカウントの認証コードを含むリンクを電子メールで送信したり、クリックしたり、アプリケーションが知らないうちにすべてのデータをアカウントにプッシュしたりすることを防ぐために存在します。
いくつかの追加情報は、OAuth 2.0脅威モデルドキュメントにあります:
https ://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-00
特に、CSRF保護に関するセクションを参照してください:
https ://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-10.12