JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-11

Abstract

JSON Web Token (JWT) は2者間でやりとりされるコンパクトで URL-safe なクレームの表現方法である. JWT に含まれるクレームは JavaScript Object Notation (JSON) オブジェクトとしてエンコードされ, JSON Web Signature (JWS) のペイロードや JSON Web Encryption (JWE) の平文として利用される. JWS や JWE とともに用いることで, クレームに対してデジタル署名や MAC を付与と暗号化の両方を行うことが可能となる.

JWT の推奨される発音は, 英単語の "jot" と同じである.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 30, 2014.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

1.  はじめに
    1.1.  要求記法および規則
2.  用語集
3.  JSON Web Token (JWT) 概要
    3.1.  JWTの例
4.  JWTクレーム
    4.1.  予約済クレーム名
        4.1.1.  "iss" (Issuer) クレーム
        4.1.2.  "sub" (Subject) クレーム
        4.1.3.  "aud" (Audience) クレーム
        4.1.4.  "exp" (Expiration Time) クレーム
        4.1.5.  "nbf" (Not Before) クレーム
        4.1.6.  "iat" (Issued At) クレーム
        4.1.7.  "jti" (JWT ID) クレーム
        4.1.8.  "typ" (Type) クレーム
    4.2.  パブリッククレーム名
    4.3.  プライベートクレーム名
5.  JWT ヘッダ
    5.1.  "typ" (Type) ヘッダ・パラメータ
    5.2.  "cty" (Content Type) ヘッダ・パラメータ
    5.3.  ヘッダ・パラメータとしてクレームを複製する
6.  プレーンテキストJWT
    6.1.  プレーンテキストJWTの例
7.  JWTを作成および検証するためのルール
    7.1.  文字列の比較規則
8.  暗号化アルゴリズム
9.  IANA Considerations
    9.1.  JSON Web トークンクレームレジストリ
        9.1.1.  レジストリテンプレート
        9.1.2.  初期レジストリコンテンツ
    9.2.  Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt
        9.2.1.  レジストリコンテンツ
    9.3.  JSON Web Signature and Encryption Type Values Registration
        9.3.1.  レジストリコンテンツ
    9.4.  Media Type Registration
        9.4.1.  レジストリコンテンツ
    9.5.  JWEヘッダパラメータの登録
        9.5.1.  レジストリコンテンツ
10.  Security Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
    11.3.  翻訳プロジェクト
Appendix A.  JWT Examples
    A.1.  暗号化されたJWTの例
    A.2.  入れ子 JWT の例
Appendix B.  JWTとSAMLアサーションの関係
Appendix C.  JWTとシンプル・ウェブ・トークン (SWT) の関係
Appendix D.  Acknowledgements
Appendix E.  Document History
Appendix F.  翻訳者
§  Authors' Addresses

1.  はじめに

JSON Web Token(JWT)はHTTP認証ヘッダやURIクエリパラメータなどスペースに制約のある環境を意図したコンパクトな表現形式である. JWTは, クレームをJSON Web Signature(JWS)[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)のペイロードや JSON Web Encryption(JWE)[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)のプレーンテキストとなるJavaScript Object Notation(JSON)[RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.)オブジェクトとしてエンコードし, クレームに対するデジタル署名やMACと暗号化の両方を可能にする. JWTは常にJWSのコンパクトシリアライゼーションまたはJWS Compact Serializationを利用して表現される.

JWTの推奨される発音は, 英単語の"jot"と同じである.

1.1.  要求記法および規則

本文書で用いられる各キーワード「MUST (しなければならない) 」, 「MUST NOT (してはならない) 」, 「REQUIRED (必須である) 」, 「SHALL (するものとする) 」, 「SHALL NOT (しないものとする) 」, 「SHOULD (すべきである) 」, 「SHOULD NOT (すべきではない) 」, 「RECOMMENDED (推奨される) 」, 「MAY (してもよい) 」, 「OPTIONAL (任意である) 」は Key words for use in RFCs to Indicate Requirement Levels[RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)で述べられている通りに解釈されるべきものである.

2.  用語集

JSON Web Token (JWT)

クレームのセットをJSONオブジェクトとして文字列表現にしてJWSやJWEにエンコードすることで, クレームに対するデジタル署名やMACと暗号化の両方が可能になる.

base64urlエンコーディング

RFC 4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648]の節 5で説明されているURLおよびファイル名として安全なBase64エンコーディングであり, 節 3.2で許可されているように (URLとして安全ではない) '=' パディング文字が省略されている. (パディングなしのbase64urlエンコーディングの導入についての注意事項は[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)のAppendix Cを参照のこと)

JSONテキストオブジェクト

UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.)エンコード済テキストでありJSONオブジェクトを表現する. JSONオブジェクトの構文は[RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.)の節 2.2で定義されている.

JWTヘッダ

JWTに適用される暗号化オペレーションについて記述しているJSONテキストオブジェクト. JWTがデジタル署名もしくはMACされている場合, JWTヘッダはJWSヘッダである. JWTが暗号化されている場合, JWTヘッダはJWEヘッダである.

ヘッダ・パラメータ名

JWTヘッダのメンバの名前.

ヘッダ・パラメータ値

JWTヘッダのメンバの値.

JWTクレームセット

JWTによって伝搬されるクレームを含むJSONテキストオブジェクト.

クレーム

