署名する代わりに本体を暗号化する（JWTなどを使用）
「クレーム/ボディ/データ」を暗号化してユーザーに送信すると、どのような問題が発生しますか。ユーザーがこの暗号化トークンを送信すると、それを復号化して信頼し、その中のデータを操作します（もし秘密鍵を使用して復号化できます）。したがって、基本的にはJWTと同じ考え方だけですが、ヘッダーと署名は送信せず、本文は暗号化されます。
これに既知の/暗黙の脆弱性はありますか？
TL; DR：推奨されません。公開鍵暗号化を使用したくない場合は、HMACを使用できます。
暗号化を使用することはある程度はうまくいくかもしれませんが、あなたは本当に自分が何をしているかを知る必要があるか、あなたが幸運になることを願っています。
署名/ MACはメッセージ全体が変更されるのを防ぎます。暗号化は変更を防止しません。それを防止できる唯一のことは、攻撃者が何を変更しているかを知ることです。
これで、たとえばユーザーIDの場所がわかっている（そして幸運である）場合など、形式がわかっていれば、それを盲目的に別の（ランダム）IDに変更できます。これは、攻撃者にとって有用な場合とそうでない場合がありますが、多くの問題が発生します。
また、暗号化アルゴリズム、パディング（ある場合）、およびその他の要因によっては、追加の問題が発生する可能性があります。
たとえば、スキームにIVがない場合、攻撃者は1つのメッセージの一部と別のメッセージの一部を取得して、それらを混在させることができます。それでは、2つのメッセージを傍受するとします。 1つはあなたを管理者にし、もう1つは私をユーザーにします。私はメッセージから名前を、あなたのマッサージからランク（管理者）を取得して、自分を管理者にすることができる場合があります。
また、AndrolGenhaldによって指摘されているように、[〜＃〜] ctr [〜＃〜]モード（AESまたは他のブロック暗号）を使用すると、攻撃者は暗号化されたメッセージを、それがそうである限り、完全に変更できます。同じ長さ。これは、あまり知られていないモードや暗号で可能になる場合もあります。
PS：GCMモードのAESは、データの暗号化と認証の両方に使用できるため、データの機密性が必要な場合は、上記のすべての問題を防止し、望ましい方法です。ただし、IVとMACを本文とともに送信する必要があります。