web-dev-qa-db-ja.com

複数のリソースサーバーにスコープを持つトークンのOAuth2 JWT暗号化

OAuth2デプロイメントのコンテキスト内で、複数のリソースサーバーにスコープを持ち、すべてのリソースサーバー間でシークレットを共有する承認サーバーとは関係なく、各リソースサーバーによって復号化できる暗号化されたJWTをクライアントに付与します。

このシナリオで解決する仕様はありますか？

次のセクションの要件では、残りの制約をいくつか指定しています。

必要条件

  • （トークンイントロスペクションエンドポイントなどを介して）トークンを承認サーバーにプロキシする必要なく、リソースサーバーレイヤーで復号化を行う必要があります。
  • リソースサーバーは、特定の秘密キーが侵害される可能性のある攻撃面を制限するために、すべて個別の秘密キーを持っている必要があります。
  • OpenID Connectへの準拠を維持するために、JWTはコンパクトフォーマットを使用する必要があります（これは本当ですか、またはOpenID ConnectはJWT（JWS/JWE）JSONシリアル化フォーマットで機能しますか？）

使用例

認証コード付与（ https://tools.ietf.org/html/rfc6749#section -1.3.1 ）私のユースケースをさらに説明するために。

  • 認可サーバーの登録ユーザーとして
  • 登録済みのOAuth2クライアントアプリケーションに（ユーザーエージェントを使用して）初めてアクセスしたとき
  • 次に、Authorization Code Grantのクエリに必要なクエリパラメータ（scopes = "photos.read、photos.write、friends.read"を含む）を使用して、Authorization Serverにリダイレクトする必要があります

  • また、次のサービスへの委任アクセスを要求する承認ダイアログが表示されます。

    • 写真を読む
    • あなたに代わって写真をアップロードする
    • 友達を読んで

  • 「承認」をクリックすると

  • 次に、承認コードを使用して、登録済みのOAuth2クライアントアプリケーションにリダイレクトされます。
  • OAuth2クライアントアプリケーションシステムが認証コードを使用してトークンをリクエストしたとき

  • 次に、OAuth2クライアントアプリケーションシステムは、次のスコープを持つトークンを受け取ります。

    • photos.read
    • photos.write
    • friends.read

（...）

このシステムの私の実装では、「写真リソース」と「友達リソース」は2つの異なるリソースサーバー上にあります。上記のように、これらのリソースサーバーが同一の秘密鍵を共有しないことが目標です。

可能な解決策

  1. 複数の受信者によるJWE JSONシリアル化（ https://tools.ietf.org/html/rfc7516#appendix-A.4.7 ）。はJWEコンパクトフォーマットではなくJWE JSONシリアル化メソッドを使用しているため、これは上記の要件に違反しています。上記の質問のとおり、OpenID ConnectはJWTコンパクト形式しか使用できないようです。ここで私の仮定が間違っている場合、おそらくこれは合理的な解決策ですか？

これを読んでくれてありがとう。私は本当に提案やポインタをいただければ幸いです。

oauthjwt
2
Will Sulzer

私はあなたのような「問題」に直面したので、数回あなたの質問を読みました。トークンとしてOpenID ConnectとJWTを使用したOAuth2を使用して提示されたソリューションは正しいです。私はMediumに書いた article で、OpenID ConnectでOAuth2を使用する方法を詳しく説明しました。ご不明な点がございましたら、お気軽にお問い合わせください。

後で編集

OAuth2の弱点の1つは、リソースサーバーがアクセストークンを検証したり、アクセストークンを使用してユーザーのIDを確立したりするための規定された方法がないことです。

Googleおよびその他のOAuth2プロバイダーは、TokenInfoエンドポイントを提供することでこの問題を解決しました。リソースサーバーは、アクセストークンをこのエンドポイントに渡し、トークンの有効性、ユーザーID、トークンのスコープ、および有効期限に関する情報を取得できます。私の場合、このエンドポイントは許可サーバーに対応しています。

enter image description here

この概念は、IDトークンの導入によりOpenID Connectで拡張されました。 IDトークンは、ユーザーのIDとスコープ内のクレームを含む、署名され暗号化されている可能性のあるトークンです。

enter image description here

IDトークンは、IDデータを含むJSON Web Token（JWT）です。クライアントによって消費され、ユーザーの名前、電子メールなどのユーザー情報を取得するために使用されます。これは、リソースサーバーのチェーンがあり、リソースサーバーが別のリソースサーバーのクライアントになる場合にも役立ちます。

JWT機能により、クライアントアプリケーションとリソースサーバーは、承認サーバーに毎回アクセスする必要なく、ユーザーに関する情報を安全に直接取得できます。

enter image description here

過度に広いアクセストークンの発行を防ぎたい場合は、チェーンの各ポイントで承認チェックを提供できます。リソースサーバーは、承認サーバーのクライアントになり、そのJWTを提示し、チェーン内の次のリソースサーバーの新しいJWTを要求できます。

3
Mihaila Adrian