ある主体に関するひとまとまりの情報. クレームはクレーム名とクレーム値から構成される名前と値のペアで表現される.

クレーム名

クレーム表現の中の名前の部分. クレーム名は常に文字列である.

クレーム値

クレーム表現の中の値の部分. クレーム値は任意のJSON値であり得る.

エンコード済JWTヘッダ

JWTヘッダをbase64urlエンコードしたもの.

入れ子にされたJWT

署名と暗号化の両方が適用されたJWTに入れ子にされているJWT. 入れ子にされたJWTでは, JWTは内包されたJWS/JWEのペイロード/平文の値として利用される.

平文のJWT

完全性保護も暗号化もされていないクレームからなるJWT.

耐衝突性を持つ名前空間

他の名前空間とほとんど衝突しない様に割り当てられた名前空間. 例えば, 耐衝突性は名前空間の一部の管理を移譲したり, 耐衝突性を持つ名前の割り付け機能の利用によって達成することが出来る. 耐衝突性を持つ名前空間の例は次のものを含んでいる. ドメイン名, ITU-T X.600とX.670推奨シリーズで定義されているオブジェクト識別子 (OID), ユニバーサル・ユニーク識別子 (UUID)[RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.). 管理を移譲された名前空間を利用する場合, 名前を定義する人は定義するための名前空間の一部を管理していることを保証するために合理的な予防措置を講ずる必要がある.

StringOrURI

任意の文字列を使っても良い一方で, ":"を含むどのような値もURI[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)でなければならない, という追加の要求があるJSON文字列の値. StringOrURIの値には変形や正規化が適用されず, 大文字・小文字を区別する文字列として比較される.

IntDate

1970-01-01T0:0:0Z UTCから指定されたUTCの日付/時刻まで秒の数を表わすJSON数値. 日付/時刻に関する詳細はRFC 3339 (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339]の全般と, 特にUTCを参照すること.

3.  JSON Web Token (JWT) 概要

JWTは, JWSとJWE構造の両方の中にエンコードされるJSONオブジェクトとしてクレームのセットを表す. このJSONオブジェクトはJWTクレーム・セットである. RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]の節 2.2の通り, JSONオブジェクトは0以上の名前/値のペア(もしくはメンバ)から構成され, その名前は文字列であり値は任意のJSON値である. これらのメンバはJWTによって表現されるクレームである.

JWTクレームセットの中のメンバ名はクレーム名として参照される. 対応する値はクレーム値として参照される.

JWTヘッダの内容は, JWTクレーム・セットに適用される暗号化オペレーションについて記述している. JWTヘッダがJWSヘッダである場合, そのJWTクレーム・セットをJWSペイロードとしたJWSとして表現され, クレームにはデジタル署名もしくはMACが付与される. JWTヘッダがJWEヘッダである場合, そのJWTはJWTクレーム・セットをJWEの平文入力としたJWEとして表現され, クレームは暗号化される. JWTはJWEやJWS構造の中に含まれ入れ子のJWTを構成することができ, 単一のJWTに対して署名や暗号化を繰り返し実施することができる.

JWTはピリオド('.')によって連結された一連のURL-safeな文字列として表現される. それぞれのパートはbase64urlでエンコード済の値で構成される. JWTの中のパートの数は, JWSコンパクト・シリアライゼーション表現のJWSもしくはJWS Compact Serialization表現のJWEのどちらとして利用されているかに依存する.

3.1.  JWTの例

下記はJWTヘッダの例である. このヘッダは, エンコード済オブジェクトがJSON Web Token (JWT) であり, そのJWTにはHMAC SHA-256アルゴリズムを使ってMACが付与されていることを表している.

  {"typ":"JWT",
   "alg":"HS256"}

JWTヘッダのUTF-8表現のオクテットをbase64urlエンコードすると, このエンコード済JWSヘッダの値が作られ, それはエンコードされたJWTヘッダとして使われる.

  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]

JWSペイロードをbase64urlエンコードすると, このエンコード済JWSペイロードが作り出せる. (改行は掲載上の都合による)

  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
  9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

エンコード済のJWSヘッダとエンコード済のJWSペイロードをHMAC SHA-256アルゴリズムで署名し, [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)に指定された形で署名をbase64urlエンコードすると, このエンコード済JWS署名を作り出せる.

  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

これら3つのパートをこの順に各パートの間をピリオド('.')で連結すると完全なJWTが作り出せる. (表示上の都合で改行を含む)

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

この計算についての詳細は[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)のAppendix A.1に記載されている. 暗号化されたJWTについてはAppendix A.1 (暗号化されたJWTの例)を参照のこと.

4.  JWTクレーム

JWT クレームセットは JSON オブジェクトであり, それぞれのメンバは JWT として送られるクレームである. JWT クレームセット内のクレーム名は一意でなければならない（MUST）. 受信者はクレーム名が重複した JWT を拒否するか, あるいは JSON パーサーを ECMAScript 5.1 [ECMAScript] (Ecma International, “ECMAScript Language Specification, 5.1 Edition,” June 2011.) の節 15.12 (JSON オブジェクト) で定義されているとおり語彙的に最後の重複メンバ名だけを返却する JSON パーサを利用しなければならない（MUST）.

