0

RESTful サービスを保護するために OAuth 2.0 に飛び込んでいます。私はコンシューマー側とプロバイダー側​​を所有しているため、エンドユーザーがプロバイダー上のデータへのアクセスを許可する必要はありません。クライアント資格情報フローを試してみましたが、これはクライアント全体のトークンしか取得できず、個々のユーザーのトークンは取得できないようです。Javascript でクライアントのトークンを使用した場合、トークンはすべてのユーザーに渡され、ユーザーが他のすべてのユーザーのデータを取得する可能性があるため、安全性が低くなります。

2-legged (別名クライアント資格情報) を使用して、Ajax/Javascript で使用できるユーザー固有のトークンを取得する方法はありますか (暗黙的なフローが提供するものと同様ですが、ユーザーの承認は必要ありません)。

ありがとう。

4

2 に答える 2

0

そうです、標準では「クライアント資格情報の付与」シナリオのユーザー資格情報については何も述べられていません。ただし、保護されたリソースがユーザーに属している場合、各トークンは特定のユーザーに関連付けられている必要があります。あなたの質問に基づいて、私はこれが事実だと思います。

OAuthサーバーも実装している場合は、これを簡単に行うことができます。「クライアント資格情報の付与」シナリオでは、許可要求に「user_id」パラメーターを追加するだけです。サーバー側でリクエストを処理し、指定されたユーザーにトークンを関連付けることができます。これは、プロトコルに対する独自のわずかな拡張と見なすことができます。

また、完全に標準に準拠し、石で書かれていないことは何もしないことをお勧めします。そうしないと、OAuthサーバーの実装にアクセスできない場合があります。この場合、ユーザーにとらわれないトークン(または質問で呼び出した「クライアント全体」のトークン)を使用しようとする場合があります。ただし、保護されたリソースにアクセスする場合は、トークン自体から推測できないため、ユーザーを明示的に指定する必要があります(たとえば、リソースパスの一部として、またはHTTPを使用するクエリパラメーターで)。

于 2012-06-08T11:23:51.510 に答える
0

クライアントを自動承認する機能を発見したので、特定のクライアントがデータにアクセスするときにユーザーが承認する必要はありません。両方の Web サイトで同じシングル サインオン メカニズムを使用しており、プロバイダーへのログインはユーザーに対して透過的であるため、これは私のシナリオでは機能します。

于 2012-06-28T19:04:11.130 に答える