OAuth2 のユーザー エージェント フローについて 2 つの質問があります。(OAuth2 のユーザー エージェント フローの現在の RFC ドラフトはこちら: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-11#section-2.2 )
1)
ステップ C: アクセス トークンは、ユーザー エージェント (ブラウザー) のみがアクセスできるため、フラグメントで指定する必要があります。サーバー側に到達する場合（サーバー側がある場合）、クライアント側がサーバー側にそれを渡すことができるようにする簡単な回避策もあります（Cookie、隠しフィールド、. ..)
2)
OAuth2 ユーザー エージェント フローを実装したいのですが、2 つのバージョン (request_token で十分です。コンシューマー アプリはユーザーとして機能するため、サービス プロバイダーでユーザーを認証する必要はありません)
OAuth2 のユーザー エージェント フローと 2 脚バージョンの組み合わせには、大きなセキュリティ ギャップが 1 つあります。
Web ブラウザーがすべてのリダイレクトを処理します。これは、サービス プロバイダーが指定されたホストとドメインにユーザーを送信していると考えていても、そのホストとドメインは、ユーザーが DNS 設定または /etc/hosts を微調整することにより、自分のマシンまたは任意の場所にリダイレクトするのは簡単であることを意味します。ファイル。
これを 3 脚バージョンと 2 脚バージョンで見てみましょう。
3-legged OAuth では、ユーザーはサービス プロバイダーで自分自身を認証する必要があるため、これは大きな問題ではありません。攻撃者は自分のマシンにつながる偽のドメインを設定する可能性がありますが、それでもユーザーの資格情報が必要です。彼はユーザーを自分のドメインに誘い込むことができますが、ドメイン検索の結果を作成する必要があり (ユーザーのユーザーエージェントによって行われます)、ユーザーのマシンにアクセスすることによってのみ行うことができます (これはより困難です)。
ただし、2-legged OAuth の場合: 攻撃者は、罪のないコンシューマー アプリのドメインを使用して localhost (/etc/hosts) を簡単に設定し、request_token を取得できます。ユーザーはそれとは何の関係もありません。攻撃者は、罪のないコンシューマー アプリのすべてのユーザーに代わって呼び出しを行うことができます。このギャップを確保する方法を知っている人はいますか?
こんにちは、キエルス