JSON Web Token

JSON Web Token（ジェイソン・ウェブ・トークン）は、JSONデータに署名や暗号化を施す方法を定めたオープン標準 () である。略称はJWT（RFC 7519 のIntroductionで、英単語の jot と同じ「ジョット」と読むことが提案されている）。

概要 JWTでは、トークン内に任意の情報（クレーム）を保持することが可能であり、例えばサーバはクライアントに対して「管理者としてログイン済」という情報を含んだトークンを生成することができる。クライアントはそのトークンを、自身が管理者としてログイン済であることの証明に使用することができる。トークンは当事者の一方（通常はサーバ）または両方（もう一方は公開鍵を提供する）の秘密鍵により署名されており、発行されたトークンが正規のものか確認することができる。

JWTのトークンはコンパクトな設計となっており、またURLセーフである。サーバー側でセッションを保持せずにユーザーの認証・認可を管理するのに適しているため、OAuthのアクセストークンやOIDCの認証トークンとして使われている。トークンには一般的にアイデンティティプロバイダやサービスプロバイダが認証したユーザー識別情報が格納される他、各々のサービスで必要な情報も格納される。

JWTは他のJSONベースのオープン標準である (JWS, ) とJSON Web Encryption (JWE, ) に拠って立っている。

構造 JWTのトークンは以下の3つの要素から構成される。

ヘッダー{ "alg" : "HS256", "typ" : "JWT" } 署名生成に使用したアルゴリズムを格納する。左記のHS256は、このトークンがHMAC-SHA256で署名されていることを示す。

署名アルゴリズムとしては、SHA-256を使用したHMAC (HS256) や、SHA-256を使用したRSA署名 (RS256) がよく用いられる。JSON Web Algorithms (JWA, ) では認証や暗号化用のさらに多くのアルゴリズムが提示されている。ペイロード{ "loggedInAs" : "admin", "iat" : 1422779638 } 認証情報などのクレームを格納する。JWTの仕様では、トークンに一般的に含まれる7つの標準フィールドが定義されている。また用途に応じた独自のカスタムフィールドを含むこともできる。

左記の例では、トークン発行日時を示す標準のクレーム (iat) と、カスタムクレーム (loggedInAs) を格納している。署名HMAC-SHA256( base64urlEncoding(header) + '.' + base64urlEncoding(payload), secret ) トークン検証用の署名。署名は、ヘッダーとペイロードをBase64urlでエンコードされた上で、ピリオドで結合したものから生成する。署名はヘッダーで指定された暗号化アルゴリズムにより生成される。左記はHMAC-SHA256形式でのコード例である。Base64url方式は、Base64を元に特殊記号やパディングの扱いを変えたものである。

これら3つの要素は、Base64URLでエンコードされた上で、ピリオドにより結合される。以下にコード例を示す。 const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

上記データは、秘密鍵が"secretkey"の場合、以下のようなトークンとなる。

このように生成されたトークンは、HTMLとHTTPの仕組みの中で簡単に取り扱うことができる。

使用ユーザーがサーバにログインを行う場合、従来のセッションによる認証ではCookieにてセッションIDが返されるが、JWTにおいてはトークンが返され、それをローカルに保存して利用する（主にが用いられる。セッションIDのようにCookieを用いる場合もある）。

ユーザーが認証が必要な機能やリソースにアクセスする際、クライアントはトークンを何らかの手段、主としてAuthorizationヘッダーでBearerスキーマを用いてサーバに送信する。この場合、Authorizationヘッダーは以下のような形式となる。

Authorization: Bearer eyJhbGci...(中略)...yu5CSpyHI

JWTは、サーバ上に認証状態を保持しないステートレスな認証方式である。サーバはAuthorizationヘッダーで渡されたトークンが正しいかだけを検証し、アクセスを許可する。JWTにおいては、認証に必要な情報は全てトークン内に格納されており、データベースへの問い合わせを削減することができる。

標準フィールド RFC 7519においては、含める以下のような利用可能な標準フィールド（クレーム）が定義されている。

ヘッダーのフィールドコード名称説明typToken typeトークンの形式。JWTとすることが推奨される。ctyContent typeJWTを入れ子にして署名や暗号化を行う場合、このフィールドにJWTを指定する。それ以外では通常指定しない。algMessage authentication code algorithm発行者が使用した署名アルゴリズム。任意のアルゴリズムが指定可能だが、いくつかのアルゴリズムは安全ではない。NONEが指定された場合、署名なしのトークンを受け入れることになるので、安全ではない。通常はサーバーやライブラリで、NONEを無効・拒否する。その他、JWSとJWE由来のヘッダーが存在する。

ペイロードのフィールドコード名称説明issIssuerトークン発行者の識別子。subSubjectトークンの主題の識別子。audAudienceトークンが意図している受信者の識別子。トークンを受け付ける受信者は、この値に自身が含まれるかを識別しなければならない。もしaudクレームが存在し、かつ自身が含まれない場合、トークンを拒否しなければならない。expExpiration Timeトークンの有効期限。この期限以降の場合、トークンを受け付けてはならない。有効期限は1970-01-01 00:00:00Zからの秒数を数値で指定する（UNIX時間）。nbfNot Beforeトークンの開始日時。この期限以降の場合、トークンを受け付けてよい。秒数を数値で指定する。iatIssued atトークンの発行日時。秒数を数値で指定する。jtiJWT ID発行者ごとトークンごとに一意な識別子。サーバ側でjtiを利用し、トークンの使用履歴を管理することで、リプレイ攻撃を防ぐことができる。

セキュリティ対策 JWTがステートレスであり、また認証・認可のトークンとして使用されることから、窃取されたときの影響が大きい。トークンを送信する際は必ずHTTPS (HTTP over SSL/TLS) を使用し、通信経路全体を暗号化する必要がある。また、JWTトークンが漏洩した場合のリスクを考慮し、有効期限をできるだけ短く設定しておく。

JWTをCookieに保存する際は、最低限のクロスサイトスクリプティング (XSS)対策として、HttpOnlyフラグを設定し、JavaScriptからのアクセスを禁止する対策が必要である。また、クロスサイトリクエストフォージェリ (CSRF)対策として、SameSite属性をStrictまたはLaxに設定し、外部サイトからのリクエストで自動的にCookieが送信されることを制限する必要がある。

脆弱性と批判 JWTはステートレスであることから、JWT単体ではトークンを無効にすることが出来ない。従来のセッション同様、サーバに状態を保持すれば可能だが、その場合ステートレスの利点は失われる。

署名の脆弱性セキュリティコンサルタントのTim McLeanは、複数のJWTライブラリがalgクレームに署名無し (none) 等を指定した不正なトークンを処理してしまう脆弱性を報告した。これらの脆弱性は修正されたが、McLeanは同様の問題を防ぐためalgクレーム自体を廃止すべきだと主張している。

署名アルゴリズムの脆弱性については、以下のような方法で対策が可能である。

JWTヘッダーだけを見て検証しない。アルゴリズムについて知る。適切なキーサイズを用いる。

JSON Web Token

Źródło i licencja