OAuth 2.0承認コードフローは「ショルダーサーフィン」に対して脆弱ですか？
OAuth Webアプリケーションで認証コードフローを使用する場合、リソース所有者の認証が成功した後、認証サーバーは通常ブラウザリダイレクトで応答し、リダイレクトURLを介して認証コードをクライアントに返します。クエリ文字列。
これで、リダイレクトURLが十分に短い場合、URL全体（認証コードを含む）がブラウザーのアドレスバーの表示スペースに収まります。被害者の肩越しに見ている攻撃者は、この認証コードを見ることができます。理論的には、攻撃者が被害者のブラウザよりも高速である場合、攻撃者はこの認証コードを盗んで自分のクライアントのリダイレクトエンドポイントに渡すことができます。
実際の例：
誰かがブラウザウィンドウを低レイテンシで一般の視聴者にライブストリーミングしています。視聴者の攻撃者が攻撃を完全に自動化しました。ビデオストリームがキャプチャされ、認証コードが傍受されて、被害者のログインセッションを盗むために使用されます。
質問：
- この攻撃を防ぐためにクライアント（または対応するバックエンド）ができることはありますか？
- または、承認サーバーのみで攻撃をより困難にすることができますか？ 1つのアイデアは、非常に長いリダイレクトURLの最後にある認証コードを非表示にすることです。しかし、ユーザーのクライアントが現在利用できない場合はどうなりますか？タイムアウトしたリダイレクトリクエストのURLは、被害者のブラウザ履歴に引き続き表示され、認証コードが期限切れにならない限り、攻撃は機能しています。
この攻撃を防ぐためにクライアント（または対応するバックエンド）ができることはありますか？
OAuth 2.0 PKCE拡張機能 が探していたようです。説明したように このスレッド内 の場合、PKCE拡張機能は、漏洩した認証コードが攻撃者にとって有用であることを防ぎます。
これは、認証コード（デフォルトのクライアントシークレットと同様）を利用するときだけでなく、認証リクエストを作成するときにも（たとえば、ユーザーセッション固有の）シークレットを認証サーバーと交換することで実現されます。プロセス全体を通して、秘密（したがってセッション）は同じままです。