OAuth Token Translation（Opaque to JWT））
私は、APIゲートウェイでの不透明トークンからJWTトークンへのOAuthトークン変換の使用を提案するいくつかの話を見てきました。このアプローチの利点と欠点は何ですか？誰が使用する必要がありますか？
HTTPSを使用している場合、これがトークンの漏洩の点で違いを生むとは思いません。 2つの欠点は、クライアントが何ができるか、またはトークンがまだアクティブであるかどうかをクライアントが推測できないことであり、すべてのAPIをゲートウェイの背後に配置する必要があります*。
*：単一の承認サーバーと通信する限り、nゲートウェイの背後に配置することもできますが、これによりASにn倍の負荷がかかります。
これが話の例です https://youtu.be/BdKmZ7mPNns?t=901
それについての一つの注意：
現在、クライアントは何ができるか、またはトークンがまだアクティブかどうかを推測できません
JWTを保存する最も安全な方法は、おそらくhttponly（XSSを防ぐため）セキュアCookie（+ XSRFに対する対策を講じる）です。そうすると、クライアント側のコードは、JWTを直接チェックできなくなります。
最初の質問については、失効/セッションの有効期限をより詳細に制御するのに役立つと思います。 JWTをエンドユーザーに配布する場合、「exp」に達するまで無力です（このパラメーターは発行者によって決定されているため、独自のポリシーと一致しない場合があります）。不透明な識別子を使用すると、制御を維持し、いつでもアクセスを取り消すことができます。ある意味では、委任された認証にJWTを活用しながら、古い形式のセッション管理を維持できます。
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
セッションとは異なり、サーバーはいつでも無効にできるので、個々のステートレスJWTトークンを無効にすることはできません。設計上、何が発生しても、有効期限が切れるまで有効です。
ステートフルサービスの場合は、サービスごとに新しい有効期間が1回限りのトークンを渡します。このトークンは、サービス自体で交換され、その特定のサービスのセッションに使用されます。トークン自体をセッションとして使用することはありません。