有効な JWT が含まねばならないクレームはコンテキストに依存するため, 本仕様の範囲外とする. JWT を実装するアプリケーションごとに, クレームを理解する方法と処理方法について定めることになる. アプリケーションがこのような要件を定めていないクレームについては, それが理解不可能な場合には無視すること (SHOULD).

JWT クレーム名には予約済クレーム名とパブリッククレーム名, プライベートクレーム名の3つのクラスが定義されている.

4.1.  予約済クレーム名

次のクレーム名は予約済である. 以下に定義されているクレームは, いずれも必須とされることを想定されてはいないが, 有用で相互運用性のあるクレームとなることを期待して提供されている. JWT は表現がコンパクトになることを目的としているため, すべてのクレーム名は短くなっている. 追加の予約済クレーム名は Section 9.1 (JSON Web トークンクレームレジストリ) の IANA JSON Web トークンクレームレジストリにしたがって定義することができる.

4.1.1.  "iss" (Issuer) クレーム

iss（issuer）クレームは JWT の発行者の識別子である. このクレームの処理は一般的にアプリケーション固有である. iss の値は文字列あるいは StringOrURI 値である. このクレームの使用は任意である（OPTIONAL）.

4.1.2.  "sub" (Subject) クレーム

sub（subject）クレームは JWT の主語となる主体の識別子である. JWT に含まれるクレームは, 通常 subject について述べたものである. このクレームの処理は一般的にアプリケーション固有である. sub の値は文字列あるいは StringOrURI 値である. このクレームの使用は任意であるOPTIONAL）.

4.1.3.  "aud" (Audience) クレーム

aud（audience）クレームは JWT を利用することが想定された主体の識別子一覧である. JWT を処理するために意図されたそれぞれの対象は, オーディエンスクレームの値に自身の識別子が含まれていることを確認し, aud に自身の識別子が含まれない場合はその JWT の処理を拒否しなければならない（MUST）. 一般的な場合において, aud クレームの値は文字列あるいは StringOrURI 値の配列である. JWT が単一のオーディエンスから構成される場合に限って, aud の値は単一の文字列あるいは StringOrURI 値でもよい（MAY）. オーディエンス値の解釈は一般的にアプリケーション固有である. このクレームの使用は任意である（OPTIONAL）.

4.1.4.  "exp" (Expiration Time) クレーム

exp (expiration time) クレームは, JWT の有効期限を示す. これ以降はその JWT を処理してはならない (MUST NOT). exp クレームを処理する際には, exp が現在時刻以前でないことを確認しなければならない (MUST). 実装者はクロック・キューを考慮していくらかの小さな 余地 (通常は数分以上はない) を与えてもよい (MAY). このクレームの値は IntDate 値でなければならない(MUST). このクレームの使用は任意である (OPTIONAL).

4.1.5.  "nbf" (Not Before) クレーム

nbf (not before) クレームは, JWT が有効になる日時を示す. これ以前にその JWT を処理してはならない (MUST NOT). nbf クレームを処理する際には, exp が現在時刻以前であることを確認しなければならない (MUST). 実装者はクロック・キューを考慮していくらかの小さな余地 (通常は数分以上はない) を与えてもよい (MAY). その値は IntDate 値でなければならない (MUST). このクレームの使用は任意である (OPTIONAL).

4.1.6.  "iat" (Issued At) クレーム

iat (issued at) クレームは, JWT を発行した時刻を示す. このクレームは JWT の発行されてからの経過時間を求める際に利用可能である. その値は IntDate 値でなければならない (MUST). このクレームの使用は任意である (OPTIONAL).

4.1.7.  "jti" (JWT ID) クレーム

jti (JWT ID) クレームは, JWT のための一意な識別子を提供する. その識別子の値は, 重複確率が無視できるほど十分低いことを保証できる方法で割り当てられなければならない (MUST). jti クレームは, JWT がリプレイされることを防ぐことに利用することができる. jti の値は大文字と小文字を区別する文字列である. このクレームの使用は任意である (OPTIONAL).

4.1.8.  "typ" (Type) クレーム

typ (type) クレームは, アプリケーションにとって有用なコンテキストにおいて, アプリケーション固有の方法で, JWT クレームセットのコンテンツのタイプを宣言するために利用できる (MAY). typ の値は, 大文字と小文字を区別する文字列である. このクレームの使用は任意である (OPTIONAL).

typ クレーム値には, typ ヘッダパラメータと同じ値空間および同じ規則が適用される.

4.2.  パブリッククレーム名

クレーム名は JWT の利用者によって自由に定義することができる. しかしながら, 衝突をさけるために, いくつかのクレーム名は IANA JSON Web トークンクレームレジストリ Section 9.1 (JSON Web トークンクレームレジストリ) に登録するか, 耐衝突性を持つ名前空間を含むパブリック名にすべきである (SHOULD). それぞれの場合において, 名前あるいは値の定義者は, クレーム名を定義するために用いる名前空間の一部が自身の管理下にあることを保証できるよう, 妥当な措置を講じる必要がある.

4.3.  プライベートクレーム名

JWT の作成者および利用者は, 相互に同意のもとで, 予約済クレーム名 Section 4.1 (予約済クレーム名) でもパブリッククレーム名 Section 4.2 (パブリッククレーム名) でもないプライベートクレーム名を用いてもよい (MAY). パブリッククレーム名とは異なり, プライベートクレーム名は衝突の可能性があり, 慎重に使用する必要がある.

