JWTトークンサイズの考慮事項

JWTのサイズは、多くの開発者が問題に直面するまで見落としがちな実務上の懸念事項です。不透明なセッショントークン（通常32〜128バイト）とは異なり、JWTは独自のペイロードを持ち、数キロバイトにまで成長する可能性があります。トークンはすべてのAPIリクエストとともに送信されるため、そのサイズはネットワークパフォーマンスに直接影響し、インフラストラクチャの厳格な制限に達する可能性があります。

JWTサイズを決める要素:

HS256署名を使用し、subとexpのみを含む最小限のJWTは約150〜200バイトです。追加のクレームごとにペイロードが増加します。サイズに影響する一般的な要素は、ユーザーのロールとパーミッション（特に細粒度のパーミッション配列）、組織メタデータ、カスタムクレームです。署名アルゴリズムも重要です。RS256の署名は約342バイト（base64urlエンコード後）、ES256の署名は約86バイト、HS256の署名は約43バイトです。

HTTPヘッダーの制限:

JWTは通常Authorizationヘッダーで送信されます。ほとんどのWebサーバーとプロキシはヘッダーサイズの制限を設けています。Apacheのデフォルトは8KB、Nginxのデフォルトは4〜8KB、AWS API Gatewayは10KBまで許可、多くのCDNも同様の制限を設けています。これらの制限を超えるJWTは、サイレントなリクエスト失敗、431（Request Header Fields Too Large）エラー、またはプロキシの拒否を引き起こします。これらの失敗は、アプリケーションコードに到達する前にインフラストラクチャレベルで発生するため、デバッグが困難です。

Cookieサイズの制限:

JWTをCookieに保存する場合、ドメインあたり4096バイトのCookieサイズ制限が適用されます。これはブラウザの厳格な制限であり、超過するとCookieがサイレントにドロップされます。この制限は、多くのクレームやRS256署名を持つトークンにとって特に問題になります。

サイズ削減の戦略:

短いクレーム名を使用してください（例: user_role_assignmentsではなくroles）。RS256の代わりにES256を使用すると、署名だけで約256バイト節約できます。使用頻度の低いデータは、トークンに埋め込むのではなくIDで取得するサーバーサイドのユーザープロファイルに移動してください。カスタムクレームにはクレームの略称を検討してください。非常に大きなクレームセットの場合は、リファレンストークンパターンを使用してください。完全なクレームをサーバーサイドに保存し、それを参照するコンパクトなトークンを発行します。

トークンサイズの監視:

認証サービスにトークンサイズの監視やログ記録を追加してください。平均トークンサイズが閾値（例: 2KB）を超えた場合にアラートを出し、インフラストラクチャの制限に達する前に問題に対処できるようにしてください。