0

これは、別の OAuth の質問で回答されているように感じますが、見つかりませんでした...

私が書いている Web サービスに OAuth プロバイダーを実装しました。プロバイダー (「アプリケーション」) の OAuth コンシューマーはコンシューマー キーを持ち、典型的な OAuth の方法でユーザー アクセス トークンを取得します (リクエスト トークンを取得し、プロデューサーにリダイレクトしてユーザーに承認させ、アクセス トークンを取得し、それを保存するなど)。 . これはすべてうまくいきます。

私の質問は、これらの OAuth コンシューマーがアプリケーションのログイン資格情報を使用して訪問時に誰かを認証する方法についてです。基本的に、誰かが消費者向けアプリケーションにアクセスしたとき、私は次のことを望んでいます。

  1. ユーザーが消費者サイトでログインをクリックします。
  2. ユーザーはアプリケーションにリダイレクトされ、ログイン フォームが表示されます。
  3. ログイン後、私のアプリケーション (OAuth プロバイダー) は、このユーザーが既にこのコンシューマーを承認していることを認識し、それらをコンシューマーにリダイレクトします。
  4. コンシューマーは、このリクエストでこのユーザーのユーザー名 (またはアクセス トークン) を何らかの方法で通知されます。

これは、OAuth コンシューマが承認済みのリクエスト トークンをアクセス トークンと交換する必要がないことを除いて、一般的な OAuth フローに似ています。代わりに、ユーザーが認証されるとすぐに、コンシューマーは認証されたユーザーを認識し、既に保存されているトークン/シークレットを使用してすぐにリクエストを開始できます。

これを実装する際に考慮する必要があるセキュリティ条件は何ですか? これは安全に実装することさえ可能ですか? ナイーブに、これは、ユーザーのユーザー名 (またはその他の固有のもの) を使用して、プロデューサーがコンシューマー コールバックに GET パラメーターを返すようにすることで実装できます。ただし、攻撃者は、攻撃したいユーザーのユーザー名を使用してコンシューマーのコールバックにリクエストを送信することで、これを悪用する可能性があります。

考え?これは、私が再発明して再実装しようとしている解決済みの問題ですか? 私のプラットフォームは Java です。これをすべて実行しているライブラリがある場合です。ありがとうございました!

4

1 に答える 1

0

あなたの問題は(3)です:

「ログイン後、私のアプリケーション (OAuth プロバイダー) は、このユーザーが既にこのコンシューマーを承認していることを認識し、それらをコンシューマーにリダイレクトします。」

OAuth プロバイダーは、このユーザーが既に認証/承認されていることを認識できません。これは、承認がアプリによって行われていないためです。アプリは、誰が認証され、誰が認証されていないか、および何に対して承認されているかを決定する必要があります。これが OAuth の全体的な考え方です。

コンシューマーによって認証されたユーザーを「認識」する OAuth プロバイダーを実装する場合、コンシューマーはプロバイダーに何かを送信する必要があり、コンシューマー (OAuth クライアント) とアプリ (OAuth プロバイダー) の間の結合が作成されます。

OAuth SPECは OAuthの一般的なインターフェイスを正確に定義しているため、それに固執する場合は、プロバイダーに余分なデータを送信しないようにする必要があります。これにより、特定のクライアントに結合されなくなります。

于 2013-01-23T07:58:47.973 に答える