あなたが言ったように、RFC7519（ https://tools.ietf.org/html/rfc7519 ）またはJWSまたはJWEに関連する他のRFCで定義されている最大長はありません。
JSON Serialized形式またはJSON Flattened Serialized形式を使用する場合、制限はなく、制限を定義する理由はありません。
ただし、JSON Compact Serialized形式（最も一般的な形式）を使用する場合、主にWebコンテキストで使用されるため、できるだけ短くする必要があることに留意する必要があります。 4kb JWTは避けるべきものです。
有用なクレームとヘッダー情報のみを保存するように注意してください。
私もこれを見つけようとしました。
私は言うだろう-それが7kb以下であることを確認してください。
JWTは仕様に上限を定義していません（ http://www.rfc-editor.org/rfc/rfc7519.txt ）運用上の制限があります。 JWTはHTTPヘッダーに含まれているため、現在のサーバーの大部分では8Kの上限（ SO：httpヘッダー値の最大値 ）があります。
これにはallが含まれるので、8 kb未満のリクエストヘッダー、7 kbには他のヘッダーに十分なスペースが与えられます。その制限に対する最大のリスクはCookie（ヘッダーで送信され、大きくなる可能性があります）です。
暗号化およびbase64されているため、元のjson文字列の少なくとも33％の無駄があるため、最終的な暗号化されたトークンの長さを確認してください。
最後のポイント-プロキシおよびその他のネットワークアプライアンスは、途中で任意の制限を適用する場合があります...
herokuを使用する場合、ヘッダーは8kに制限されます。 jwt2で使用しているデータの量に応じて、到達します。リクエストは、サイズが大きくてもノードインスタンスに影響せず、herokuルーターはAPIレイヤーの前にそれをドロップします。
着信要求を処理するとき、ルーターは8KBの受信バッファーをセットアップし、HTTP要求行と要求ヘッダーの読み取りを開始します。これらはそれぞれ最大で8KBの長さにすることができますが、合計で合計8KBを超えることができます。 8KBより長い要求行またはヘッダー行を含む要求は、ディスパッチされずにルーターによってドロップされます。
参照： Heroku Limits