JSON Web Token

JSON Web Token（ジェイソン・ウェブ・トークン）は、JSONデータに署名や暗号化を施す方法を定めたオープン標準 (.mw-parser-…

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

概要

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"
}
署名生成に使用したアルゴリズムを格納する。

左記のHS256は、このトークンがHMAC-SHA256で署名されていることを示す。

署名アルゴリズムとしては、SHA-256を使用したHMAC (HS256) や、SHA-256を使用したRSA署名 (RS256) がよく用いられる。JSON Web Algorithms (JWA, RFC 7518) では認証や暗号化用のさらに多くのアルゴリズムが提示されている[9]。

ペイロード 
{
 "loggedInAs" : "admin",
 "iat" : 1422779638
}
認証情報などのクレームを格納する。JWTの仕様では、トークンに一般的に含まれる7つの標準フィールドが定義されている[10]。また用途に応じた独自のカスタムフィールドを含むこともできる。

左記の例では、トークン発行日時を示す標準のクレーム (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"の場合、以下のようなトークンとなる。 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

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

使用

ユーザーがサーバにログインを行う場合、従来のセッションによる認証では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]。

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

関連項目

出典

  1. ^ Nickel, Jochen (2016). Mastering Identity and Access Management with Microsoft Azure. p. 84. ISBN 9781785887888. https://books.google.com/books?id=Q4dcDgAAQBAJ&pg=PA84&dq=jwt+smaller+saml&hl=en&sa=X&ved=0ahUKEwiWouXcu67cAhUSJt8KHV0UD2IQ6AEINzAC#v=onepage&q=jwt%20smaller%20saml&f=false 2018年7月20日閲覧。 
  2. ^ a b “JWT.IO - JSON Web Tokens Introduction”. jwt.io. 2018年7月20日閲覧。
  3. ^ “第2章 2.ユーザ認証を外部化する場合 | アーカイブ”. IPA 独立行政法人 情報処理推進機構. 2025年9月19日閲覧。
  4. ^ Sevilleja, Chris. “The Anatomy of a JSON Web Token”. 2015年5月8日閲覧。
  5. ^ “Atlassian Connect Documentation”. developer.atlassian.com. 2015年5月8日閲覧。
  6. ^ “draft-ietf-oauth-json-web-token-32 - JSON Web Token (JWT)”. tools.ietf.org. 2015年5月8日閲覧。
  7. ^ a b “draft-ietf-jose-json-web-signature-41 - JSON Web Signature (JWS)”. tools.ietf.org. 2015年5月8日閲覧。
  8. ^ a b “draft-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)”. tools.ietf.org. 2015年5月8日閲覧。
  9. ^ “draft-ietf-jose-json-web-algorithms-40 - JSON Web Algorithms (JWA)”. tools.ietf.org. 2015年5月8日閲覧。
  10. ^ a b John, Bradley. “JSON Web Token (JWT)”. tools.ietf.org. 2016年11月14日閲覧。
  11. ^ a b McLean, Tim (2015年3月31日). “Critical vulnerabilities in JSON Web Token libraries”. Auth0. 2016年3月29日閲覧。
  12. ^ Author, Vaadata (2025年4月30日). “JWT: Vulnerabilities, Attacks & Security Best Practices” (英語). 2025年9月19日閲覧。
  13. ^ John, Bradley,. “JSON Web Token (JWT)” (英語). tools.ietf.org. 2017年12月20日閲覧。
  14. ^ a b “JWTでアプリのセキュリティを高める方法”. www.wallarm.com. 2025年9月19日閲覧。
  15. ^ “Stop using JWT for sessions”. joepie91 Ramblings. 2018年8月1日閲覧。
  16. ^ “Common JWT security vulnerabilities and how to avoid them” (英語). 2018年5月14日閲覧。

外部リンク

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.