アクセス トークン、リフレッシュ トークン、スコープ、オーディエンス、およびクライアント ID の間で、Google OAuth のドキュメントで、混乱した代理人の問題を防ぐためにすべてのトークンを検証するように指示されたとき、私は混乱しました。リンクされているウィキペディアの記事では、OAuth やネットワーク認証に固有のものではなく、一般的な問題を高レベルで説明しているだけです。私が正しく理解していれば、トークンの検証は OAuth2 の一部ではなく、実際には特定の実装に依存しています。だからここに私の質問があります：
Google OAuth トークンの検証はどのように、なぜ行われるのですか?
このコンテキストでの混乱した代理問題の具体的な例は、特に高く評価されます。また、それが違いを生む場合、完全にクライアント側のアプリのコンテキストでこれを尋ねることに注意してください。
Google は特にアクセストークンについて言及しています。
OAuth 2.0 のコンテキストでは、混乱した代理人の問題は、認証に使用される場合のImplicit Grant プロトコル フローに適用されます。Google が「クライアント側アプリケーションの OAuth 2.0」と呼んでいるものは、暗黙的な付与プロトコル フローに基づいています。
暗黙的なフローは URI フラグメントを介してアクセス トークンをエンド ユーザーに公開するため、アクセス トークンが改ざんされる可能性が生じます。正当なアプリ (OAuth クライアント) は、別の (悪意のある) アプリに発行されたアクセス トークンを受け入れることで混乱した代理人になり、攻撃者が被害者のアカウントにアクセスできるようになります。
アクセス トークンを検証する際の重要なステップは、アクセス トークンが最初に別のアプリに発行されたものではないことをアプリが検証することです。Google は次のように言うと、これに注意を促します。
注: トークンを検証するときは、応答の対象者フィールドが API コンソールに登録されている client_id と正確に一致することを確認することが重要です。これは、混乱した代理人の問題を緩和するものであり、この手順を実行することは絶対に不可欠です。
簡単な例として、(1) 正規のファイル ストレージ アプリである FileStore と (2) EvilApp の 2 つのアプリがあるとします。どちらのアプリも、クライアント側アプリに Google の認証プロセスを使用します。Alice は罪のないエンド ユーザーであり、彼女の Google ユーザー ID は XYZ です。
FileStore の間違いは、与えられたアクセス トークンが実際に FileStore に発行されたものであることを Google に確認しなかったことです。トークンは実際に EvilApp に発行されました。
他の人はこれを私よりもはるかにエレガントに説明しています:
これで、クライアント側アプリでのアクセス トークンの検証の一部と、それが混乱した代理人の問題にどのように関連するかが説明されることを願っています。
OAuth2 をどのように使用していますか? 認証コードを取得し、リフレッシュ トークンと交換しますか? または、フロントエンドから直接アクセス トークンを取得していますか?
認証コードを受け取っている場合は、完了です。バックエンドで Google によって実行される client_secret のチェックにより、認証コードと引き換えに返されたすべてのトークンがアプリケーションに対して発行されたものであることが保証されます。
フロントエンド経由で access_token+id_token を受け取っている場合は、推奨ライブラリを使用して id_token 署名を検証し、id_token の「aud」フィールドが Google でアプリケーションに登録したものと一致することを検証する必要があります。完全なセキュリティのために、https://developers.google.com/accounts/docs/OAuth2Login に記載されているように、access_token と id_token (id_token には「at_hash」にファイルされた access_token の切り捨てられたハッシュが含まれます) を使用してクロス検証も行います。