5.  JWT ヘッダ

JWTヘッダ内のJSONオブジェクトのメンバは, JWTに適用される暗号化オペレーション, および任意でJWTの追加プロパティを表現している. JWTヘッダ内のメンバ名はヘッダ・パラメータ名として参照される. それらの名前はユニークである必要があり (MUST) , 受信者は重複するヘッダ・パラメータ名を持つJWTを拒否するか, ECMAScript 5.1 [ECMAScript] (Ecma International, “ECMAScript Language Specification, 5.1 Edition,” June 2011.) の節 15.12 (JSONオブジェクト) に指定されているとおり語彙的に最後の重複メンバ名だけを返却するJSONパーサを利用しなければならない (MUST). 対応する値はヘッダ・パラメータ値として参照される.

JWSヘッダ・パラメータは[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)で定義されている. JWEヘッダ・パラメータは[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)で定義されている. 更に本仕様は, JWTがJWSである場合とJWTがJWEである場合の両方のケースにおいて続くヘッダ・パラメータが利用されることを明示する.

5.1.  "typ" (Type) ヘッダ・パラメータ

typ (type) ヘッダ・パラメータは, アプリケーションにとって有用なコンテキストにおいて, アプリケーション固有の方法で, このJWTの形式を記述するために利用してもよい (MAY). このパラメータはJWTの処理に影響を及ぼさない. もしパラメータが存在した場合, その値はそのオブジェクトがJWTであることを示すため, JWTもしくはurn:ietf:params:oauth:token-type:jwtを指定することが推奨される (RECOMMENDED). typの値は大文字小文字を区別する文字列である. このヘッダ・パラメータの利用は任意である (OPTIONAL).

5.2.  "cty" (Content Type) ヘッダ・パラメータ

cty (content type) ヘッダ・パラメータはJWTの構造情報を記述するために用いられる. 値は文字列でなければならない (MUST).

入れ子の署名/暗号化オペレーションが使用されない通常時, このヘッダ・パラメータの使用は推奨されない (NOT RECOMMENDED). 入れ子の署名/暗号化オペレーションが使用される場合, このヘッダ・パラメータの使用は必須である (REQUIRED). 後者の場合, このJWTの中に入れ子となるJWTが含まれることを示すため, 値はJWTでなければならない (MUST). 入れ子のJWTの例はAppendix A.2 (入れ子 JWT の例)を参照のこと.

ctyヘッダ・パラメータ値には, typ ヘッダパラメータと同じ値空間および同じ規則が適用される.

5.3.  ヘッダ・パラメータとしてクレームを複製する

暗号化されたJWTを使ういくつかのアプリケーションでは, 暗号化されていない表現のいくつかのクレームを持つことは有用である. 例えばこれはアプリケーションがJWTを復号する前にそれををどのように処理するかを決定するためのルールを処理する際に使用される.

本仕様は, JWE の JWT クレームセット中に存在するクレームが, アプリケーションの必要に応じてヘッダパラメータとしても重複して存在することを許可する. もしそのように複製されたクレームが存在する場合, それらを受け取るアプリケーションはそれらの値が同一であることを確認すべきである (SHOULD). JWTのヘッダ・パラメータ値として複製されるクレームが, 暗号化せずに送信しても安全なものであることを保証するのは, アプリケーションの責任である.

本仕様はそれらを必要とするアプリケーションのために, 暗号化されたJWTの中のクレームの暗号化されていない複製を提供する目的でiss (issuer), sub (subject), aud (audience) ヘッダ・パラメータ名を予約する. 他の仕様においても同様に必要があればヘッダ・パラメータ名として予約済クレーム名として他の名前を予約してもよい (MAY).

6.  プレーンテキストJWT

署名や暗号化以外の方法でJWTコンテンツが保護されるユースケースをサポートするために, 署名と暗号化の両方なしにJWTを生成することも可能とする (MAY). プレーンテキストJWTはJSON Web Algorithms (JWA)で定義されたJWSのalgヘッダパラメータにnoneを使用したJWSであり, JWS署名値は空文字列となる.

6.1.  プレーンテキストJWTの例

次の例ではJWTヘッダはエンコード済オブジェクトがプレーンテキストJWTであることを宣言する.

  {"alg":"none"}

JWTヘッダのUTF-8表現のオクテットをbase64urlエンコーディングし, このエンコード済JWTヘッダを得る.

  eyJhbGciOiJub25lIn0

次は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を作成および検証するためのルール

JWTを作成するために, 次の手順を実行しなければならない(MUST). 手順の入力と出力の間に依存関係が存在しない場合には, 手順の順序は重要ではない.

1. 必要なクレームを含むJWTクレームセットを作成する. なお, 空白は表現の中で明確に許容されており, エンコーディングの前に正規化を実行する必要はない.
2. メッセージをJWTクレームセットのUTF-8表現のオクテットとする.
3. 必要なヘッダパラメータを含むJWTヘッダを作成する. JWTは, [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)仕様, または[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)仕様に従わなければならない(MUST). なお, 空白は表現の中で明確に許容されており, エンコーディングの前に正規化を実行する必要はない.
4. JWTヘッダのUTF-8表現のオクテットをbase64urlエンコードする. これをエンコード済JWTヘッダとする,
5. 当該のJWTがJWSかJWEかによって2つのケースがある.
   • JWTがJWSの場合, JWSヘッダとしてJWTヘッダを, JWSペイロードとしてメッセージを使用してJWSを作成する. JWSを作成するために[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)で明記されたすべての手順に従わなければならない(MUST).
   • JWTがJWEの場合, JWEヘッダとしてJWTヘッダを, JWEプレーンテキストとしてメッセージを使用してJWEを作成する. JWEを作成するために[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)で明記されたすべての手順に従わなければならない(MUST)
