JSON Web Token
Web アプリケーション環境における当事者間のクレームの受け渡しのための JSON ベースのオープンスタンダード (RFC 7519)
From Wikipedia, the free encyclopedia
概要
JWTでは、トークン内に任意の情報(クレーム)を保持することが可能であり、例えばサーバはクライアントに対して「管理者としてログイン済」という情報を含んだトークンを生成することができる。クライアントはそのトークンを、自身が管理者としてログイン済であることの証明に使用することができる。トークンは当事者の一方(通常はサーバ)または両方(もう一方は公開鍵を提供する)の秘密鍵により署名されており、発行されたトークンが正規のものか確認することができる。
JWTのトークンはコンパクトな設計となっており[1]、またURLセーフである[2]。サーバー側でセッションを保持せずにユーザーの認証・認可を管理するのに適しているため、OAuthのアクセストークンやOIDCの認証トークンとして使われている[3]。トークンには一般的にアイデンティティプロバイダやサービスプロバイダが認証したユーザー識別情報が格納される他、各々のサービスで必要な情報も格納される[4][5]。
JWTは他のJSONベースのオープン標準であるJSON Web Signature (JWS, RFC 7515) とJSON Web Encryption (JWE, RFC 7516) に拠って立っている[6][7][8]。
構造
JWTのトークンは以下の3つの要素から構成される。
| ヘッダー | {
"alg" : "HS256",
"typ" : "JWT"
}
|
署名生成に使用したアルゴリズムを格納する。
左記の 署名アルゴリズムとしては、SHA-256を使用したHMAC (HS256) や、SHA-256を使用したRSA署名 (RS256) がよく用いられる。JSON Web Algorithms (JWA, RFC 7518) では認証や暗号化用のさらに多くのアルゴリズムが提示されている[9]。 |
|---|---|---|
| ペイロード | {
"loggedInAs" : "admin",
"iat" : 1422779638
}
|
認証情報などのクレームを格納する。JWTの仕様では、トークンに一般的に含まれる7つの標準フィールドが定義されている[10]。また用途に応じた独自のカスタムフィールドを含むこともできる。
左記の例では、トークン発行日時を示す標準のクレーム ( |
| 署名 | HMAC-SHA256(
base64urlEncoding(header) + '.' +
base64urlEncoding(payload),
secret
)
|
トークン検証用の署名。署名は、ヘッダーとペイロードをBase64urlでエンコードされた上で、ピリオドで結合したものから生成する。署名はヘッダーで指定された暗号化アルゴリズムにより生成される。左記はHMAC-SHA256形式でのコード例である。Base64url方式は、Base64を元に特殊記号やパディングの扱いを変えたものである。 |
これら3つの要素は、Base64URLでエンコードされた上で、ピリオドにより結合される。以下にコード例を示す。
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
上記データは、秘密鍵が"secretkey"の場合、以下のようなトークンとなる。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
使用
ユーザーがサーバにログインを行う場合、従来のセッションによる認証ではCookieにてセッションIDが返されるが、JWTにおいてはトークンが返され、それをローカルに保存して利用する(主にlocal storageやsession storageが用いられる。セッションIDのようにCookieを用いる場合もある)。
ユーザーが認証が必要な機能やリソースにアクセスする際、クライアントはトークンを何らかの手段、主としてAuthorizationヘッダーでBearerスキーマを用いてサーバに送信する。この場合、Authorizationヘッダーは以下のような形式となる。
Authorization: Bearer eyJhbGci...(中略)...yu5CSpyHI
JWTは、サーバ上に認証状態を保持しないステートレスな認証方式である。サーバはAuthorizationヘッダーで渡されたトークンが正しいかだけを検証し、アクセスを許可する。JWTにおいては、認証に必要な情報は全てトークン内に格納されており、データベースへの問い合わせを削減することができる。
標準フィールド
RFC 7519においては、含める以下のような利用可能な標準フィールド(クレーム)が定義されている。
ヘッダーのフィールド
| コード | 名称 | 説明 |
|---|---|---|
typ |
Token type | トークンの形式。JWTとすることが推奨される。 |
cty |
Content type | JWTを入れ子にして署名や暗号化を行う場合、このフィールドにJWTを指定する。それ以外では通常指定しない[10]。 |
alg |
Message authentication code algorithm | 発行者が使用した署名アルゴリズム。任意のアルゴリズムが指定可能だが、いくつかのアルゴリズムは安全ではない[11]。NONEが指定された場合、署名なしのトークンを受け入れることになるので、安全ではない。通常はサーバーやライブラリで、NONEを無効・拒否する[12]。 |
| その他、JWSとJWE由来のヘッダーが存在する[7][8]。 | ||
ペイロードのフィールド
| コード | 名称 | 説明 |
|---|---|---|
iss |
Issuer | トークン発行者の識別子。 |
sub |
Subject | トークンの主題の識別子。 |
aud |
Audience | トークンが意図している受信者の識別子。トークンを受け付ける受信者は、この値に自身が含まれるかを識別しなければならない。もしaudクレームが存在し、かつ自身が含まれない場合、トークンを拒否しなければならない。 |
exp |
Expiration Time | トークンの有効期限。この期限以降の場合、トークンを受け付けてはならない。有効期限は1970-01-01 00:00:00Zからの秒数を数値で指定する(UNIX時間)[13]。 |
nbf |
Not Before | トークンの開始日時。この期限以降の場合、トークンを受け付けてよい。秒数を数値で指定する。 |
iat |
Issued at | トークンの発行日時。秒数を数値で指定する。 |
jti |
JWT ID | 発行者ごとトークンごとに一意な識別子。サーバ側でjtiを利用し、トークンの使用履歴を管理することで、リプレイ攻撃を防ぐことができる。 |
セキュリティ対策
JWTがステートレスであり、また認証・認可のトークンとして使用されることから、窃取されたときの影響が大きい。トークンを送信する際は必ずHTTPS (HTTP over SSL/TLS) を使用し、通信経路全体を暗号化する必要がある。また、JWTトークンが漏洩した場合のリスクを考慮し、有効期限をできるだけ短く設定しておく[14]。
JWTをCookieに保存する際は、最低限のクロスサイトスクリプティング (XSS)対策として、HttpOnlyフラグを設定し、JavaScriptからのアクセスを禁止する対策が必要である。また、クロスサイトリクエストフォージェリ (CSRF)対策として、SameSite属性をStrictまたはLaxに設定し、外部サイトからのリクエストで自動的にCookieが送信されることを制限する必要がある[14]。
脆弱性と批判
JWTはステートレスであることから、JWT単体ではトークンを無効にすることが出来ない。従来のセッション同様、サーバに状態を保持すれば可能だが、その場合ステートレスの利点は失われる[15]。
署名の脆弱性
セキュリティコンサルタントのTim McLeanは、複数のJWTライブラリがalgクレームに署名無し (none) 等を指定した不正なトークンを処理してしまう脆弱性を報告した。これらの脆弱性は修正されたが、McLeanは同様の問題を防ぐためalgクレーム自体を廃止すべきだと主張している[11]。
署名アルゴリズムの脆弱性については、以下のような方法で対策が可能である[16]。
- JWTヘッダーだけを見て検証しない。
- アルゴリズムについて知る。
- 適切なキーサイズを用いる。