web-dev-qa-db-ja.com

OAuth2リソースサーバーは、他のユーザーリソースへの不正アクセスを防ぐために、それを承認したユーザーにアクセストークンをどのように関連付けることができますか？

OAuth2 RFC に従って、リソースサーバーがアクセストークンに関連付けられているユーザーを推測できるかどうか、またはそれが予想される場合でも、誰かが片付けてくれるとありがたいです。

次のことを前提とします。

  • 認可サーバーとリソースサーバーは分離され、独立しています。
  • clientは印刷サービスです。
  • リソースサーバーはユーザーの写真をホストします。
  • clientがresource serverから保護されたAPIを呼び出してユーザーの写真を取得したい https：// es/api/users/USER_ID/photos およびそれらを印刷します。
  • clientはユーザーを独立した認可サーバーにリダイレクトし、最終的にアクセストークンを生成します。
  • clientはそのアクセストークンを使用してユーザーの写真を取得して印刷します。

トークンは不透明であり、独立したリソースサーバーにもクライアントにも意味がないため、クライアントがそのアクセストークンを使用してユーザーから写真にアクセスして印刷することを妨げるものはありません。それを承認した人だけ。

これは正解？または、リソースサーバーはユーザーをトークンにどのように関連付けて、その使用を制限しますか？

oauthoauth2
3
codependent

リソースサーバーが認証サーバーにトークンメタデータを照会する方法として、 OAuth 2.0 Token Introspection を実装できます。

定義されたイントロスペクション応答フィールドを使用して、subおよびusernameフィールドでリソース所有者IDを転送できます。

さらに、トークンが本当に不透明な場合は、チェックする方法であるため、イントロスペクションを実装する必要があるだけでなく、実装する必要があります。

  • トークンが実際に正しい認証サーバーによって発行されている場合-暗号化によってもそれを保証できますが、後のことはできません
  • トークンがまだアクティブな場合
  • トークンがそれを使用してクライアントに発行された場合
  • トークンのスコープが要求された操作をカバーする場合
1
AGrzes

oAuth 2.0にはこれを行うための組み込みメカニズムはありませんが、これを機能させるために使用できるスキームがいくつかあります。

  1. 必要なユーザー情報を取得するために、トップオフの認証レイヤーを使用oAuth（openID Connectなど）

  2. ユーザーの詳細ごとにスコープを追加して、そのユーザーの詳細にアクセスし、そのユーザーにのみそのスコープを付与します。発生する可能性のある情報漏洩に注意してください。

  3. 承認プロバイダーをゲートキーパーとして使用し、画像が実際に保存されているリソースサーバーではなく、特定のユーザーに対して要求された詳細を提供します。警官のようなものですが、うまくいくでしょう。

3
LvB

OAuthはauthorizationを処理します。トークンは、委任されたアクセス許可のみを示します。権限を委任したユーザーに関する情報も含まれている可能性がありますが、実際にはユーザーを表していません。アクセス許可を理解し、それに応じて使用を制限するのは、リソースサーバーの役割です。

サーバーの性質上、ユーザーのIDなしではこれを設定できない場合は、OAuthと連動するauthenticationソリューション（OpenID Connectなど）が必要になります。

1
AlphaD

承認は、アプリケーションサーバーと承認サーバーの信頼性を維持するリダイレクトの実装で実行されます。

OAuthはさまざまなタイプのワークフローをサポートしています。 Authorization Code Grantタイプは、Webブラウザーのリダイレクト機能を利用するように最適化されているため、最も一般的に使用されます。

詳細については、次のリソースをご覧ください：-

https://revs.runtime-revolution.com/an-in-depth-look-at-the-oauth2-redirect-flow-8a5e6c964085

0
Aayush