6. 入れ子にされた署名または暗号化処理を行う場合は, JWSもしくはJWEをメッセージとしてステップ3に戻る. この際, そのステップで新たに作られる JWTヘッダのcty (content type) ヘッダ値には, JWTを指定する.
7. それ以外の場合, 結果として生成されるJWTはJWSまたはJWEとなる.

JWTを検証する際, 次の手順を取らねばならない(MUST). 手順の入力と出力の間に依存関係が存在しない場合には, 手順の順序は重要ではない. 列挙されている手順のいずれかが失敗した場合, そのJWTの処理はリジェクトされねばならない(MUST).

1. JWTは少なくとも一つのピリオド('.')を含まねばならない(MUST)
2. エンコード済JWTヘッダは最初のピリオド(',')の前のJWTの一部とする.
3. エンコード済JWTヘッダは, パディング文字を使用しないという本仕様が定める制約に従い, base64urlデコードできなければならない(MUST).
4. 生成されたJWTヘッダは, RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]に準拠した, 完全に有効なJSON構文でなければならない(MUST).
5. 生成されたJWTヘッダは, その構文と意味が理解可能で且つサポートされ, 理解できないとき無視されるパラメータと値のみを含むように検証されなければならない (MUST).
6. alg (アルゴリズム) ヘッダの値, およびオプションでenc (暗号化方式) ヘッダの値 (存在する場合) を検証し, そのJWT が JWS なのか JWE なのかを判別する.
7. JWTがJWSかJWEかによって, 2つのケースがある.
   • JWTがJWSの場合, JWSを検証するために[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)で指定されたすべての手順に従わなければならない(MUST). メッセージはbase64urlデコードされたJWSペイロードとなる.
   • JWTがJWEの場合, JWEを検証するために[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)で指定されたすべての手順に従わなければならない(MUST). メッセージはJWEプレーンテキストとなる.
8. JWTヘッダが cty (content type) の値として JWT を持つ場合, このメッセージは入れ子にされた署名または暗号化処理を受けたJWTである. この場合, メッセージをJWTとして扱い, ステップ1に戻る.
9. それ以外の場合, JWTクレームセットをメッセージとする.
10. JWTクレームセットは, RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]に準拠した, 完全に有効なJSON構文でなければならない(MUST)

7.1.  文字列の比較規則

JWTを処理するとき必然的にJSONオブジェクトの中の値を既知の文字列と比較することを求められる. 例えば, アルゴリズムが何であるかチェックするためには, alg というUnicode文字列を受け取ったJWTヘッダメンバ名と比較し, 一致しているヘッダパラメータがあるかどうかを確認することになる.

[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.) 節 5.3の "String Comparison Rules" に示す通り, JSON文字列と他のUnicode文字列の比較は, 正規化せずにUnicodeコードポイントを比較することによって実施されなければならない(MUST).

8.  暗号化アルゴリズム

JWTはJSON Web Signature (JWS)[JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.)とJSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)を, JWTのコンテンツに対して署名と暗号化の両方を実施するために利用する.

JWAの署名アルゴリズムのうち, HMAC SHA-256 (HS256)とnoneは, JWT実装に準拠する形で実装されなければならない(MUST). また実装は, SHA-256ハッシュアルゴリズム(RS256)のRSASSA-PKCS1-V1_5と, P-256曲線を利用したECDSAと, SHA-256ハッシュアルゴリズム(ES256)のサポートも推奨される(RECOMMENDED). 他のアルゴリズムと鍵サイズのサポートは任意である(OPTIONAL).

JWA暗号化アルゴリズムの実装が, 暗号化機能を提供する場合, 2048ビット鍵(RSA1_5)のRSAES-PKCS1-V1_5, 128と256ビット鍵のAESキーラップ(A128KWとA256KW), それと複合認証されたAES CBCとHMAC SHA-2(A128CBC-HS256とA256CBC-HS512)を 使用した暗号化アルゴリズムは、実装に準拠する形で実装しなければならない(MUST). 実装がコンテンツ暗号化鍵をラップするために利用される鍵について同意するためのECDH-ESと, 128ビットと256ビットの鍵でGalois/Counterモード(GCM)のAES(A128GCMとA256GCM) をサポートすることもまた推奨される(RECOMMENDED). 他のアルゴリズムと鍵サイズのサポートは任意である(OPTIONAL).

9.  IANA Considerations

9.1.  JSON Web トークンクレームレジストリ

本仕様では, 予約済 JWT クレーム名のための IANA JSON Web トークンクレームレジストリを定める. このレジストリは, 予約済クレーム名とそれを定義している仕様へのリファレンスを記録する. 本仕様は Section 4.1 (予約済クレーム名) で定義されているクレーム名を登録する.

