JWTはクレームを署名付きトークンに入れるため、サーバーはセッションストアなしで検証できる

ユーザーがログインすると、通常サーバーはセッションIDを発行し、ユーザーをテーブルに保存する。その後、各リクエストがそのテーブルにアクセスする。これは1台のマシンでは機能するが、ステートレスなAPIサーバーの群れは、キャッシュやスティッキーセッションなしにはインメモリのテーブルを共有できない。

JWTはユーザーのクレームをトークン自体に移す。トークンはコンパクトでURLセーフなJSONペイロードであり、偽造できないように署名されている。サーバーは署名を検証し、クレームをトークンから直接読み取る。

その結果はステートレス認証である。公開鍵を知っている任意のサーバーが、共有セッションストアなしで任意のユーザーを検証できる。クレームと証明が一緒に移動するため、JWTはAPI認証とシングルサインオンのデフォルトになった。

クレームをトークンに入れる。署名が証明である。

トークンが自己完結しているため、検証者はデータベース呼び出しを必要とせず、リクエストパスは平坦で高速なままである。

セッションではなく署名が信頼のアンカーであるため、鍵を持つ任意のステートレスサーバーが任意のトークンを検証できる。

その3部分からなるheader.payload.signature構造は、Webエコシステムのあらゆる言語にとって実装が簡単である。

OAuthやOpenID Connectと組み合わせられるため、同じトークンが多くのサービスや製品で機能する。

証明がクレームと一緒に移動するなら、どこでも検証でき、検証者を水平方向にスケールできる。なぜなら、アイデンティティはルックアップではなく自己完結になるからである。

JWTは2015年5月にRFC 7519として標準化され、JWS/JWEファミリーを完備している。シングルページアプリの認証、APIゲートウェイ、マイクロサービスのデフォルトになった。既知の弱点は、失効（デナイリストなしでは有効期限前にトークンを無効化できない）とアルゴリズム混同のバグ、そして不透明なセッションに対するサイズのオーバーヘッドである。