JWTの無効化実装例

こんばんは、ritou です。

今日は　JWTの無効化の方法はいっぱいあるよ って話を書きます。

単体での無効化(jti, 文字列全体のハッシュ)

これが最も一般的な JWT無効化の方法 と言えるかもしれません。

ちょっと前に話題になった「Stateless」なユースケースにおける無効化できないみたいな話に絡むところでしょう。

The "jti" (JWT ID) claim provides a unique identifier for the JWT.

例えば失効対象の jti のリストを管理することで無効化判定ができるでしょう。
有効期限を持つかどうかにより対象の jti をいつまで保持するか、などの細かい要件は変わります。

これ以外にも、JWTに含まれる claim を利用した検証 ってのは 無効化管理/判定 をしていると言いかえることもできます。

時刻での無効化(iat, exp)

ほとんどのユースケースで exp の値と現在時刻の値を比較することで無効化の判定をしているでしょう。
iat の値を利用して この時刻以前に生成されたJWTは無効 と言う判定も可能です。

例えば、パスワード変更したら既存のセッションを無効化したい みたいなときにパスワード変更日時をDBに保持していたら既に発行済みのJWTの iat と比較して無効化判定ができます。

対象者単位の無効化(sub)

例えばユーザーIDが　sub の値に含まれている場合、 ユーザーDBを引いてそのユーザーが存在しない(退会した)とかの場合は無効である という判定ができるでしょう。

送信元/受信者での無効化(iss, aud)

このあたりも同様ですね。

鍵単位の無効化(kid)

まだまだあまり鍵の追加、更新を意識してJWTを使う開発者が少ない気がしますが、

1. ある時点で有効な鍵(A)の情報を jwk_uri で提供している
2. 新しく署名生成/検証に利用する鍵(B)の情報を jwk_uri　に追加
3. その鍵(B)を利用してJWTを生成開始
4. 鍵(A)のJWTを無効にしたいときは jwk_uri から削除
5. 鍵(A)のJWT検証時に無効判定

みたいな流れはあり得るでしょう。

アルゴリズム単位で無効化(alg)

このアルゴリズムは対象外とする！
みたいな場合は alg を用いた判定をすることもありそうです。

まとめ

検証可能な claim の数だけ無効化の実装方法がある と言えるでしょう。

ではまた。