OAuthデバッガー

Proof Key for Code Exchange（PKCE、RFC 7636）は、もともとクライアントシークレットを安全に保存できないモバイルアプリやネイティブアプリ向けに設計されました。クライアントがランダムなcode_verifierを生成し、そこからcode_challengeを導出し（SHA-256 + base64url）、認可リクエストと一緒にチャレンジを送信することで機能します。認可コードをトークンと交換する際、クライアントは元のcode_verifierを送信します。認可サーバーは、それが以前のチャレンジと一致することを検証します — これにより、トークンリクエストがフローを開始したのと同じクライアントから来たことが証明されます。

機密クライアント（クライアントシークレットを持つサーバー側アプリ）であっても、PKCEは現在OAuth 2.1により、認可コード傍受攻撃への対策として推奨されています。

インプリシットフロー（response_type=token）は、シングルページアプリ向けのショートカットとして設計され、アクセストークンをURLフラグメントに直接返します。これは深刻な問題を引き起こします。URL内のトークンはブラウザ履歴、サーバーログ、リファラーヘッダーに残り、フローはトークンインジェクション攻撃に対して脆弱です。OAuth 2.0 Security Best Current Practice（RFC 9700）とOAuth 2.1は、SPAがクライアントシークレットなしで安全に使用できる認可コード+PKCEを優先し、インプリシットフローを明示的に廃止しています。

• 機密クライアントを含むすべての認可コードフローでPKCEが必須になりました。
• インプリシットフローが廃止 — 代わりに認可コード+PKCEを使用してください。
• Resource Owner Password Credentials（ROPC）が廃止 — passwordグラントタイプは非推奨です。
• パブリッククライアントではリフレッシュトークンのローテーションが必須 — 使用のたびに新しいリフレッシュトークンを発行する必要があります。
• リダイレクトURIの完全一致が必須 — パターンマッチングやワイルドカードは使用できません。

1. PKCEペアを生成：ランダムなcode_verifierを作成し、code_challenge = BASE64URL(SHA256(code_verifier))を計算します。
2. 認可エンドポイントにリダイレクト：response_type=code、client_id、redirect_uri、scope、state、code_challenge、code_challenge_method=S256を含めます。
3. 認可サーバーでユーザーが認証し、同意を許可します。
4. エコーされたstateとともに、redirect_uriで認可コードを受け取ります — stateが送信したものと一致することを確認します。
5. コードをトークンと交換：grant_type=authorization_code、code、redirect_uri、client_id、code_verifierを使ってトークンエンドポイントにPOSTします。
6. アクセストークンを受け取り（オプションでid_tokenとrefresh_tokenも）、APIの呼び出しに使用します。