まず、お時間をいただきありがとうございます。Live Connect の OAuth2 API について深刻な懸念があります。
私はこれに従い、DotNetOpenAuth を使用して、フェデレーション ID およびアクセス管理システムの LiveId 認証/承認を実装/統合します。
http://msdn.microsoft.com/en-us/library/live/hh243647.aspx#authcodegrant
すべてがかなり長い間正常に機能しています。しかし、現在、LiveId ログイン モジュールのリプレイ アタックの問題を修正する際に深刻な問題が発生しています。上記の記事の Authorization code grant フローを見てみましょう。
"*4. ユーザー エージェントは、リダイレクト URI を使用してクライアントを呼び出します。このリダイレクト URI には、クライアントから提供された承認コードと任意のローカル状態が含まれます。例: ...Callback.htm?code=AUTHORIZATION_CODE. 5. クライアントが要求する認証用のクライアント資格情報を使用して認可サーバーのトークン エンドポイントからアクセス トークンを取得し、前の手順で受け取った認可コードを含めます。クライアントには、検証用の認可コードを取得するために使用されたリダイレクト URI が含まれます。*"
ステップ 4 の直後に、Live Connect OAuth2 サーバーは、次のように認証コードと状態を使用してコールバック エンドポイントに戻ります。
問題は、認証コードが複数回使用される可能性があることです。したがって、次のシナリオのように、深刻なリプレイ攻撃の問題につながります。
ユーザー A がアプリケーションにログインするときに LiveId を選択してサインインすると、LiveId ログイン ページにリダイレクトされます。次にログインすると、Live Connect OAuth2 サーバーは code=xxx&state=yyy...user A でコールバック エンドポイントに戻り、この認証コードを使用してアクセス トークンを取得しました...
ユーザー B は、アプリケーションにログインするときに LiveId を選択してサインインし、LiveId のログイン ページにログインしました。Live Connect OAuth2 サーバーが code=kkk&state=ggg を返すようになりました
今回は、Webscarab などのツールを使用して応答/要求をキャプチャし、OAuth2 サーバーからの戻り値を code=xxx&state=ggg に変更します (古い認証コードはユーザー B ではなくユーザー A に与えられました)。その後、このリプレイ認証コードを使ったアクセストークンのリクエストは順調に進みました。そして、何を推測しますか？以前にユーザー A に与えられた ACCESS TOKEN を再度受け取りました...そして最終的に、ユーザー B はユーザー A として私のアプリケーションにログインできます。
上記と同じリプレイ攻撃を Google OAuth2 サーバーに適用すると、サーバーから不正なリクエスト エラーが返され、Google OAuth2 承認コードが 2 回以上使用されないことに注意してください。コード フローというか、Google ログインと LiveId ログインの実装はまったく同じです。
DotNetOpenAuth.OAuth2.WebServerClient を使用して、Google と LiveId の両方の OAuth2 認証フローを実装しました。繰り返しますが、まったく同じコードですが、Google OAuth2 サーバーは認証コードを再利用すると「不正な要求」を返しましたが、LiveId は以前のユーザーの古いアクセス トークンを返しました。
これは深刻なセキュリティ上の問題です。皆さんがこれについていくつかのアイデアを持っていることを願っています. またはうまくいけば、私はいくつかの点で間違っています。指摘してください。
Phuc Leさん、どうもありがとう。