値は, 1名以上の Designated Experts の勧告に従い, [TBD]@ietf.org のメーリングリストで2週間の審査期間を経て, Specification Required [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) な状態で登録される. しかしながら, 発行に先立ってそれらの値を用いることができるように, Designated Expert(s) はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for access token type: example") で [TBD]@ietf.org のメーリングリストに通知しなければならず, そこでレビューとコメントが行われる. [[ RFC-EDITORへの注意: メーリングリストの名前は, IESGとIANAと協議の上, 決定されるべきである. 推奨される名前: claims-reg-review ]]

Designated Expert(s) は審査期間内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.

IANA は, Designed Export(s) からのレジストリ更新のみを受け付けなければならず, すべての登録要請をレビューメーリングリストに送信しなければならない.

9.1.1.  レジストリテンプレート

Claim Name:

名称 (例: "example"). 名称は大文字と小文字を区別する. 大文字と小文字を区別せず他の登録されている名称と一致する名称は受け付けられるべきではない (SHOULD NOT).

Change Controller:

RFC の標準に従う際は, "IETF" と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページの URL) も記載してもよい.

Specification Document(s):

パラメータ仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできる URI が記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.

9.1.2.  初期レジストリコンテンツ

• クレーム名: iss
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.1 ("iss" (Issuer) クレーム) of [[ this document ]]

• クレーム名: sub
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.2 ("sub" (Subject) クレーム) of [[ this document ]]

• クレーム名: aud
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.3 ("aud" (Audience) クレーム) of [[ this document ]]

• クレーム名: exp
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.4 ("exp" (Expiration Time) クレーム) of [[ this document ]]

• クレーム名: nbf
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.5 ("nbf" (Not Before) クレーム) of [[ this document ]]

• クレーム名: iat
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.6 ("iat" (Issued At) クレーム) of [[ this document ]]

• クレーム名: jti
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.7 ("jti" (JWT ID) クレーム) of [[ this document ]]

• クレーム名: typ
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.8 ("typ" (Type) クレーム) of [[ this document ]]

9.2.  Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt

9.2.1.  レジストリコンテンツ

本仕様は, コンテントが JWT であることを示すことが出来るように, An IETF URN Sub-Namespace for OAuth (Campbell, B. and H. Tschofenig, “An IETF URN Sub-Namespace for OAuth,” October 2012.) [RFC6755] に設けられた IANA urn:ietf:params:oauth レジストリへ token-type:jwt の値を登録する.

• URN: urn:ietf:params:oauth:token-type:jwt
• 共通名: JSON Web Token (JWT) Token Type
• 変更管理: IETF
• 仕様ドキュメント: [[this document]]

9.3.  JSON Web Signature and Encryption Type Values Registration

9.3.1.  レジストリコンテンツ

本仕様は, コンテントが JWT であることを示すことが出来るように, IANA JSON Web Signature and Encryption Type Values レジストリ [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.) に JWT タイプの値を登録する.

• "typ" ヘッダ・パラメータの値: JWT
• MIME Type の略称: application/jwt
• 変更管理: IETF
• 仕様ドキュメント: Section 5.1 ("typ" (Type) ヘッダ・パラメータ) of [[ this document ]]

9.4.  Media Type Registration

9.4.1.  レジストリコンテンツ

本仕様は, コンテントが JWT であることを示すことが出来るように, MIME Media Type registry [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) に application/jwt Media Type [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) を登録する.

• タイプ名: application
• サブタイプ名: jwt
• 必須パラメータ: n/a
• オプションパラメータ: n/a
• エンコーディングにおける考慮点: JWT の値はピリオド ('.') で区切られた base64url エンコード済の値 (それらのうち幾つかが空の文字列の場合もある) の列としてエンコードされる.
• セキュリティ上の考慮点: [[ this document ]] のセキュリティ上の考慮点の節を参照のこと.
• 相互運用上の考慮点: n/a
• 公開された仕様: [[ this document ]]
• このメディアタイプを利用するアプリケーション: OpenID Connect, Mozilla Persona, Salesforce, Google, 他多数
• 追加情報: マジックナンバー: n/a, ファイル拡張子: n/a, Macintosh ファイルタイプコード: n/a
• その他情報の問い合わせ先とメールアドレス: Michael B. Jones, mbj@microsoft.com
• 意図された用途: COMMON
• 用途の制限: none
• 著者: Michael B. Jones, mbj@microsoft.com
• 変更管理: IETF

9.5.  JWEヘッダパラメータの登録

本仕様は, Section 5.3 (ヘッダ・パラメータとしてクレームを複製する) にあるように, ヘッダパラメータとして複製されたクレームを使用するために, JSON Web Signature and Encryption Header Parameters レジストリのSection 4.1 (予約済クレーム名)で定義された特定の予約済クレーム名を登録する.

9.5.1.  レジストリコンテンツ

• ヘッダパラメータ名: iss
• ヘッダパラメータの使用箇所: JWE
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.1 ("iss" (Issuer) クレーム) of [[ this document ]]

• ヘッダパラメータ名: sub
• ヘッダパラメータの使用箇所: JWE
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.2 ("sub" (Subject) クレーム) of [[ this document ]]

• ヘッダパラメータ名: aud
• ヘッダパラメータの使用箇所: JWE
• 変更管理: IETF
• 仕様ドキュメント: Section 4.1.3 ("aud" (Audience) クレーム) of [[ this document ]]

10.  Security Considerations

