操作して学ぶ
OAuth 2.0 フロー可視化
「OAuthは結局どこで何が起きているのか」を、認可コードフロー（+PKCE）として 1ステップずつ追えます。ユーザー・クライアント・認可サーバー・API の4者の間を、ブラウザ経由（フロントチャネル）とサーバー間の直接通信（バックチャネル）に分けて可視化します。 「▶ 次へ」または「自動再生」で進めてください。
ブラウザ経由（フロント）直接通信（バック）内部処理
1 / 11
クライアント内部クライアント（内部）
1. 準備：PKCE と state を生成
code_verifier（乱数）code_challenge = SHA256(code_verifier)state（乱数）クライアントはまず2つの乱数を作る。code_verifier は手元に秘匿し、そのSHA256ハッシュ code_challenge だけを後で送る。state はこのログイン試行に紐づく識別子。
要点PKCE は認可コードの横取り対策、state は CSRF 対策。どちらもこの後の攻撃を防ぐ布石。
なぜこんな回り道をするのか
「最初からアクセストークンをくれればいいのに」と感じる遠回りには、すべて理由があります。 鍵はブラウザを通る通信（フロントチャネル）は漏れやすいという前提です。 URL は履歴・リファラ・ログに残り、盗聴もされうる。だから設計はこう組まれています。
- 認可コードを挟む理由：ブラウザには使い捨ての一時コードだけを流し、本物のトークンはブラウザを通らないバックチャネルで受け取る。トークンが URL や履歴に残らない。
- PKCE が守るもの：万一その認可コードを盗まれても、
code_verifierを知らない攻撃者はトークンに交換できない。秘密を隠し持てない SPA・モバイルアプリで必須とされる。 - state が守るもの：攻撃者が用意した認可コードを掴まされる CSRF を防ぐ。送った
stateと戻ってきたstateの一致確認がその要。 - Implicitフローが非推奨になった理由：かつてはトークンをフロントチャネルに直接返す方式もあったが、露出リスクが高く、現在は認可コード + PKCE に一本化する流れ。