JWTでログアウトを実装する方法｜トークン無効化の考え方

RJC Techチーム

JWT（JSON Web Token）は、一度発行すると、有効期限が切れるまでそのままでは無効化できません。サーバーがログイン状態を記録しない（ステートレス）ことがJWTの特徴で、署名が正しく期限内であれば、サーバーはそのトークンを受け入れるからです。

そのため「ログアウトボタンを押したのに、トークンを持っていればAPIが使える」という状態が起こり得ます。この記事では、その理由と、ログアウトや強制失効を実現する主な方法、それぞれの使い分けを解説します。

なぜJWTは無効化できないのか

従来のセッション方式では、サーバーがセッションIDとログイン状態を保存し、ログアウト時にそのセッションを削除します。サーバー側の記録を消せば、そのIDは使えなくなります。

JWTは、ユーザー情報と有効期限をトークン自体に含め、署名で改ざんを防ぎます。サーバーは署名と有効期限を検証するだけで、トークンの状態を記録しません。これにより、どのサーバーでも検証でき、スケールしやすいという利点があります。

その裏返しとして、「このトークンはもう使えない」という情報を持つ場所がないため、有効期限が来るまで使えてしまうのです。

ログアウト時にブラウザからトークンを削除すれば、通常の操作ではもう使われません。これは必要な処理ですが、それだけでは十分ではありません。

サーバー側で失効を判断できる仕組みを、要件に応じて組み合わせる必要があります。

最も一般的な構成です。

ログアウト時は、サーバー側でリフレッシュトークンを削除（失効）します。アクセストークンは短い期限で自然に切れ、新しいものは発行されなくなります。

利点：APIの呼び出しごとにサーバーの状態を確認しなくて済むので、JWTの利点をほぼ保てる 注意点：アクセストークンの有効期限の間（数分）は、ログアウト後も使えてしまう。この「猶予」を許容できるかが判断基準です

リフレッシュトークンを使うたびに新しいリフレッシュトークンを発行し、古いものを失効させる方式です。万一リフレッシュトークンが盗まれても、正規ユーザーと攻撃者のどちらかが古いトークンを使った時点で不正を検知し、そのトークン系列をまとめて失効させる、といった対策が取れます。

ログアウトしたトークンの識別子（JWTの jti クレームなど）を、有効期限まで失効リストに保存し、APIの呼び出しごとにリストを確認する方法です。

利点：ログアウトの瞬間から、そのトークンを使えなくできる 注意点：呼び出しごとにリストの確認が必要になり、ステートレスの利点が一部失われる

リストには「有効期限までのトークン」だけを保存すればよいので、期限切れのものは自動で削除される仕組み（有効期限付きのキーを扱えるストア等）を使うと、肥大化を防げます。

ユーザー情報に「トークンのバージョン番号」を持たせ、JWTにもその番号を含めます。全端末からのログアウトやパスワード変更時にバージョンを上げると、古い番号のトークンはすべて無効になります。

利点：「全端末からログアウト」「パスワード変更時に全セッションを失効」が1操作でできる 注意点：呼び出しごとにユーザーのバージョンを確認する必要がある（キャッシュで負荷を抑えるのが一般的）

方法	ログアウトの即時性	サーバーの状態	向いている要件
短命アクセストークン＋リフレッシュトークン	数分の猶予あり	リフレッシュトークンのみ	多くのWebアプリ・モバイルアプリ
失効リスト	即時	失効したトークン	即時の失効が必須のシステム
トークンバージョン	即時（全端末単位）	ユーザーごとの番号	全端末ログアウト・強制失効が必要

多くのシステムでは、方法1を基本に、必要に応じて方法2か3を組み合わせる構成が現実的です。金融・医療など、ログアウトや権限変更を即座に反映する必要がある場合は、即時性のある方法を併用します。

ログアウトの設計と同じくらい重要なのが、ブラウザのどこにトークンを保存するかです。

localStorage — JavaScriptから読めるため、XSS（悪意あるスクリプトの注入）が起きるとトークンを盗まれる
HttpOnly属性付きのCookie — JavaScriptから読めないため、XSSによる窃取を防げる。CSRF対策（SameSite属性やトークン）とセットで使う

どちらが絶対に正しいというより、守りたい脅威に合わせて選ぶものです。リフレッシュトークンのように長く有効なものは、HttpOnly Cookieに置く構成がよく採用されます。