JWT/JWS/JWE/JWKエージェントは, 暗号化アプリケーションが直面したあらゆるセキュリティ問題に対応しなければならない. これらの問題の中には, ユーザのプライベート鍵および対称鍵を保護し, 様々な攻撃を防ぎ, ユーザが不正な受信者のためにメッセージを不注意に暗号化するような間違いを避けることを助けることが含まれる. セキュリティに関する検討項目の全てのリストを挙げることは本ドキュメントの範囲外である.

JWSの仕様のすべてのセキュリティに関する検討項目は, 暗号化が使用される際のJWEのセキュリティに関する検討項目と同様に, JWTにも適用される. 特に, JWSのJSONのセキュリティに関する検討項目とUnicode比較のセキュリティに関する検討項目はJWSヘッダに適用されるのと同様にJWTクレームセットにも等しく適用される.

構文上, 入れ子のJWTのための署名と暗号化のオペレーションは任意の順番に適用してもよいが, 通常送信者はメッセージに署名してからその結果を暗号化するべきである (したがって, 署名を暗号化する). このことは, メッセージを暗号化されたままにするため, 署名者にプライバシーを提供するのと同様に, 署名を暴かれる攻撃を防ぐ. 更に, 暗号化されたテキストに対する署名は多くのルール上, 有効であるとは考えられてはいない.

署名と暗号化オペレーションの順序に関連するセキュリティ問題に関する潜在的な懸念は, 既にJWSとJWEの仕様の中で指摘されている. 特に, JWEは認証された暗号化アルゴリズムの利用のみをサポートしているため, 多くのコンテキストで適用される暗号化後の署名に関する潜在的な必要性についての暗号化関連の懸念事項は, 本仕様には適用されない.

11.  References

11.1. Normative References

11.2. Informative References

11.3. 翻訳プロジェクト

Appendix A.  JWT Examples

This section contains examples of JWTs. For other example JWTs, see Section 6.1 (プレーンテキストJWTの例) and Appendices A.1, A.2, and A.3 of [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.).

A.1.  暗号化されたJWTの例

この例では, RSAES-PKCS1-V1_5とAES_128_CBC_HMAC_SHA_256を使用して, 受信者にSection 3.1 (JWTの例)で使用したものと同じクレームを暗号化する.

次の例ではJWEヘッダ(改行は掲載上の都合による)を宣言する.

• 暗号化鍵コンテンツは, JWE暗号化鍵を生成するために, RSAES-PKCS1-V1_5アルゴリズムを用いて受信者によって暗号化され,
• 平文は暗号文を生成するためにAES_128_CBC_HMAC_SHA_256アルゴリズムを用いて暗号化される.

  {"alg":"RSA1_5","enc":"A128CBC-HS256"}

平文の値としてSection 3.1 (JWTの例)のJWTクレームセットのUTF-8表現のオクテットを利用するほか, このJWTの計算は使用される鍵を含む[JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)のAppendix 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 が入れ子になったJWTを作成する JWE または JWS のペイロードとして使用する方法を示す. この場合, JWT クレームセットは始めに署名した後, 暗号化されている.

内部の署名 JWT は, [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.) の 付録 A.2 の例と同じである. この例は, その後 RSAES-PKCS1-V1_5 と AES_128_CBC_HMAC_SHA_256 を使用して受信者にこの内部の JWT を暗号化する.

以下のJWEヘッダ (改行は掲載上の都合による) の例を宣言する:

