ユーザークレームをJWTトークンに保存する必要がありますか？

HTTPヘッダーでJWTトークンを使用して、リソースサーバーへのリクエストを認証しています。リソースサーバーと認証サーバーは、Azureの2つの独立したワーカーロールです。

トークンにクレームを保存するか、他の方法で要求/応答に添付するかについて、思いを固めることはできません。クレームリストは、サーバー上のデータへのアクセスだけでなく、クライアント側のUI要素のレンダリングにも影響します。このため、サーバーで受信したクレームが本物であり、リクエストが処理される前に検証されていることを確認したいと思います。

クレームの例：CanEditProductList、CanEditShopDescription、CanReadUserDetails。

JWTトークンを使用したい理由は次のとおりです。

• クレームのクライアント側編集に対するより良い保護（クレームリストのハッキング）。
• リクエストごとにクレームを調べる必要はありません。

JWTトークンを使用したくない理由：

• 次に、認証サーバーはアプリ中心のクレームリストを知る必要があります。
• トークンは、ハックエントリの単一ポイントになります。
• JWTトークンはアプリレベルのデータ用ではないことをいくつか読みました。

どちらにも欠点があるように思えますが、これらの主張をトークンに含めることに傾倒しており、これを以前に扱った人によって実行したいだけです。

注：すべてのAPIリクエストにHTTPSを使用するため、トークンは「十分」に安全であると思われます。私はAngularJS、C＃、Web API 2およびMVC5を使用しています。

私はjwtに識別子クレーム（useridなど）（暗号化された）のみを保存します。

次に、サーバー（API）でトークンを取得すると、ルックアップサーバー側（db、またはローカルネットワークAPI呼び出し）を実行し、ユーザーID（アプリ、ロールなど）へのすべての関連付けを取得できます。

ただし、jwtにさらにデータを詰め込みたい場合は、各リクエストで送信される可能性が高いため、サイズに注意してください。ただし、機密性の高いクレームデータは必ず暗号化してください。

認証（ユーザーが誰であるか）と承認（ユーザーに許可されていること）は、希望するほど明確に分かれていないようです。

認証サーバーがユーザーに何の資格があるかを知りたくない場合は、wchowardが示唆したように、そのJWTのクレームをユーザーIDに制限します。認可サーバーと呼ばれる別のサーバーに、ユーザーに資格があるものを検索させることができます。

認可ステップは、クライアントが最初に認証トークンを提示したときにリソースサーバーで実行できます。リソースサーバーは、承認要求を含むトークンをクライアントに送信します。

注：両方のJWTは異なるキーで署名する必要があります。

長所：

• 認証と承認は別々に管理されます。
• リソースサーバーは、リクエストごとに承認を検索する必要はありません。
• UIには承認を表示するアクセス権がありますが、編集はできません。

短所：

• クライアントは、1つではなく2つのトークンを処理する必要があります。
• 認可サーバーを追加すると、管理する別の可動部分が追加されます。