[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 7797, 8725 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7519 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Token (JWT)
要約
JSON Web Token (JWT) は、2 つの当事者間で転送される
クレームを表現するための、コンパクトで URL セーフな手段である。
JWT におけるクレームは JSON オブジェクトとして符号化され、JSON
Web Signature (JWS) 構造のペイロードとして、または JSON Web
Encryption (JWE) 構造の平文として使用される。これにより、クレームは
デジタル署名されるか、メッセージ認証コード (MAC) によって完全性が
保護され、かつ／または暗号化される。
本メモの位置付け
本文書は、インターネット標準トラック文書である。
本文書は Internet Engineering Task Force
(IETF) による成果物である。これは IETF コミュニティの合意を表す。
本文書は公開レビューを受け、Internet Engineering Steering Group
(IESG) によって公開が承認されている。インターネット標準に関する
追加情報は RFC 5741 のセクション 2
に記載されている。
本文書の現在の状態、正誤表、ならびにフィードバックの提供方法に関する
情報は、以下から入手できる。
http://www.rfc-editor.org/info/rfc7519.
Jones, et al. Standards Track [Page 1]
RFC 7519 JSON Web Token (JWT) May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones, et al. Standards Track [Page 2]
RFC 7519 JSON Web Token (JWT) May 2015
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 表記規則 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token (JWT) の概要 . . . . . . . . . . . . . . . . 6
3.1. JWT の例 . . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT クレーム . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. 登録済みクレーム名 . . . . . . . . . . . . . . . . . . . 9
4.1.1. "iss" (発行者) クレーム . . . . . . . . . . . . . . . 9
4.1.2. "sub" (主体) クレーム . . . . . . . . . . . . . . . . 9
4.1.3. "aud" (対象者) クレーム . . . . . . . . . . . . . . 9
4.1.4. "exp" (有効期限) クレーム . . . . . . . . . . . . . . 9
4.1.5. "nbf" (この時刻以前は無効) クレーム . . . . . . . . . 10
4.1.6. "iat" (発行時刻) クレーム . . . . . . . . . . . . . . 10
4.1.7. "jti" (JWT ID) クレーム . . . . . . . . . . . . . . . 10
4.2. 公開クレーム名 . . . . . . . . . . . . . . . . . . . . . 10
4.3. 私用クレーム名 . . . . . . . . . . . . . . . . . . . . . 10
5. JOSE ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ" (型) ヘッダパラメータ . . . . . . . . . . . . . . 11
5.2. "cty" (コンテンツ型) ヘッダパラメータ . . . . . . . . . 11
5.3. ヘッダパラメータとしてのクレームの複製 . . . . . . . . . 12
6. 非保護 JWT . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. 非保護 JWT の例 . . . . . . . . . . . . . . . . . . . . 12
7. JWT の生成と検証 . . . . . . . . . . . . . . . . . . . . 13
7.1. JWT の生成 . . . . . . . . . . . . . . . . . . . . . . 13
7.2. JWT の検証 . . . . . . . . . . . . . . . . . . . . . . 14
7.3. 文字列比較規則 . . . . . . . . . . . . . . . . . . . . 15
8. 実装要件 . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. コンテンツが JWT であることを宣言するための URI . . . . . . 17
10. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token クレームレジストリ . . . . . . . . . . . 17
10.1.1. 登録テンプレート . . . . . . . . . . . . . . . . . 18
10.1.2. 初期レジストリ内容 . . . . . . . . . . . . . . . . 18
10.2. urn:ietf:params:oauth:token-type:jwt
のサブ名前空間登録 . . . . . . . . . . . . . . . . . 19
10.2.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 19
10.3. メディアタイプ登録 . . . . . . . . . . . . . . . . . . 20
10.3.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 20
10.4. ヘッダパラメータ名の登録 . . . . . . . . . . . . . . . 20
10.4.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 21
11. セキュリティに関する考慮事項 . . . . . . . . . . . . . . . 21
11.1. 信頼に関する判断 . . . . . . . . . . . . . . . . . . . 21
11.2. 署名および暗号化の順序 . . . . . . . . . . . . . . . . . 21
12. プライバシーに関する考慮事項 . . . . . . . . . . . . . . . 22
13. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. 規定参照文献 . . . . . . . . . . . . . . . . . . . . . 22
13.2. 参考参照文献 . . . . . . . . . . . . . . . . . . . . . 23
Jones, et al. Standards Track [Page 3]
RFC 7519 JSON Web Token (JWT) May 2015
付録 A. JWT の例 . . . . . . . . . . . . . . . . . . . . . . . 26
A.1. 暗号化された JWT の例 . . . . . . . . . . . . . . . . . 26
A.2. ネストされた JWT の例 . . . . . . . . . . . . . . . . 26
付録 B. JWT と SAML アサーションの関係 . . . . . . . . . . . 28
付録 C. JWT と Simple Web Token (SWT) の関係 . . . . . . . 28
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 29
1. はじめに
JSON Web Token (JWT) は、HTTP 認可ヘッダや URI クエリ
パラメータなどの、空間制約のある環境を想定した、
コンパクトなクレーム表現形式である。JWT は、JSON
Web Signature (JWS) [JWS] 構造のペイロード、または JSON Web
Encryption (JWE) [JWE] 構造の平文として使用される
JSON [RFC7159] オブジェクトとしてクレームを符号化し、
クレームをデジタル署名するか、メッセージ認証コード
(MAC) によって完全性を保護し、かつ／または暗号化する。
JWT は常に、JWS Compact Serialization または JWE Compact
Serialization を用いて表現される。
JWT の推奨される発音は、英単語 "jot" と同じである。
1.1. 表記規則
本文書における "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", および "OPTIONAL" というキーワードは、
「RFC における要求レベルを示すためのキーワード」
[RFC2119] に記載されているとおりに解釈される。
これらの解釈は、用語がすべて大文字で記載されている場合にのみ適用される。
2. 用語
「JSON Web Signature (JWS)」、「Base64url Encoding」、「Header
Parameter」、「JOSE Header」、「JWS Compact Serialization」、
「JWS Payload」、「JWS Signature」、および「Unsecured JWS」
という用語は、JWS 仕様 [JWS] により定義されている。
「JSON Web Encryption (JWE)」、「Content Encryption Key
(CEK)」、「JWE Compact Serialization」、「JWE Encrypted Key」、
および「JWE Initialization Vector」という用語は、JWE 仕様
[JWE] により定義されている。
「Ciphertext」、「Digital Signature」、「Message Authentication
Code (MAC)」、および「Plaintext」という用語は、
「Internet Security Glossary, Version 2」
[RFC4949] により定義されている。
Jones, et al. Standards Track [Page 4]
RFC 7519 JSON Web Token (JWT) May 2015
以下の用語は、本仕様により定義される：
JSON Web Token (JWT)
一連のクレームを表す JSON オブジェクトを、JWS または JWE に
符号化した文字列であり、クレームをデジタル署名するか、
MAC により保護し、かつ／または暗号化することを可能にする。
JWT クレーム集合
JWT によって伝達されるクレームを含む JSON オブジェクト。
クレーム
主体について主張される情報の一部。クレームは、
クレーム名とクレーム値からなる名前／値の対として表現される。
クレーム名
クレーム表現における名前の部分。クレーム名は常に文字列である。
クレーム値
クレーム表現における値の部分。クレーム値は任意の JSON 値を取ることができる。
ネストされた JWT
署名および／または暗号化が入れ子で使用される JWT。
ネストされた JWT では、JWT は外側の JWS または JWE 構造の
ペイロードまたは平文値として、それぞれ使用される。
非保護 JWT
クレームが完全性保護も暗号化もされていない JWT。
衝突耐性のある名前
他の名前と衝突する可能性が極めて低い方法で名前を割り当てることを可能にする
名前空間内の名前。衝突耐性のある名前空間の例としては、
ドメイン名、ITU-T X.660 および X.670 勧告シリーズで定義される
オブジェクト識別子 (OID)、ならびに
Universally Unique IDentifier (UUID)
[RFC4122] がある。
管理的に委任された名前空間を使用する場合、名前の定義者は、
自身が使用している名前空間の部分を管理していることを確実にするため、
合理的な予防措置を講じる必要がある。
StringOrURI
JSON の文字列値であり、任意の文字列値を使用してよいが、
":" 文字を含む値は URI
[RFC3986] でなければならないという追加要件を持つ。
StringOrURI 値は、大文字小文字を区別する文字列として、
変換や正規化を行わずに比較される。
Jones, et al. Standards Track [Page 5]
RFC 7519 JSON Web Token (JWT) May 2015
NumericDate
1970-01-01T00:00:00Z UTC から、指定された UTC の日時までの
秒数を表す JSON の数値。うるう秒は無視される。
これは、IEEE Std 1003.1, 2013 Edition
[POSIX.1] における
「Seconds Since the Epoch」の定義と等価であり、
各日は正確に 86400 秒として計算される点は同じだが、
非整数値を表現できる点が異なる。
日時全般および UTC に関する詳細については
RFC 3339
[RFC3339] を参照されたい。
3. JSON Web Token (JWT) の概要
JWT は、一連のクレームを表す JSON オブジェクトを、
JWS および／または JWE 構造に符号化したものである。
この JSON オブジェクトが JWT クレーム集合である。
RFC 7159 のセクション 4
[RFC7159] に従い、
JSON オブジェクトは 0 個以上の名前／値の対（またはメンバー）から構成され、
名前は文字列であり、値は任意の JSON 値である。
これらのメンバーが、JWT により表現されるクレームである。
この JSON オブジェクトは、
RFC 7159 のセクション 2
[RFC7159] に従い、
JSON 値や構造文字の前後に空白や改行を含んでもよい。
JWT クレーム集合内のメンバー名は、クレーム名と呼ばれる。
対応する値は、クレーム値と呼ばれる。
JOSE ヘッダの内容は、JWT クレーム集合に適用される暗号操作を記述する。
JOSE ヘッダが JWS 用である場合、JWT は JWS として表現され、
クレームはデジタル署名されるか MAC 処理され、
JWT クレーム集合は JWS ペイロードとなる。
JOSE ヘッダが JWE 用である場合、JWT は JWE として表現され、
クレームは暗号化され、JWT クレーム集合は
JWE によって暗号化される平文となる。
JWT は、別の JWE または JWS 構造に内包されることで、
ネストされた JWT を作成することもでき、
これにより署名および暗号化の入れ子処理が可能となる。
JWT は、ピリオド ('.') 文字で区切られた、
URL セーフな複数の部分の列として表現される。
各部分には base64url で符号化された値が含まれる。
JWT の部分数は、JWS Compact Serialization または
JWE Compact Serialization を用いた結果の
JWS または JWE の表現に依存する。
Jones, et al. Standards Track [Page 6]
RFC 7519 JSON Web Token (JWT) May 2015
3.1. JWT の例
以下の例の JOSE ヘッダは、符号化されたオブジェクトが JWT であり、
JWT が HMAC SHA-256 アルゴリズムを用いて
MAC 処理された JWS であることを宣言している：
{"typ":"JWT",
"alg":"HS256"}
上記の JSON オブジェクト表現における潜在的な曖昧さを除去するため、
上記 JOSE ヘッダの実際の UTF-8 表現に用いられる
オクテット列も以下に示す。
（曖昧さは、改行コードの違い（CRLF と LF）、
行頭および行末の空白の違い、
最終行に改行があるかどうか、
その他の要因によって生じる可能性がある。
本例で使用されている表現では、
最初の行には先頭および末尾の空白がなく、
1 行目と 2 行目の間に CRLF の改行 (13, 10) があり、
2 行目には先頭に 1 つの空白 (32) があり末尾の空白はなく、
最終行には終端の改行がない。）
本例における JOSE ヘッダの UTF-8 表現を表すオクテット列
（JSON 配列記法を使用）は次のとおりである：
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
JOSE ヘッダの UTF-8 表現のオクテットを
Base64url エンコードすると、
次のエンコード済み JOSE ヘッダ値が得られる：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
以下は、JWT クレーム集合の例である：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
以下のオクテット列は、
上記 JWT クレーム集合に対して本例で使用されている
UTF-8 表現であり、JWS ペイロードである：
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
Jones, et al. Standards Track [Page 7]
RFC 7519 JSON Web Token (JWT) May 2015
JWS ペイロードを Base64url エンコードすると、このエンコードされた
JWS ペイロードが得られる（表示目的のためにのみ改行を含む）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
エンコードされた JOSE ヘッダーおよびエンコードされた JWS ペイロードの
MAC を HMAC SHA-256 アルゴリズムで計算し、その HMAC 値を
[JWS] で規定されている方法で
base64url エンコードすると、次のエンコードされた JWS 署名が得られる：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
これらのエンコードされた各部品を、この順序で、部品間にピリオド ('.')
文字を挿入して連結すると、この完全な JWT が得られる
（表示目的のためにのみ改行を含む）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
この計算は、[JWS] の
付録 A.1 において、より詳細に示されている。
暗号化された JWT の例については 付録 A.1 を参照されたい。
4. JWT クレーム
JWT クレームセットは、JWT によって伝達されるクレームをメンバーとして
含む JSON オブジェクトを表す。JWT クレームセット内のクレーム名は
一意でなければならない。JWT パーサーは、重複するクレーム名を含む
JWT を拒否するか、または ECMAScript 5.1 の
セクション 15.12（「JSON オブジェクト」）で規定されているように、
字句的に最後の重複メンバー名のみを返す JSON パーサーを使用しなければ
ならない。
JWT が有効と見なされるために含まなければならないクレームの集合は、
コンテキスト依存であり、本仕様の範囲外である。JWT の特定のアプリケーション
では、実装が特定の方法でいくつかのクレームを理解し、処理することが
要求される。しかし、そのような要件がない場合、実装によって理解されない
すべてのクレームは無視されなければならない。
JWT クレーム名には、登録クレーム名、公開クレーム名、非公開クレーム名の
3 つのクラスがある。
Jones, et al. Standards Track [Page 8]
RFC 7519 JSON Web Token (JWT) May 2015
4.1. 登録クレーム名
以下のクレーム名は、セクション 10.1 によって確立された
IANA の「JSON Web Token Claims」レジストリに登録されている。以下で定義
されるクレームはいずれも、すべてのケースで使用または実装が必須と
意図されているわけではなく、むしろ有用で相互運用可能なクレーム集合の
出発点を提供するものである。JWT を使用するアプリケーションは、どの
クレームを使用し、それらが必須か任意かを定義すべきである。すべての
名前が短いのは、JWT の中核的な目標が表現をコンパクトにすることである
ためである。
4.1.1. 「iss」（Issuer）クレーム
「iss」（issuer）クレームは、JWT を発行した主体を識別する。この
クレームの処理は、一般にアプリケーション固有である。「iss」の値は、
StringOrURI 値を含む大文字小文字を区別する文字列である。このクレームの
使用は任意である。
4.1.2. 「sub」（Subject）クレーム
「sub」（subject）クレームは、JWT の主体となる主体を識別する。JWT 内の
クレームは、通常、主体に関する記述である。主体の値は、発行者の文脈内で
局所的に一意であるか、またはグローバルに一意でなければならない。この
クレームの処理は、一般にアプリケーション固有である。「sub」の値は、
StringOrURI 値を含む大文字小文字を区別する文字列である。このクレームの
使用は任意である。
4.1.3. 「aud」（Audience）クレーム
「aud」（audience）クレームは、JWT が意図している受信者を識別する。
JWT を処理することが意図されている各主体は、audience クレーム内の値で
自身を識別しなければならない。このクレームが存在する場合に、クレームを
処理する主体が「aud」クレーム内の値で自身を識別しない場合、その JWT は
拒否されなければならない。一般的な場合、「aud」の値は、StringOrURI 値を
含む大文字小文字を区別する文字列の配列である。JWT に 1 つの audience
しかない特別な場合には、「aud」の値は、StringOrURI 値を含む単一の
大文字小文字を区別する文字列であってもよい。audience 値の解釈は、
一般にアプリケーション固有である。このクレームの使用は任意である。
4.1.4. 「exp」（Expiration Time）クレーム
「exp」（expiration time）クレームは、JWT が処理のために受け入れられては
ならない時刻、またはそれ以降の有効期限時刻を識別する。「exp」クレームの
処理では、現在の日付／時刻が、「exp」クレームに記載された有効期限の
日付／時刻より前でなければならない。
Jones, et al. Standards Track [Page 9]
RFC 7519 JSON Web Token (JWT) May 2015
実装者は、通常は数分以内の小さな猶予を設けて、時計のずれを考慮してもよい。
その値は NumericDate 値を含む数値でなければならない。このクレームの使用は
任意である。
4.1.5. 「nbf」（Not Before）クレーム
「nbf」（not before）クレームは、JWT が処理のために受け入れられてはならない
それ以前の時刻を識別する。「nbf」クレームの処理では、現在の日付／時刻が、
「nbf」クレームに記載された not-before の日付／時刻以降でなければならない。
実装者は、通常は数分以内の小さな猶予を設けて、時計のずれを考慮してもよい。
その値は NumericDate 値を含む数値でなければならない。このクレームの使用は
任意である。
4.1.6. 「iat」（Issued At）クレーム
「iat」（issued at）クレームは、JWT が発行された時刻を識別する。この
クレームは JWT の経過時間を判断するために使用できる。その値は NumericDate
値を含む数値でなければならない。このクレームの使用は任意である。
4.1.7. 「jti」（JWT ID）クレーム
「jti」（JWT ID）クレームは、JWT に一意の識別子を提供する。この識別子の
値は、同じ値が誤って別のデータオブジェクトに割り当てられる確率が
無視できるように割り当てられなければならない。アプリケーションが複数の
発行者を使用する場合には、異なる発行者によって生成される値間の衝突も
防止されなければならない。「jti」クレームは、JWT のリプレイを防止する
ために使用できる。「jti」の値は大文字小文字を区別する文字列である。
このクレームの使用は任意である。
4.2. 公開クレーム名
クレーム名は、JWT を使用する者が自由に定義できる。しかし、衝突を防止する
ために、新しいクレーム名は、セクション 10.1 によって
確立された IANA の「JSON Web Token Claims」レジストリに登録されるか、
または公開名、すなわち衝突耐性のある名前を含む値であるべきである。
いずれの場合も、その名前または値を定義する者は、クレーム名を定義するために
使用する名前空間の部分を自らが管理していることを確認するために、
合理的な予防措置を講じる必要がある。
4.3. 非公開クレーム名
JWT の生成者および消費者は、登録クレーム名
（セクション 4.1）や公開クレーム名
（セクション 4.2）ではない非公開名の
クレーム名を使用することに合意してもよい。公開クレーム名とは異なり、
Jones, et al. Standards Track [Page 10]
RFC 7519 JSON Web Token (JWT) May 2015
非公開クレーム名は衝突の可能性があり、注意して使用すべきである。
5. JOSE ヘッダー
JWT オブジェクトにおいて、JOSE ヘッダーによって表される JSON オブジェクトの
メンバーは、JWT に適用される暗号操作、ならびにオプションで JWT の追加の
プロパティを記述する。JWT が JWS か JWE かに応じて、JOSE ヘッダー値に対する
対応する規則が適用される。
本仕様は、JWT が JWS である場合と JWE である場合の両方において、以下の
ヘッダーパラメーターの使用をさらに規定する。
5.1. 「typ」（Type）ヘッダーパラメーター
[JWS] および
[JWE] によって定義される
「typ」（type）ヘッダーパラメーターは、JWT アプリケーションが、この完全な
JWT のメディアタイプ [IANA.MediaTypes] を宣言するために
使用される。これは、JWT でない値も含み得るアプリケーションデータ構造内に
JWT オブジェクトが存在する場合に、アプリケーションが存在し得る異なる種類の
オブジェクトを区別するために使用されることを意図している。通常、オブジェクトが
JWT であることがすでに分かっている場合には、アプリケーションによって使用されない。
このパラメーターは JWT 実装によっては無視され、このパラメーターの処理は
JWT アプリケーションによって行われる。存在する場合には、このオブジェクトが
JWT であることを示すため、その値を「JWT」とすることが推奨される。メディアタイプ名は
大文字小文字を区別しないが、従来の実装との互換性のために、「JWT」は常に
大文字で綴ることが推奨される。このヘッダーパラメーターの使用は任意である。
5.2. 「cty」（Content Type）ヘッダーパラメーター
[JWS] および
[JWE] によって定義される
「cty」（content type）ヘッダーパラメーターは、本仕様において JWT に関する
構造的な情報を伝達するために使用される。
入れ子になった署名や暗号化操作が使用されない通常のケースでは、この
ヘッダーパラメーターの使用は推奨されない。入れ子になった署名または暗号化が
使用される場合には、このヘッダーパラメーターは存在しなければならず、
この場合、その値は、この JWT にネストされた JWT が含まれていることを示すため、
「JWT」でなければならない。メディアタイプ名は大文字小文字を区別しないが、
従来の実装との互換性のために、「JWT」は常に大文字で綴ることが推奨される。
ネストされた JWT の例については 付録 A.2 を参照されたい。
Jones, et al. Standards Track [Page 11]
RFC 7519 JSON Web Token (JWT) May 2015
5.3. クレームをヘッダーパラメーターとして複製する
暗号化された JWT を使用する一部のアプリケーションでは、いくつかの
クレームについて、暗号化されていない表現を持つことが有用である。例えば、
JWT が復号される前に、それを処理するかどうか、またどのように処理するかを
判断するためのアプリケーション処理規則で使用されることがある。
本仕様は、アプリケーションによって必要とされる場合に、JWT クレームセットに
含まれるクレームを、JWE である JWT のヘッダーパラメーターとして複製することを
許可する。そのように複製されたクレームが存在する場合、アプリケーションが
それらのクレームに対して別の特定の処理規則を定義していない限り、受信側の
アプリケーションは、それらの値が同一であることを検証すべきである。暗号化されて
いない形で伝送しても安全なクレームのみが、JWT のヘッダーパラメーター値として
複製されるようにする責任は、アプリケーションにある。
本仕様の セクション 10.4.1 は、暗号化された JWT において
それらを必要とするアプリケーションのために、これらのクレームの暗号化されていない
複製を提供する目的で、「iss」（issuer）、「sub」（subject）、
「aud」（audience）のヘッダーパラメーター名を登録している。他の仕様も同様に、
必要に応じて、登録クレーム名である他の名前をヘッダーパラメーター名として
登録してもよい。
6. 非セキュア JWT
JWT 内に含まれる署名および／または暗号化以外の手段（例えば、JWT を含む
データ構造に対する署名）によって JWT の内容が保護されるユースケースを
サポートするため、JWT は署名や暗号化なしで作成される場合もある。非セキュア
JWT は、JWA 仕様 [JWA] で定義されているように、
「alg」ヘッダーパラメーターの値が「none」であり、JWS 署名値として空文字列を
使用する JWS である。これは、JWT クレームセットを JWS ペイロードとする
非セキュアな JWS である。
6.1. 非セキュア JWT の例
次の例の JOSE ヘッダーは、エンコードされたオブジェクトが非セキュア JWT
であることを宣言している：
{"alg":"none"}
JOSE ヘッダーの UTF-8 表現のオクテット列を Base64url エンコードすると、
次のエンコードされた JOSE ヘッダー値が得られる：
eyJhbGciOiJub25lIn0
Jones, et al. Standards Track [Page 12]
RFC 7519 JSON Web Token (JWT) May 2015
次は、JWT クレームセットの例である：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWT クレームセットの UTF-8 表現のオクテット列を Base64url エンコードすると、
次のエンコードされた JWS ペイロードが得られる
（表示目的のためにのみ改行を含む）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
エンコードされた JWS 署名は空文字列である。
これらのエンコードされた各部品を、この順序で、部品間にピリオド ('.')
文字を挿入して連結すると、この完全な JWT が得られる
（表示目的のためにのみ改行を含む）：
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
7. JWT の生成および検証
7.1. JWT の生成
JWT を生成するには、次の手順を実行する。手順の順序は、手順間に
入力および出力の依存関係がない場合には重要ではない。
1. 必要なクレームを含む JWT クレームセットを作成する。表現中の
空白は明示的に許可されており、エンコード前に正規化を行う必要はない。
2. メッセージを、JWT クレームセットの UTF-8 表現のオクテット列とする。
3. 必要なヘッダーパラメーターの集合を含む JOSE ヘッダーを作成する。
JWT は [JWS] または
[JWE] のいずれかの
仕様に適合しなければならない。表現中の空白は明示的に許可されており、
エンコード前に正規化を行う必要はない。
Jones, et al. Standards Track [Page 13]
RFC 7519 JSON Web Token (JWT) May 2015
4. JWT が JWS か JWE かに応じて、次の 2 つの場合がある：
* JWT が JWS の場合、メッセージを JWS ペイロードとして使用して
JWS を作成する。[JWS] で
規定されている JWS 作成のすべての手順に従わなければならない。
* それ以外で、JWT が JWE の場合、メッセージを JWE の平文として
使用して JWE を作成する。[JWE] で
規定されている JWE 作成のすべての手順に従わなければならない。
5. 入れ子になった署名または暗号化操作が行われる場合、メッセージを
JWS または JWE とし、手順 3 に戻って、その手順で作成される新しい
JOSE ヘッダーに「cty」（content type）の値として「JWT」を使用する。
6. それ以外の場合、結果として得られる JWT を JWS または JWE とする。
7.2. JWT の検証
JWT を検証する際には、次の手順を実行する。手順の順序は、手順間に
入力および出力の依存関係がない場合には重要ではない。列挙された手順の
いずれかが失敗した場合、JWT は拒否されなければならない。すなわち、
アプリケーションによって無効な入力として扱われる。
1. JWT に少なくとも 1 つのピリオド ('.') 文字が含まれていることを確認する。
2. エンコードされた JOSE ヘッダーを、JWT の最初のピリオド ('.')
文字より前の部分とする。
3. 改行、空白、その他の追加文字が使用されていないという制約に従って、
エンコードされた JOSE ヘッダーを Base64url デコードする。
4. 得られたオクテット列が、RFC 7159
[RFC7159] に
適合する完全に有効な JSON オブジェクトの UTF-8 エンコード表現である
ことを検証し、これを JOSE ヘッダーとする。
5. 得られた JOSE ヘッダーに、構文および意味の両方が理解され、かつ
サポートされているパラメーターおよび値、または理解されない場合に
無視されると規定されているもののみが含まれていることを検証する。
6. [JWE] のセクション 9 に
記載されているいずれかの方法を用いて、JWT が JWS か JWE かを判定する。
Jones, et al. Standards Track [Page 14]
RFC 7519 JSON Web Token (JWT) May 2015
7. JWT が JWS か JWE かに応じて、次の 2 つの場合がある：
* JWT が JWS の場合、[JWS] に
規定されている JWS 検証の手順に従う。メッセージを、JWS ペイロードを
Base64url デコードした結果とする。
* それ以外で、JWT が JWE の場合、[JWE] に
規定されている JWE 検証の手順に従う。メッセージを、得られた平文とする。
8. JOSE ヘッダーに「cty」（content type）の値として「JWT」が含まれている
場合、メッセージは、入れ子になった署名または暗号化操作の対象であった
JWT である。この場合、メッセージを JWT として使用し、手順 1 に戻る。
9. それ以外の場合、改行、空白、その他の追加文字が使用されていないという
制約に従って、メッセージを Base64url デコードする。
10. 得られたオクテット列が、RFC 7159
[RFC7159] に
適合する完全に有効な JSON オブジェクトの UTF-8 エンコード表現である
ことを検証し、これを JWT クレームセットとする。
最後に、どのアルゴリズムを使用できるかはアプリケーションの判断である点に
注意されたい。JWT を正常に検証できたとしても、JWT で使用されている
アルゴリズムがアプリケーションにとって受け入れ可能でない場合、アプリケーションは
JWT を拒否すべきである。
7.3. 文字列比較規則
JWT の処理では、既知の文字列を JSON オブジェクト内のメンバーや値と
比較する必要が必然的に生じる。例えば、アルゴリズムを確認する際には、
Unicode [UNICODE] の
文字列エンコーディング「alg」が、JOSE ヘッダー内のメンバー名と照合され、
一致するヘッダーパラメーター名が存在するかどうかが確認される。
メンバー名の比較を行うための JSON の規則は、
RFC 7159 のセクション 8.3
[RFC7159] に
記載されている。実行される文字列比較操作は等価および非等価のみであるため、
メンバー名とメンバー値のいずれを既知の文字列と比較する場合にも、
同じ規則を使用できる。
これらの比較規則は、メンバーの定義において、そのメンバー値に対して
異なる比較規則を使用することが明示的に指定されている場合を除き、
すべての JSON 文字列比較に使用されなければならない。本仕様では、
「typ」および「cty」のメンバー値のみが、これらの比較規則を使用しない。
Jones, et al. Standards Track [Page 15]
RFC 7519 JSON Web Token (JWT) May 2015
一部のアプリケーションでは、「iss」（issuer）クレーム値の一部として
DNS 名を含めるなど、大文字小文字を区別する値の中に大文字小文字を区別しない
情報が含まれることがある。そのような場合、複数の当事者が同じ値を生成して
比較できるようにするため、アプリケーションは、大文字小文字を区別しない部分を
小文字化するなど、表現に使用する正規の大文字小文字規則を定義する必要が
あるかもしれない。（ただし、他のすべての当事者が、生成側が出力した値を
そのまま消費し、独立に生成された値と比較しようとしないのであれば、
生成側が使用した大文字小文字は問題にならない。）
8. 実装要件
本セクションは、本仕様において実装が必須とされるアルゴリズムおよび
機能を定義する。本仕様を使用するアプリケーションは、使用する実装に対して
追加の要件を課すことができる。例えば、あるアプリケーションでは暗号化された
JWT やネストされた JWT のサポートを要求する一方、別のアプリケーションでは、
P-256 曲線および SHA-256 ハッシュアルゴリズム（「ES256」）を使用する
楕円曲線デジタル署名アルゴリズム（ECDSA）による JWT の署名を要求することがある。
JSON Web Algorithms [JWA] で規定されている
署名および MAC アルゴリズムのうち、適合する JWT 実装が必ず実装しなければ
ならないのは、HMAC SHA-256（「HS256」）および「none」のみである。
実装は、SHA-256 ハッシュアルゴリズムを用いた RSASSA-PKCS1-v1_5
（「RS256」）および、P-256 曲線と SHA-256 ハッシュアルゴリズムを用いた
ECDSA（「ES256」）もサポートすることが推奨される。他のアルゴリズムおよび
鍵長のサポートは任意である。
暗号化された JWT のサポートは任意である。実装が暗号化機能を提供する場合、
[JWA] で規定されている暗号化アルゴリズムのうち、
適合する実装が必ず実装しなければならないのは、2048 ビット鍵を用いた
RSAES-PKCS1-v1_5（「RSA1_5」）、128 ビットおよび 256 ビット鍵を用いた
AES 鍵ラップ（「A128KW」および「A256KW」）、ならびに AES-CBC と
HMAC SHA-2 を用いた複合認証付き暗号化アルゴリズム
（「A128CBC-HS256」および「A256CBC-HS512」）のみである。実装は、
コンテンツ暗号鍵をラップするための鍵合意に楕円曲線 Diffie-Hellman
Ephemeral Static（ECDH-ES）を使用する方式
（「ECDH-ES+A128KW」および「ECDH-ES+A256KW」）や、128 ビットおよび
256 ビット鍵を用いた Galois/Counter Mode（GCM）の AES
（「A128GCM」および「A256GCM」）もサポートすることが推奨される。
他のアルゴリズムおよび鍵長のサポートは任意である。
ネストされた JWT のサポートは任意である。
Jones, et al. Standards Track [Page 16]
RFC 7519 JSON Web Token (JWT) May 2015
9. コンテンツが JWT であることを宣言するための URI
本仕様は、URI（例えばメディアタイプではなく）を使用してコンテンツタイプを
宣言するアプリケーションが、参照されるコンテンツが JWT であることを示すために
使用する URN
「urn:ietf:params:oauth:token-type:jwt」を登録する。
10. IANA に関する考慮事項
10.1. JSON Web Token クレームレジストリ
本節は、JWT クレーム名のための IANA「JSON Web Token Claims」
レジストリを確立する。このレジストリは、クレーム名と、それを定義する
仕様への参照を記録する。本節では、セクション 4.1
で定義されているクレーム名を登録する。
値は、jwt-reg-review@ietf.org メーリングリスト上での 3 週間の
レビュー期間を経て、1 名以上の指定専門家の助言に基づき、
Specification Required [RFC5226] の
基準で登録される。ただし、公開前に値を割り当てられるようにするため、
指定専門家は、当該仕様が公開されることに十分な確信を持った時点で、
登録を承認してもよい。
レビューのためにメーリングリストへ送付される登録要求は、適切な件名
（例:「Request to register claim: example」）を使用すべきである。
レビュー期間内に、指定専門家は登録要求を承認または拒否し、その決定を
レビュー用メーリングリストおよび IANA に通知する。拒否の場合は、説明を
含め、該当する場合には要求を成功させるための提案を含めるべきである。
21 日を超える期間にわたり未決定の登録要求は、解決のために
IESG（iesg@ietf.org メーリングリストを使用）に付託することができる。
指定専門家が適用すべき基準には、提案された登録が既存の機能を重複して
いないか、一般的な適用性があるか、単一のアプリケーションにのみ有用
であるか、また登録記述が明確であるかを判断することが含まれる。
IANA は、指定専門家からのレジストリ更新のみを受け付けなければならず、
登録に関するすべての要求をレビュー用メーリングリストに誘導すべきである。
登録決定に関する幅広い見識に基づくレビューを可能にするため、本仕様を
使用する異なるアプリケーションの観点を代表できる複数の指定専門家を
任命することが推奨される。登録決定が特定の専門家にとって利益相反を
生じさせると認識され得る場合、その専門家は他の専門家の判断に委ねる
べきである。
Jones, et al. Standards Track [Page 17]
RFC 7519 JSON Web Token (JWT) May 2015
10.1.1. 登録テンプレート
Claim Name:
要求される名前（例:「iss」）。本仕様の中核的な目標の 1 つは、
生成される表現をコンパクトにすることであるため、やむを得ない理由が
ない限り、名前は短いこと、すなわち 8 文字を超えないことが
RECOMMENDED される。この名前は大文字と小文字を区別する。
指定専門家が例外を認めるべき十分な理由があると判断しない限り、
大文字小文字を区別しない比較において、他の登録済みの名前と一致してはならない。
Claim Description:
クレームの簡潔な説明（例:「Issuer」）。
Change Controller:
Standards Track RFC の場合は「IESG」を記載する。それ以外の場合は、
責任主体の名称を記載する。他の詳細（例: 郵送先住所、電子メール
アドレス、ホームページ URI）を含めてもよい。
Specification Document(s):
当該パラメータを規定する文書への参照。可能であれば、文書の写しを
取得するために使用できる URI を含めることが望ましい。関連する
セクションの記載を含めてもよいが、必須ではない。
10.1.2. 初期レジストリ内容
o Claim Name: "iss"
o Claim Description: Issuer
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.1
o Claim Name: "sub"
o Claim Description: Subject
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.2
o Claim Name: "aud"
o Claim Description: Audience
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.3
Jones, et al. Standards Track [Page 18]
RFC 7519 JSON Web Token (JWT) May 2015
o Claim Name: "exp"
o Claim Description: Expiration Time
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.4
o Claim Name: "nbf"
o Claim Description: Not Before
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.5
o Claim Name: "iat"
o Claim Description: Issued At
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.6
o Claim Name: "jti"
o Claim Description: JWT ID
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.7
10.2. サブネームスペース登録:
urn:ietf:params:oauth:token-type:jwt
10.2.1. レジストリ内容
本節は、「OAuth のための IETF URN サブネームスペース」
[RFC6755] により確立された
IANA「OAuth URI」レジストリに値「token-type:jwt」を登録する。
これは、内容が JWT であることを示すために使用できる。
o URN: urn:ietf:params:oauth:token-type:jwt
o Common Name: JSON Web Token (JWT) トークン種別
o Change Controller: IESG
o Specification Document(s): RFC 7519
Jones, et al. Standards Track [Page 19]
RFC 7519 JSON Web Token (JWT) May 2015
10.3. メディア型登録
10.3.1. レジストリ内容
本節は、「Media Types」レジストリ [IANA.MediaTypes] に、
RFC 6838 [RFC6838] に記載された方法に従って、
「application/jwt」メディア型 [RFC2046] を登録する。
これは、内容が JWT であることを示すために使用できる。
o Type name: application
o Subtype name: jwt
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; JWT の値は、
base64url でエンコードされた一連の値（空文字列であるものを含む場合がある）を
ピリオド（'.'）文字で区切ったものとして符号化される。
o Security considerations: RFC 7519 の
Security Considerations セクションを参照
o Interoperability considerations: n/a
o Published specification: RFC 7519
o Applications that use this media type: OpenID Connect、Mozilla
Persona、Salesforce、Google、Android、Windows Azure、Amazon Web
Services、その他多数
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: なし
o Author: Michael B. Jones, mbj@microsoft.com
o Change controller: IESG
o Provisional registration? No
10.4. ヘッダパラメータ名登録
本節は、セクション 4.1 で定義されている特定のクレーム名を、
JWS により確立された IANA
「JSON Web Signature and Encryption Header Parameters」レジストリに登録する。
これらは、セクション 5.3 に従って、JWE において
ヘッダパラメータとして複製されたクレームで使用される。
Jones, et al. Standards Track [Page 20]
RFC 7519 JSON Web Token (JWT) May 2015
10.4.1. レジストリ内容
o Header Parameter Name: "iss"
o Header Parameter Description: Issuer
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.1
o Header Parameter Name: "sub"
o Header Parameter Description: Subject
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.2
o Header Parameter Name: "aud"
o Header Parameter Description: Audience
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 のセクション 4.1.3
11. セキュリティに関する考慮事項
あらゆる暗号アプリケーションに関連するすべてのセキュリティ問題は、
JWT/JWS/JWE/JWK エージェントによって対処されなければならない。
これらの問題には、ユーザの非対称秘密鍵および対称秘密鍵を保護すること、
ならびに各種攻撃に対する対策を講じることが含まれる。
JWS 仕様におけるすべてのセキュリティ考慮事項は JWT にも適用され、
暗号化が使用される場合には JWE のセキュリティ考慮事項も同様に適用される。
特に、[JWS] の
セクション 10.12（「JSON セキュリティ考慮事項」）および
10.13（「Unicode 比較セキュリティ考慮事項」）は、JOSE ヘッダに適用されるのと
同じ方法で、JWT クレームセットにも等しく適用される。
11.1. 信頼判断
JWT の内容は、暗号学的に保護され、かつ信頼判断に必要な文脈に結び付け
られていない限り、信頼判断において依拠することはできない。
特に、JWT の署名および／または暗号化に使用される鍵は、通常、JWT の
発行者として識別される当事者の管理下にあることが検証可能である必要がある。
11.2. 署名および暗号化の順序
構文上は、ネストされた JWT に対する署名および暗号化の操作は任意の順序で
適用できるが、署名と暗号化の両方が必要な場合、通常は生成者はまず
メッセージに署名し、その後に結果を暗号化すべきである。
Jones, et al. Standards Track [Page 21]
RFC 7519 JSON Web Token (JWT) May 2015
これにより、署名が除去され、暗号化されたメッセージのみが残るような
攻撃を防止できるとともに、署名者のプライバシーも提供される。
さらに、多くの法域では、暗号化されたテキストに対する署名は有効と
見なされていない。
署名および暗号化の操作順序に関連する潜在的なセキュリティ上の懸念は、
既に基盤となる JWS および JWE の仕様において対処されていることに注意すること。
特に、JWE は認証付き暗号アルゴリズムの使用のみをサポートしているため、
多くの文脈で適用される、暗号化後に署名する必要性に関する暗号学的な懸念は、
本仕様には当てはまらない。
12. プライバシーに関する考慮事項
JWT にはプライバシー上機微な情報が含まれる場合がある。その場合、
意図しない当事者への情報漏えいを防止するための措置を講じなければならない。
その一つの方法は、暗号化された JWT を使用し、受信者を認証することである。
別の方法は、暗号化されていないプライバシー上機微な情報を含む JWT が、
Transport Layer Security (TLS) など、エンドポイント認証をサポートする
暗号化を利用するプロトコルのみを用いて送信されるようにすることである。
JWT からプライバシー上機微な情報を省略することは、プライバシー問題を
最小化する最も簡単な方法である。
13. 参考文献
13.1. 規範的参照
[ECMAScript]
Ecma International, 「ECMAScript Language Specification,
第 5.1 版」, ECMA Standard 262, 2011 年 6 月,
<http://www.ecma-international.org/ecma-262/5.1/
ECMA-262.pdf>.
[IANA.MediaTypes]
IANA, 「Media Types」,
<http://www.iana.org/assignments/media-types>.
[JWA] Jones, M., 「JSON Web Algorithms (JWA)」, RFC 7518,
DOI 10.17487/RFC7518, 2015 年 5 月,
<http://www.rfc-editor.org/info/rfc7518>.
[JWE] Jones, M. および J. Hildebrand, 「JSON Web Encryption (JWE)」,
RFC 7516, DOI 10.17487/RFC7516, 2015 年 5 月,
<http://www.rfc-editor.org/info/rfc7516>.
Jones, et al. Standards Track [Page 22]
RFC 7519 JSON Web Token (JWT) May 2015
[JWS] Jones, M., Bradley, J. および N. Sakimura,
「JSON Web Signature (JWS)」, RFC 7515,
DOI 10.17487/RFC, 2015 年 5 月,
<http://www.rfc-editor.org/info/rfc7515>.
[RFC20] Cerf, V., 「ASCII format for Network Interchange」, STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969 年 10 月,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2046] Freed, N. および N. Borenstein,
「Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types」,
RFC 2046, DOI 10.17487/RFC2046, 1996 年 11 月,
<http://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S.,
「Key words for use in RFCs to Indicate Requirement Levels」,
BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997 年 3 月,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R. および L. Masinter,
「Uniform Resource Identifier (URI): Generic Syntax」, STD 66,
RFC 3986, DOI 10.17487/RFC3986, 2005 年 1 月,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4949] Shirey, R.,
「Internet Security Glossary, Version 2」,
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007 年 8 月,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC7159] Bray, T., 編,
「The JavaScript Object Notation (JSON) Data Interchange Format」,
RFC 7159, DOI 10.17487/RFC7159, 2014 年 3 月,
<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] The Unicode Consortium,
「The Unicode Standard」,
<http://www.unicode.org/versions/latest/>.
13.2. 参考的参照
[CanvasApp]
Facebook, 「Canvas Applications」, 2010 年,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JSS] Bradley, J. および N. Sakimura（編）,
「JSON Simple Sign」,
2010 年 9 月,
<http://jsonenc.info/jss/1.0/>.
Jones, et al. Standards Track [Page 23]
RFC 7519 JSON Web Token (JWT) May 2015
[MagicSignatures]
Panzer, J.（編）, Laurie, B. および D. Balfanz,
「Magic Signatures」,
2011 年 1 月,
<http://salmon-protocol.googlecode.com/svn/
trunk/draft-panzer-magicsig-01.html>.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R. および E. Maler,
「OASIS Security Assertion Markup Language (SAML) V2.0
のためのアサーションおよびプロトコル」,
OASIS Standard saml-core-2.0-os, 2005 年 3 月,
<http://docs.oasis-open.org/security/saml/v2.0/
saml-core-2.0-os.pdf>.
[POSIX.1] IEEE,
「The Open Group Base Specifications Issue 7」,
IEEE Std 1003.1, 2013 年版, 2013 年,
<http://pubs.opengroup.org/onlinepubs/9699919799/
basedefs/V1_chap04.html#tag_04_15>.
[RFC3275] Eastlake 3rd, D., Reagle, J. および D. Solo,
「(Extensible Markup Language) XML-Signature Syntax and Processing」,
RFC 3275, DOI 10.17487/RFC3275, 2002 年 3 月,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC3339] Klyne, G. および C. Newman,
「Date and Time on the Internet: Timestamps」,
RFC 3339, DOI 10.17487/RFC3339, 2002 年 7 月,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC4122] Leach, P., Mealling, M. および R. Salz,
「A Universally Unique IDentifier (UUID) URN Namespace」,
RFC 4122, DOI 10.17487/RFC4122, 2005 年 7 月,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. および H. Alvestrand,
「Guidelines for Writing an IANA Considerations Section in RFCs」,
BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008 年 5 月,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6755] Campbell, B. および H. Tschofenig,
「An IETF URN Sub-Namespace for OAuth」,
RFC 6755, DOI 10.17487/RFC6755, 2012 年 10 月,
<http://www.rfc-editor.org/info/rfc6755>.
[RFC6838] Freed, N., Klensin, J. および T. Hansen,
「Media Type Specifications and Registration Procedures」,
BCP 13, RFC 6838,
DOI 10.17487/RFC6838, 2013 年 1 月,
<http://www.rfc-editor.org/info/rfc6838>.
Jones, et al. Standards Track [Page 24]
RFC 7519 JSON Web Token (JWT) May 2015
[SWT] Hardt, D. および Y. Goland,
「Simple Web Token (SWT)」,
Version 0.9.5.1, 2009 年 11 月,
<http://msdn.microsoft.com/en-us/
library/windowsazure/hh781551.aspx>.
[W3C.CR-xml11-20060816]
Cowan, J.,
「Extensible Markup Language (XML) 1.1（第 2 版）」,
World Wide Web Consortium Recommendation
REC-xml11-20060816, 2006 年 8 月,
<http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml-c14n-20010315]
Boyer, J.,
「Canonical XML Version 1.0」,
World Wide Web Consortium Recommendation
REC-xml-c14n-20010315, 2001 年 3 月,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
Jones, et al. Standards Track [Page 25]
RFC 7519 JSON Web Token (JWT) May 2015
付録 A. JWT の例
本節では JWT の例を示す。その他の JWT の例については、本書の
セクション 6.1 および [JWS] の付録 A.1〜A.3 を参照されたい。
A.1. 暗号化された JWT の例
この例では、セクション 3.1 で使用されているものと同一のクレームを、
RSAES-PKCS1-v1_5 および AES_128_CBC_HMAC_SHA_256 を用いて受信者向けに暗号化する。
以下の例の JOSE ヘッダーは、次のことを宣言している。
o コンテンツ暗号化鍵は、RSAES-PKCS1-v1_5 アルゴリズムを使用して
受信者向けに暗号化され、JWE Encrypted Key が生成される。
o 平文に対して AES_128_CBC_HMAC_SHA_256 アルゴリズムを用いた
認証付き暗号化が行われ、JWE Ciphertext および
JWE Authentication Tag が生成される。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
セクション 3.1 の JWT Claims Set の UTF-8 表現のオクテット列を
平文値として使用する点を除けば、この JWT の計算は、使用される鍵を含め、
[JWE] の付録 A.2 における
JWE の計算と同一である。
本例における最終結果（表示目的のみで改行を含む）は次のとおりである。
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ.
AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA
A.2. ネストされた JWT の例
この例は、JWT を JWE または JWS のペイロードとして使用し、
ネストされた JWT を作成する方法を示す。この場合、JWT Claims Set は
まず署名され、その後に暗号化される。
Jones, et al. Standards Track [Page 26]
RFC 7519 JSON Web Token (JWT) May 2015
内部の署名済み JWT は、[JWS] の付録 A.2 の例と同一である。
したがって、その計算はここでは繰り返さない。本例では次に、この内部 JWT を
RSAES-PKCS1-v1_5 および AES_128_CBC_HMAC_SHA_256 を用いて受信者向けに暗号化する。
以下の例の JOSE ヘッダーは、次のことを宣言している。
o コンテンツ暗号化鍵は、RSAES-PKCS1-v1_5 アルゴリズムを使用して
受信者向けに暗号化され、JWE Encrypted Key が生成される。
o 平文に対して AES_128_CBC_HMAC_SHA_256 アルゴリズムを用いた
認証付き暗号化が行われ、JWE Ciphertext および
JWE Authentication Tag が生成される。
o 平文自体が JWT である。
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
JOSE ヘッダーの UTF-8 表現のオクテット列を base64url エンコードすると、
次のエンコード済み JOSE ヘッダー値が得られる。
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
この JWT の計算は、[JWE] の付録 A.2 における
JWE の計算と同一であり、異なる点は、使用される JOSE ヘッダー、平文、
JWE Initialization Vector、およびコンテンツ暗号化鍵の値である
（RSA 鍵は同一のものが使用される）。
使用される平文は、[JWS] の付録 A.2.1 の末尾にある JWT の
ASCII [RFC20] 表現の
オクテット列であり（すべての空白および改行は削除されている）、
458 オクテットのシーケンスである。
使用される JWE Initialization Vector の値（JSON 配列表記）は次のとおりである。
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
50]
本例では、以下に示す base64url エンコードされた値で表現される
コンテンツ暗号化鍵が使用される。
GawgguFyGrWKav7AX4VKUg
Jones, et al. Standards Track [Page 27]
RFC 7519 JSON Web Token (JWT) May 2015
このネストされた JWT の最終結果（表示目的のみで改行を含む）は次のとおりである。
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldU
In0.
g_hEwksO1Ax8Qn7HoN-BVeBoa8FXe0kpyk_XdcSmxvcM5_P296JXXtoHISr_DD_M
qewaQSH4dZOQHoUgKLeFly-9RI11TG-_Ge1bZFazBPwKC5lJ6OLANLMd0QSL4fYE
b9ERe-epKYE3xb2jfY1AltHqBO-PM6j23Guj2yDKnFv6WO72tteVzm_2n17SBFvh
DuR9a2nHTE67pe0XGBUS_TK7ecA-iVq5COeVdJR4U4VZGGlxRGPLRHvolVLEHx6D
YyLpw30Ay9R6d68YCLi9FYTq3hIXPK_-dmPlOUlKvPr1GgJzRoeC9G5qCvdcHWsq
JGTO_z3Wfo5zsqwkxruxwA.
UmVkbW9uZCBXQSA5ODA1Mg.
VwHERHPvCNcHHpTjkoigx3_ExK0Qc71RMEParpatm0X_qpg-w8kozSjfNIPPXiTB
BLXR65CIPkFqz4l1Ae9w_uowKiwyi9acgVztAi-pSL8GQSXnaamh9kX1mdh3M_TT
-FZGQFQsFhu0Z72gJKGdfGE-OE7hS1zuBD5oEUfk0Dmb0VzWEzpxxiSSBbBAzP10
l56pPfAtrjEYw-7ygeMkwBl6Z_mLS6w6xUgKlvW6ULmkV-uLC4FUiyKECK4e3WZY
Kw1bpgIqGYsw2v_grHjszJZ-_I5uM-9RA8ycX9KqPRp9gc6pXmoU_-27ATs9XCvr
ZXUtK2902AUzqpeEUJYjWWxSNsS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb2
8Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe_nNJgNliWtWpJ_ebuOpE
l8jdhehdccnRMIwAmU1n7SPkmhIl1HlSOpvcvDfhUN5wuqU955vOBvfkBOh5A11U
zBuo2WlgZ6hYi9-e3w29bR0C2-pp3jbqxEDw3iWaf2dc5b-LnR0FEYXvI_tYk5rd
_J9N0mg0tQ6RbpxNEMNoA9QWk5lgdPvbh9BaO195abQ.
AVO9iT5AV4CzvDJCdhSFlQ
付録 B. JWT と SAML アサーションとの関係
Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] は、JWT でサポートされているものよりも
高い表現力と多くのセキュリティオプションを備えたセキュリティトークンを
作成するための標準を提供する。しかし、この柔軟性および表現力の代償として、
サイズと複雑性の両方が増大する。SAML では XML
[W3C.CR-xml11-20060816] および
XML デジタル署名 (DSIG) [RFC3275] を使用するため、
SAML アサーションのサイズが大きくなる。また、XML、特に
XML 正規化 [W3C.REC-xml-c14n-20010315] の使用は、
その複雑性に寄与する。
JWT は、HTTP ヘッダーや URI のクエリ引数に収まる程度に小さい、
単純なセキュリティトークン形式を提供することを目的としている。
これは、SAML よりもはるかに単純なトークンモデルを採用し、
JSON [RFC7159] オブジェクトの
エンコード構文を使用することで実現されている。また、JWT は、
メッセージ認証コード (MAC) や、XML DSIG よりも小さく（かつ柔軟性の低い）
形式を用いたデジタル署名によるトークンの保護もサポートしている。
したがって、JWT は SAML アサーションが行うことの一部は実行できるが、
SAML アサーションの完全な代替として意図されているわけではなく、
実装の容易さやコンパクトさが考慮事項となる場合に使用される
トークン形式として位置付けられている。
Jones, et al. Standards Track [Page 28]
RFC 7519 JSON Web Token (JWT) May 2015
SAML アサーションは、常に、ある主体についてエンティティが行う
記述（ステートメント）である。JWT も同様の方法で使用されることが多く、
記述を行うエンティティは "iss"（issuer）クレームによって表され、
主体は "sub"（subject）クレームによって表される。
ただし、これらのクレームは任意であるため、JWT 形式の他の用途も許容される。
付録 C. JWT と Simple Web Token (SWT) との関係
JWT と SWT [SWT] は、いずれもその中核において、
アプリケーション間でクレームの集合を伝達することを可能にする。
SWT では、クレーム名およびクレーム値の双方が文字列である。
JWT では、クレーム名は文字列であるが、クレーム値は任意の JSON 型を
取り得る。いずれのトークン型も、その内容に対する暗号学的保護を提供する。
SWT は HMAC SHA-256 を使用し、JWT は署名、MAC、暗号化アルゴリズムを含む
複数のアルゴリズムから選択可能である。
謝辞
著者らは、JWT の設計が、SWT [SWT] の設計および簡潔性、
ならびに Dick Hardt が OpenID コミュニティ内で議論した
JSON トークンに関するアイデアから意図的に影響を受けていることを認める。
JSON コンテンツの署名に関する解決策は、以前に Magic Signatures
[MagicSignatures]、JSON Simple Sign
[JSS]、および Canvas
Applications [CanvasApp] によって検討されており、
これらすべてが本書に影響を与えている。
本仕様は OAuth ワーキンググループの成果であり、
数十名の積極的かつ献身的な参加者が含まれている。
特に、以下の個人が本仕様に影響を与えたアイデア、
フィードバック、および文言の提供に貢献した。
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Edmund Jay, Warren Kumari, Ben Laurie, Barry
Leiba, Ted Lemon, James Manger, Prateek Mishra, Kathleen Moriarty,
Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David
Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig,
Sean Turner, and Tom Yu.
Hannes Tschofenig および Derek Atkins は OAuth ワーキンググループの
議長を務め、Sean Turner、Stephen Farrell、Kathleen Moriarty は、
本仕様の策定期間中に Security Area Director を務めた。
Jones, et al. Standards Track [Page 29]
RFC 7519 JSON Web Token (JWT) May 2015
著者の連絡先
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Jones, et al. Standards Track [Page 30]