認証を行うためにOAuth 2.0を誤用した場合、私は危険にさらされますか？

Question

OAuthは認証プロトコルではなく、承認プロトコルです（ Googleの最初の段落がOAuth 2.0ページに同意しない）であっても理解します、同様にそのように：

[...]認証は、エンティティAがBからOAuthを介してアクセスキーを取得し、それをサーバーSに表示した場合、サーバーSがinferアクセスキーを付与する前に、BがAを認証したことを示します。

また、ユーザーを認証する必要がある場合は、OpenIDを使用する必要があります。

しかし、実際にOAuth（- OpenID Connect ではなく、OAuth 2.0）をGoogleで使用する場合、 Webアプリケーションが安全でないことを意味しますか？アカウントへのアクセスや何かが悪用される可能性がありますか？ユーザーが他のユーザーに渡すものを偽造できますか？

質問を少し抽象的にするために、assumeとしましょう：

PythonのFlask-OAuthなどのライブラリや、他の言語の同様のライブラリは安全です。
私はグーグルを信頼し、
ユーザーのGoogleアカウントが侵害されていない（ユーザーのGoogleアカウントが侵害されている場合、攻撃者は実際に私のWebアプリケーションでユーザーのアカウントにアクセスできると予想されます）、
FAI /ホスティングサービス/その他の中間者は信頼すべきではありません。
Googleアカウントを持っている人は誰でもログイン/登録/何でもできます。
ユーザーの電子メールアドレス、姓名、その他の個人情報が本当である必要はありません。必要なのは、あるユーザーのデータを他のユーザーから保護することだけです。

SilverlightFox · Accepted Answer

主な問題は、混乱した代理問題から確実に保護することです。

アプリケーション内でユーザーを認証するためにOAuthを使用しているとします。

ただし、悪質な開発者は、OAuthも使用する独自のアプリケーションを持っています。アプリケーションが、GoogleのOAuth APIを使用するソリティアゲームであるとします。ユーザーは、Googleアカウントを使用してソリティアの認証を行います。

ただし、悪質な開発者は、Googleから取得した承認をユーザーから取得し、代わりにアプリで再生します。認証にOAuthを使用しているため、ユーザーが実際に認証したいユーザーであるという権限のあるステートメントとして承認トークンを取得していますが、それは攻撃者です。承認トークンを使用してそのユーザーとして認証するため、攻撃者はユーザーを実際に認証しているアプリケーションをだますために、承認を悪用しました。

このブログはそれをうまく説明しています。「クロスサイトリクエストフォージェリ」を意味すると思う場合、「クロスサイトスクリプティング」というフレーズを使用していることに注意してください。

audienceパラメータを適切に検証することで、これを軽減できます。また、stateを設定し、これをコールバックで検証する必要があります。これにより、CSRF攻撃がアプリケーションのユーザーに対して「ログインCSRF」攻撃を実行できなくなる可能性があります（たとえば、アプリケーションがデータをGoogleに同期した場合、攻撃者別のユーザーが自分のGoogleアカウントに同期されたデータを盗む可能性があるため、ログインしているように見せること）。

この答えも参照してください。