安全なJWT実装のベストプラクティス

JWTの安全性は、実装の安全性にかかっています。仕様には柔軟性があり、その柔軟性が脆弱性を生みます。本番システムで認証バイパスにつながってきた一般的な落とし穴を避けるため、以下のベストプラクティスに従ってください。

想定するアルゴリズムを必ず明示的に指定してください: jwt.decode(token, key, algorithms=["RS256"])。検証鍵やコードパスを選択するために、トークンヘッダーからアルゴリズムを読み取らないでください。これにより、alg=none攻撃と鍵混同攻撃を防止できます。

アクセストークン: 15～60分。リフレッシュトークン: 7～30日間、httpOnly Cookie（localStorageではなく）に保存します。期限が切れると、クライアントはリフレッシュトークンを使って認証サーバーから新しいアクセストークンを取得するため、再認証は必要ありません。

aud（オーディエンス）を検証し、トークンが別のサービスではなく自分のサービス向けに発行されたことを確認します。iss（発行者）が認証サーバーのURLと一致することを検証します。これらのチェックがないと、同じ鍵で署名された別のアプリのトークンも受け入れてしまいます。

アクセストークンはメモリ（JS変数）に保存し、タブを閉じたときに消去します。リフレッシュトークンはhttpOnly、Secure、SameSite=Strict Cookieに保存し、JavaScriptからアクセスできないようにします。JWTをlocalStorageに保存してはいけません。XSSによって盗まれる可能性があります。

JWTはステートレスであり、組み込みの失効機能はありません。選択肢としては、各リクエストでチェックする失効リスト（denylist）を管理する、非常に短い有効期限を設定する、高セキュリティの用途では中央照会を行うオペークトークンを使用する、といった方法があります。

署名鍵を定期的にローテーションしてください。JWKSには、異なるkid値を持つ複数の鍵を公開します。ローテーション中は、新しいkidで新しいトークンを発行し、古いトークンが期限切れになるまで古い鍵を有効なままにして、その後JWKSから古い鍵を削除します。

機密データ（パスワード、SSN、クレジットカード情報）をJWTペイロードに決して入れないでください。JWTはbase64urlでエンコードされているだけで、暗号化されていません。暗号化されたクレームが必要な場合はJWE（JSON Web Encryption）を使用するか、機密データをサーバー側に保持してください。

JWTはHTTPS経由でのみ送信してください。HTTP経由で傍受されたJWTは、認証を完全にバイパスするために使われます。CookieにはSecureフラグを設定してください。プロトコルのダウングレードを防ぐためにHSTSを使用してください。サーバーログに完全なJWT文字列を決して記録しないでください。

十分に保守されているライブラリを使用してください: PyJWT 2+、python-jose、auth0/node-jsonwebtoken 9+、Nimbus JOSE + JWT（Java）。JWTの検証をゼロから実装することは避けてください。ライブラリの脆弱性について、CVEデータベースを定期的に確認してください。

すべての攻撃ベクトルをテストしてください: alg=noneトークン、RS256→HS256の混同トークン、期限切れトークン、誤ったaudienceのトークン、改ざんされたペイロードを送信します。jwt.ioを使ってテストトークンを作成してください。これらが401で拒否されることを検証する統合テストを追加してください。

Webアプリケーションでは、リフレッシュトークンをどこに保存すべきでしょうか。

JWTを安全に使用するには、アルゴリズムの固定、アクセストークンの短い有効期限、リフレッシュトークンのhttpOnly Cookieへの保存、オーディエンスと発行者の検証、鍵のローテーションが必要です。次は、暗号学的な秘密分散方式について学びます。