ユーザークレームをJWTトークンに保存する必要がありますか？
HTTPヘッダーでJWTトークンを使用して、リソースサーバーへのリクエストを認証しています。リソースサーバーと認証サーバーは、Azureでは2つの異なるワーカーロールです。
クレームをトークンに保存するか、それとも他の方法でリクエスト/レスポンスに添付するべきかについて、私は思いを巡らせることができません。クレームリストは、クライアント側のUI要素のレンダリングとサーバー上のデータへのアクセスに影響します。このため、サーバーが受け取ったクレームが本物であり、リクエストが処理される前に検証されることを確認したいと思います。
クレームの例は、CanEditProductList、CanEditShopDescription、CanReadUserDetailsです。
JWTトークンを使用したい理由は次のとおりです。
- クレームのクライアント側編集に対する保護の強化（クレームリストのハッキングなど）。
- リクエストごとにクレームを調べる必要はありません。
JWTトークンを使用したくない理由：
- 次に、認証サーバーはアプリ中心のクレームリストを知る必要があります。
- トークンはハックエントリの単一ポイントになります。
- JWTトークンはアプリレベルのデータを対象としていないことをいくつか読んだことがあります。
どちらにも欠点があるように思えますが、私はこれらの主張をトークンに含めることに傾倒しており、これをこれまでに扱ったことがある人々によって実行したいだけです。
注：すべてのAPIリクエストにHTTPSを使用するので、トークンは「十分」に安全であるように見えます。 AngularJS、C＃、Web API 2、MVC5を使用しています。
私のjwtには識別子クレーム（ユーザーIDなど）（暗号化）のみを保存します。
次に、サーバー（API）でトークンを取得すると、サーバー側（db、またはローカルネットワークのapi呼び出し）を検索して、ユーザーIDへのすべての関連付け（アプリ、ロールなど）を取得できます。
ただし、jwtにさらに詰め込む場合は、リクエストごとに送信される可能性があるため、サイズに注意してください。ただし、機密のクレームデータは必ず暗号化してください。
認証（ユーザーが誰であるか）と承認（ユーザーに許可されていること）は、意図したとおりに明確に分割されていないようです。
認証サーバーに、ユーザーが資格を与えられているものを知らせたくない場合は、wchowardが提案するように、そのJWTのクレームをユーザーIDに制限します。認可サーバーと呼ばれる別のサーバーに、ユーザーが利用できる資格を検索させることもできます。
承認ステップは、クライアントが最初に認証トークンを提示したときに、リソースサーバーが実行できます。リソースサーバーは、承認クレームを含むトークンをクライアントに送信します。
注：両方のJWTは異なる鍵で署名する必要があります。
長所：
- 認証と承認は別々に管理されます。
- リソースサーバーは、要求ごとに承認を検索する必要はありません。
- UIには承認を表示するためのアクセス権がありますが、編集することはできません。
短所：
- クライアントは、1つではなく2つのトークンを処理する必要があります。
- 承認サーバーを追加すると、管理する別の可動部分が追加されます。