• コンテンツ暗号化キーは, JWE 暗号化されたキーを生成するための RSAES-PKCS1-V1_5 アルゴリズムを使用した受信者に暗号化され,
• その平文は, 暗号化文を生成するための AES_128_CBC_HMAC_SHA_256 アルゴリズムを使用した暗号化であり,
• その平文は JWT である.

  {"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}

JWTヘッダのUTF-8表現のオクテットをbase64urlエンコードすることによりエンコード済JWTヘッダの値を得られる:

  eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0

この JWT の計算は [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.) の 付録 A.2 の JWE の計算と同じであり, 異なる JWE ヘッダ, 平文, 初期ベクトル, およびコンテンツ暗号化キーの値以外が使用される.

使用されているペイロードは, [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2013.) (すべての空白や改行は削除されている) の 付録の節 A.2.1 終わりの JWT の ASCII 表現の8ビットバイトである.

使用されている初期ベクトルの値である:

[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]

この例では, 以下のJSON Webキー [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.) フォーマットで表現されているコンテンツ暗号キーを使用している:

  {"kty":"oct",
   "k":"GawgguFyGrWKav7AX4VKUg"
  }

この入れ子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

Appendix B.  JWTとSAMLアサーションの関係

SAML 2.0 (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑core‑2.0‑os]はJWTによってサポートされるものよりもより多くの表現とセキュリティ・オプションを持ってセキュリティ・トークンを生成するための標準を提供する. しかしながら, この柔軟性と表現の豊かさの代償はサイズと複雑性の両方である. SAMLのXML [W3C.CR‑xml11‑20021015] (Cowan, J., “Extensible Markup Language (XML) 1.1,” October 2002.)とXML DSIG [RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.)の使用はSAMLアサーションのサイズを大きくしている. そのXMLの使用と特にXML正規化 [W3C.REC‑xml‑c14n‑20010315] (Boyer, J., “Canonical XML Version 1.0,” March 2001.)がその複雑性を増大させている.

JWTはHTTPヘッダとURIのクエリ引数に収まるだけの大きさの単純なセキュリティ・トークン・フォーマットを提供する様に意図されている. それは, SAMLよりはるかに単純なトークン・モデルをサポートすることにより実現しており, JSON (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]オブジェクト・エンコーディングの構文を使用する. 更にそれは, メッセージ認証コード (MAC) とXML DSIGより小さい (それほど柔軟ではない) フォーマットを使用するデジタル署名を利用するセキュリティ・トークンをサポートしている.

したがって, JWTはSAMLアサーションが行うことのうち幾らかを実現することが出来るが, JWTはSAMLアサーションのすべてを置き換えるのではなく, 実装の容易さ, もしくはコンパクトさが考慮される様な場合に使われるトークン・フォーマットとして意図されている.

SAMLアサーションは常にサブジェクトに関するエンティティによって発行されるステートメントである. しばしばJWTも, エンティティがiss (issuer) クレームによって表現され, サブジェクトがsub (subject) クレームによって表現されるステートメントを生成することにより, それと同じ方法で使用される. しかしながら, これらのクレームはオプションなので, JWTフォーマットは他の用途でも用いることが出来る.

Appendix C.  JWTとシンプル・ウェブ・トークン (SWT) の関係

中核おいて, JWTとシンプル・ウェブ・トークンSWT (Hardt, D. and Y. Goland, “Simple Web Token (SWT),” November 2009.) [SWT]は両方とも, アプリケーション間でクレームのセットのやり取りを可能にする. SWTについては, クレーム名とクレーム値の両方が文字列であり, JWTはクレーム名が文字列である一方でクレーム値が任意のJSON型であることが出来る. 両方のトークンの型は暗号化を使った内容の保護を提供している. SWTはHMAC SHA-256を, JWTは署名, MAC, 暗号化アルゴリズムを含むアルゴリズムを選択することが出来る.

Appendix D.  Acknowledgements

The authors acknowledge that the design of JWTs was intentionally influenced by the design and simplicity of Simple Web Tokens (Hardt, D. and Y. Goland, “Simple Web Token (SWT),” November 2009.) [SWT] and ideas for JSON tokens that Dick Hardt discussed within the OpenID community.

Solutions for signing JSON content were previously explored by Magic Signatures (Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011.) [MagicSignatures], JSON Simple Sign (Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010.) [JSS], and Canvas Applications (Facebook, “Canvas Applications,” 2010.) [CanvasApp], all of which influenced this draft.

This specification is the work of the OAuth Working Group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:

Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben Laurie, James Manger, Prateek Mishra, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.

Hannes Tschofenig and Derek Atkins chaired the OAuth working group and Sean Turner and Stephen Farrell served as Security area directors during the creation of this specification.

Appendix E.  Document History

[[ to be removed by the RFC editor before publication as an RFC ]]

-11

• Added a Nested JWT example.
• Added sub to the list of Claims registered for use as Header Parameter values when an unencrypted representation is required in an encrypted JWT.

-10

• Allowed Claims to be replicated as Header Parameters in encrypted JWTs as needed by applications that require an unencrypted representation of specific Claims.

-09

• Clarified that the typ header parameter is used in an application-specific manner and has no effect upon the JWT processing.
• Stated that recipients MUST either reject JWTs with duplicate Header Parameter Names or with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name.

-08

• Tracked a change to how JWEs are computed (which only affected the example encrypted JWT value).

-07

• Defined that the default action for claims that are not understood is to ignore them unless otherwise specified by applications.
• Changed from using the term "byte" to "octet" when referring to 8 bit values.
• Tracked encryption computation changes in the JWE specification.

-06

• Changed the name of the prn claim to sub (subject) both to more closely align with SAML name usage and to use a more intuitive name.
• Allow JWTs to have multiple audiences.
• Applied editorial improvements suggested by Jeff Hodges, Prateek Mishra, and Hannes Tschofenig. Many of these simplified the terminology used.
• Explained why Nested JWTs should be signed and then encrypted.
• Clarified statements of the form "This claim is OPTIONAL" to "Use of this claim is OPTIONAL".
• Referenced String Comparison Rules in JWS.
• Added seriesInfo information to Internet Draft references.

-05

• Updated values for example AES CBC calculations.

-04

• Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.
• Applied changes made by the RFC Editor to RFC 6749's registry language to this specification.
• Reference RFC 6755 -- An IETF URN Sub-Namespace for OAuth.

-03

• Added statement that "StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied".
• Indented artwork elements to better distinguish them from the body text.

-02

• Added an example of an encrypted JWT.
• Added this language to Registration Templates: "This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted."
• Applied editorial suggestions.

-01

• Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object. This significantly simplified nested JWTs.
• Moved description of how to determine whether a header is for a JWS or a JWE from the JWT spec to the JWE spec.
• Changed registration requirements from RFC Required to Specification Required with Expert Review.
• Added Registration Template sections for defined registries.
• Added Registry Contents sections to populate registry values.
• Added "Collision Resistant Namespace" to the terminology section.
• Numerous editorial improvements.

-00

• Created the initial IETF draft based upon draft-jones-json-web-token-10 with no normative changes.

Appendix F.  翻訳者

本仕様の翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.

• Masaru Kurahayashi (Yahoo! Japan)
• Muneomi Sakuta
• Naohiro Fujie (Itochu Techno Solutions)

Authors' Addresses