JWTでのロールの要求（またはその他の要求）の更新/変更
（APIエンドポイントを制限するために）JWT内にユーザーロールを格納しています。役割は管理者が変更できます。
役割が変更された場合。これをすべてのトークン内に反映するにはどうすればよいですか？私はいくつかの解決策について考えました：
更新トークンを使用する場合、ユーザーはアクセストークンの有効期限が切れるまで待つ必要があります。
変更されたユーザーIDの記録を保持し、すべての要求を確認して、ユーザーが変更された場合は新しいトークンを返すことができます。
これを行う標準的な方法はありますか？
更新トークンを瞬時に変更することに関心がある場合、更新トークンは解決策ではないように思われます。ユーザーの権限を取り消す場合、ユーザーがしばらくの間モデレートツールにアクセスすることは望ましくありません。
あなたができることは、mongooseが versionKey で行うように、ユーザーに関連するjwtトークンにバージョン番号を保持することです。これにより、このバージョンを、特定のユーザーのデータベース内のバージョンと照合することができます。このユーザーのロールを変更するたびに、このバージョンをインクリメントします。jwtのバージョンが一致しない場合は、正しいロールとバージョンで新しいバージョンを再作成し、ユーザーに送り返します。
Jwtは設計上不変なので、「更新」する必要がある場合は完全に変更する必要があります。
JWTトークンは不変なので、既存のトークンのクレームを変更/更新することはできません。そのため、新しいJWTトークンを発行する必要があります。
これが、JWTの最大の問題であるトークンの取り消しにつながります。良い解決策はありません。あなたにできることは
JWTの有効期限を短くする（およびオプションで更新トークンを使用する）
ブラックリストを使用して、取り消されたトークンのリストを保持します（もちろん、この方法で「ステートレス」部分を失います）
秘密鍵を変更します（これにより、すべてのユーザーのすべての有効なトークンが取り消されることに注意してください）
最善の解決策は、具体的なケースによって異なります。
このシナリオに対処するために、トークンの有効期間を短く保つことができます。トークンの有効期限が切れると、暗黙的な付与の場合にサイレントにトークンを更新するか、更新トークンメカニズムを使用して、承認サーバーから新しいトークンを発行できます。ロールが変更されると、すぐにはトークンに反映されない可能性がありますが、トークンが更新されると使用できるようになります。
@Janarは、異なるシナリオを処理するための3つの解決策を述べましたが、それらには依然として対応する欠点があります。
私はあなたのトークンを取り消すことも考えています：
iatをJWTペイロードに設定します。 （iatとは何かを知っている必要があります）- ユーザーのトークンを取り消す：
- ユーザーIDを見つける
- 認証サーバーに、現在時刻より前（iatによって判断）でこのユーザー（userIdによって判断）に属するトークンを拒否させる