OAuth 2.0 redirect_uriチェックの目的は何ですか？
OAuth 2.0仕様の認証コードメカニズムには、リダイレクト先のサイトからのリダイレクトURIチェックが含まれます。 仕様のセクション4.1のステップDおよびE を参照してください。また、- セクション4.1. リダイレクト先のクライアントがredirect_uri、そしてそれは最初の許可リクエストのそれと一致する必要があること。
これがプロトコルの一部であることによって緩和される攻撃ベクトルは考えられません。なぜこのredirect_uriチェックが必要なのですか？
redirect_uriを検証しないことで、OAuthプロバイダーを理想的なフィッシングベクトルとして使用できます。redirect_uriはOAuth =ブラウザーのリダイレクトによってaccess_tokenを配信する場所としてのプロバイダー。人気のあるOAuthプロバイダーFacebook が実行されている多くの脆弱性 OAuthリダイレクトに関連しています。
この攻撃では、攻撃者は被害者が信頼する認証ポータルへのURL（Facebookなど）を被害者に提示し、この認証ポータルを使用して、被害者のシークレットアクセストークンが攻撃者によって制御されるHTTPサーバーに配信されます。
認証は意図的なものであり、ユーザーを騙して意図しないリソースへのアクセスを許可することは脆弱性です。
コメントに基づいて編集されました。私は以前、OPが承認リクエスト中のredirect_uri検証を参照しており、攻撃の例 here にリンクしていると思っていました。以下の回答を更新しました。
TL; DR：静的リダイレクトURLを登録する必要があり、プロバイダーによって厳密に一致している場合、アクセストークンリクエスト中にredirect_uriが必要になるとは思いません。
登録要件（3.1.2.2） は、リダイレクトURIを登録する必要があることを示しています。ただし、すべてのプロバイダーがリダイレクトURIの完全一致を実行するわけではありませんが、仕様ではこれを要求しています。 OAuth仕様は、 脅威モデルとセキュリティに関する考慮事項RFC（ 5.2.4.5） 。
たとえば、GitHubが一致したURLプレフィックスは、Egor Homakovが説明した here の攻撃につながります。特に、バグ1と2では、攻撃者がホワイトリストのリダイレクトURIを使用してコードを取得し、そのコードを使用してコールバックフローを完了し、被害者のアカウントにアクセスすることができました。この場合、クライアント（Gist）は正しいリダイレクトURIをプロバイダー（GitHub）に送信し、リダイレクトURIが承認リクエスト中に使用されたものと同じであることを確認した場合、GitHubはアクセストークンを許可しませんでした。
これには欠陥がありました。クライアントがトークンを取得するためにどのredirect_uriを送信しても、プロバイダーは有効なaccess_tokenで応答しました。
攻撃者は、「漏れのある」redirect_uriに対して発行された認証コードをハイジャックし、漏れたコードを実際のクライアントのコールバックに適用して、被害者のアカウントにログインする可能性があります。
要約すると、アクセストークンを取得するときにredirect_uriが必要です。これは、リダイレクトからコードへの攻撃者がコードを挿入できるページへのリークコードがすぐにOAuthフローを危うくしないようにします。詳細攻撃ベクトルの完全な概要は、Egorも こちら で説明しています。
攻撃は簡単です。クライアントのドメインでリークしているページを見つけ、クロスドメインの画像またはWebサイトへのリンクを挿入し、このページをredirect_uriとして使用します。被害者が巧妙に細工されたURLをロードすると、被害者はLeaking_page？code = CODEに送信され、被害者のユーザーエージェントがリファラーヘッダーのコードを公開します。
これで、実際のredirect_uriで漏洩した認証コードを再利用して、被害者のアカウントにログインできます。
修正：柔軟なredirect_uriは悪い習慣です。ただし、必要な場合は、発行するすべてのコードにredirect_uriを格納し、access_tokenの作成時にそれを確認します。
エゴールが言ったように、 リンク1 ：
すべてoauthエクスプロイトは、redirect_uriパラメータの改ざんに基づいています。
および リンク2 ：
ベクトル2。仕様が適切に実装されている場合、redirect_uriを他の「漏出性のある」値に改ざんしても意味がありません。アクセストークンを取得するには、redirect_uri値をクライアントの資格情報とともに送信する必要があるためです。実際のredirect_uriが「リーキー」で、等しくない場合、実際のredirect_uriクライアントは、このコードのaccess_tokenを取得できません。
redirect_uriは、クライアントがAuthorization Codeを受信するためのコールバックです。クライアントは、コードを持っているすべての人をリソース所有者として扱います。
攻撃者は、コードを取得するために、ステップAでredirect_uriを悪意のあるものに置き換える可能性があります。次に、URIを再構築してトリガーし、セッションをリソースオーナーに属するハイジャックします。
ただし、すべてのコードには、対応するredirect_uriが発行されました。つまり、コードは汚染されたredirect_uriに基づいて計算されますステップCで.
ステップDの要求はクライアントによって行われることに注意してください。常に正しい形式のredirect_uriを使用します。最後に、Authorization Serverは、コードがURIに一致しないことが判明したため、ステップEでトークンが返されません。