web-dev-qa-db-ja.com

JWTを使用するロール

私はJWTが初めてです。 JWTについて少し調べたところ、JWTが「header.claims.signature」としてフレーム化されていることがわかりました。

次のような簡単なシナリオを検討してください。

  • 顧客が認証されます
  • 顧客には、管理者、メンバー、登録済み、ゲストの(1つ以上の)ロールがあります
  • サーバーはセッションを維持しません(そして認証/承認についてはJWTのみに依存します)

認証されると、サーバーは顧客のタイプを検出し、customerIdとロールがJWTの「クレーム」の一部になると想定しています。私の仮定が間違っている(または標準に反する)場合はお知らせください。

JWTの「クレーム」部分は暗号化されていません(エンコードされているだけです)。これにより、簡単なセキュリティホールが公開され、(サービス)コンシューマーはJWTの「クレーム」部分を変更し、より多くのロール(カスタマー/コンシューマーに許可されていない)で同じものを再送信できます。

私の理解/仮定が間違っている場合、どのように目標を達成しますか?

29
user203687

[〜#〜] jws [〜#〜] (header.claims.signature)を使用する場合、JWTの「クレーム」部分は署名によって完全性が保護されます。したがって、適切なキーを持たない誰かによって「クレーム」またはJWTの他の部分が変更された場合、JWTでの署名検証は失敗し、トークンは拒否されます。

29
Brian Campbell

JWTのclaims部分は検証できますが、ロールのようなものをclaimsに追加するときの別の問題はユーザーロールを変更する場合ですが、古いトークンにはまだ割り当てられた以前のロールが含まれますユーザー。だから注意してください。トークンにユーザーIDを保持し、永続化メカニズム(データベースまたはその他)に基づいてユーザーに関連付けられているその他の情報を取得するだけです。

9
Hamid Mohayeji

別のオプションは、トークンに含まれるユーザーIDに基づいて、認証中にデータベースでユーザーを検索し、JWTに含まれていないロールまたはIDの他の側面を検証することです。

ただし、JWTに含まれる情報は、前述のように署名によって検証されるため、必要に応じてJWTの内容に依存することもできます。

3
Control Complex