【ITニュース解説】Essential JWT Security (Part 2): Refresh Tokens and Revocation Made Simple

JSON Web Token、通称JWTは、ウェブアプリケーションでユーザーの認証情報を安全にやり取りするための仕組みとして非常に便利に使われている。しかし、その手軽さゆえに、適切なセキュリティ対策を怠ると深刻な問題につながる可能性を秘めている。特に、一度ユーザーに発行したJWTを、どうやって取り消すかという点は、多くの開発者が直面する課題だった。

多くのシステムでは、ユーザーがログインするとサーバーはユーザーが誰であるかを証明するトークンを発行する。このトークンは、ユーザーがアプリケーション内の様々な機能にアクセスする際に提示され、サーバーはそのトークンを検証することでユーザーのアクセス権限を確認する。JWTが持つ「ステートレス」、つまりサーバーが個々のユーザーの状態を記憶する必要がないという特性は、大規模なアプリケーションにおいて高いパフォーマンスとスケーラビリティをもたらす。しかし、このステートレス性が「一度発行したトークンは、有効期限が切れるまでサーバー側から強制的に無効にすることができない」という問題を引き起こすのだ。

例えば、ユーザーがログアウトしたとしても、もしそのユーザーのJWTが盗まれていたら、有効期限内であれば盗んだ人物は正規のユーザーとしてアプリケーションにアクセスし続けることができる。また、ユーザーがパスワードを変更した場合や、何らかの理由で不審な活動が検知された場合でも、有効期限が切れるまで待つしかないというのはセキュリティ上大きなリスクとなる。この「取り消せない」というJWTの課題を解決し、セキュリティと利便性を両立させるために考案されたのが、「アクセス・トークン」と「リフレッシュ・トークン」という二種類のトークンを組み合わせる方法である。

このアプローチでは、トークンにそれぞれ異なる役割と有効期限を持たせる。アクセス・トークンは、アプリケーションのほとんどのAPI（機能）にアクセスするための「日帰りパス」のようなものだ。有効期限は非常に短く設定され、例えば15分といった短い時間で自動的に無効になる。この短い有効期限により、たとえアクセス・トークンが盗まれたとしても、悪用できる時間が限定されるため、被害のリスクを大幅に低減できる。アクセス・トークンは、アプリケーションが起動している間だけメモリ上に保持され、ブラウザのタブを閉じたり、アプリケーションを終了したりすれば自動的に消滅する。永続的な保存は行わないため、ブラウザを閉じればセッションも終了するという、一般的なユーザーの期待に沿った動作となる。

一方、リフレッシュ・トークンは、この短命なアクセス・トークンを新しく発行するための「シーズンパス」のような役割を担う。有効期限はアクセス・トークンよりも長く、例えば1週間から1ヶ月といった期間が設定されることが多い。リフレッシュ・トークンは直接APIへのアクセスには使われず、その主な目的は有効期限が切れたアクセス・トークンを更新することにある。このリフレッシュ・トークンは、クロスサイトスクリプティング（XSS）のような攻撃から保護するため、特別な方法で保存される。具体的には、ウェブブラウザのCookie機能のうち、JavaScriptから直接アクセスできない「HttpOnly」属性を付けて保存される。これにより、悪意のあるJavaScriptがブラウザに埋め込まれたとしても、リフレッシュ・トークンを盗み出すことが非常に困難になる。さらに、サーバー側ではこのリフレッシュ・トークンをデータベースに保存し、ユーザーごとに管理することが重要となる。

アクセス・トークンが短命であると、ユーザーは頻繁にログインし直さなければならないため、利便性が損なわれると感じるかもしれない。そこで活躍するのがリフレッシュ・トークンを使った「サイレントリフレッシュ」の仕組みだ。アプリケーションは、アクセス・トークンの有効期限が切れそうになった時や、APIにアクセスして「401 Unauthorized」（未認証）エラーが返された時に、バックグラウンドでリフレッシュ・トークンをサーバーに送信し、新しいアクセス・トークンを取得する。この処理はユーザーに意識させることなく自動的に行われるため、ユーザーはログインし直すことなくアプリケーションを使い続けることができ、非常にスムーズなユーザー体験が提供される。

そして、この二種類のトークンモデルの最も強力な利点が、前述の「取り消せない」問題を解決する「失効（Revocation）」機能である。リフレッシュ・トークンをサーバー側のデータベースで管理することで、サーバーはいつでも特定のユーザーのリフレッシュ・トークンを無効化できる。具体的には、ユーザーが「ログアウト」ボタンをクリックした時、サーバーはデータベースからそのユーザーのリフレッシュ・トークンを削除する。また、ユーザーがパスワードを変更した場合や、セキュリティ上の懸念から不審な活動が検知された場合にも、関連する全てのリフレッシュ・トークンをデータベースから削除することで、それ以降そのトークンを使って新しいアクセス・トークンを発行することを完全に停止させることができるのだ。これにより、もしリフレッシュ・トークンが盗まれたとしても、サーバー側で即座にそのトークンを無効化することで、悪用されるリスクを最小限に抑えることが可能となる。

このように、アクセス・トークンとリフレッシュ・トークンを組み合わせるモデルは、JWTの持つ本来の利点である「高速性」と「スケーラビリティ」を維持しつつ、従来のセッション管理システムが提供していた「セッションの制御」（ログアウトやセッション強制終了など）という重要なセキュリティ機能を後付けすることを可能にする。これは、現代の堅牢なウェブアプリケーションを構築する上で不可欠なセキュリティ設計であり、単にJWTを発行するだけでは実現できない、現実世界でのセキュリティ要件を満たすための洗練されたアプローチと言える。システムエンジニアを目指すならば、このトークンモデルの理解と適切な実装は、安全で信頼性の高いアプリケーションを開発するための基礎となるだろう。