TOC 
OAuth Working GroupM. Jones
Internet-DraftMicrosoft
Intended status: Standards TrackJ. Bradley
Expires: January 30, 2014Ping Identity
 N. Sakimura
 NRI
 July 29, 2013


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




 TOC 

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"と同じである.



 TOC 

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.)で述べられている通りに解釈されるべきものである.



 TOC 

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を参照すること.



 TOC 

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のどちらとして利用されているかに依存する.



 TOC 

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の例)を参照のこと.



 TOC 

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つのクラスが定義されている.



 TOC 

4.1.  予約済クレーム名

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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

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

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



 TOC 

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

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



 TOC 

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

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



 TOC 

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である場合の両方のケースにおいて続くヘッダ・パラメータが利用されることを明示する.



 TOC 

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

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



 TOC 

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

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

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

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



 TOC 

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

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

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

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



 TOC 

6.  プレーンテキストJWT

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



 TOC 

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
  .


 TOC 

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つのケースがある.
  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つのケースがある.
  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)



 TOC 

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).



 TOC 

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キーラップ(A128KWA256KW), それと複合認証されたAES CBCとHMAC SHA-2(A128CBC-HS256A256CBC-HS512)を 使用した暗号化アルゴリズムは、実装に準拠する形で実装しなければならない(MUST). 実装がコンテンツ暗号化鍵をラップするために利用される鍵について同意するためのECDH-ESと, 128ビットと256ビットの鍵でGalois/Counterモード(GCM)のAES(A128GCMA256GCM) をサポートすることもまた推奨される(RECOMMENDED). 他のアルゴリズムと鍵サイズのサポートは任意である(OPTIONAL).



 TOC 

9.  IANA Considerations



 TOC 

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) からのレジストリ更新のみを受け付けなければならず, すべての登録要請をレビューメーリングリストに送信しなければならない.



 TOC 

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

Claim Name:
名称 (例: "example"). 名称は大文字と小文字を区別する. 大文字と小文字を区別せず他の登録されている名称と一致する名称は受け付けられるべきではない (SHOULD NOT).
Change Controller:
RFC の標準に従う際は, "IETF" と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページの URL) も記載してもよい.
Specification Document(s):
パラメータ仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできる URI が記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.



 TOC 

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



 TOC 

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



 TOC 

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 の値を登録する.



 TOC 

9.3.  JSON Web Signature and Encryption Type Values Registration



 TOC 

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 タイプの値を登録する.



 TOC 

9.4.  Media Type Registration



 TOC 

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.) を登録する.



 TOC 

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

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



 TOC 

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



 TOC 

10.  Security Considerations

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

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

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

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



 TOC 

11.  References



 TOC 

11.1. Normative References

[ECMAScript] Ecma International, “ECMAScript Language Specification, 5.1 Edition,” ECMA 262, June 2011 (HTML, PDF).
[JWA] Jones, M., “JSON Web Algorithms (JWA),” draft-ietf-jose-json-web-algorithms (work in progress), July 2013 (HTML).
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” draft-ietf-jose-json-web-encryption (work in progress), July 2013 (HTML).
[JWK] Jones, M., “JSON Web Key (JWK),” draft-ietf-jose-json-web-key (work in progress), July 2013 (HTML).
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), July 2013 (HTML).
[RFC2046] Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4288] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” RFC 4288, December 2005 (TXT).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC4648] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 4648, October 2006 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[RFC6755] Campbell, B. and H. Tschofenig, “An IETF URN Sub-Namespace for OAuth,” RFC 6755, October 2012 (TXT).


 TOC 

11.2. Informative References

[CanvasApp] Facebook, “Canvas Applications,” 2010.
[JSS] Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010.
[MagicSignatures] Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011.
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, March 2005.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” RFC 3275, March 2002 (TXT).
[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” RFC 4122, July 2005 (TXT, HTML, XML).
[SWT] Hardt, D. and Y. Goland, “Simple Web Token (SWT),” Version 0.9.5.1, November 2009.
[W3C.CR-xml11-20021015] Cowan, J., “Extensible Markup Language (XML) 1.1,” W3C CR CR-xml11-20021015, October 2002.
[W3C.REC-xml-c14n-20010315] Boyer, J., “Canonical XML Version 1.0,” World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001 (HTML).


 TOC 

11.3. 翻訳プロジェクト

[oidfj] OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン.”
[oidfj-github] OpenIDファウンデーションジャパン, “Githubレポジトリー.”
[oidfj-trans] OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ.”


 TOC 

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.).



 TOC 

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

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

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

  {"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


 TOC 

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ヘッダ (改行は掲載上の都合による) の例を宣言する:

  {"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


 TOC 

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フォーマットは他の用途でも用いることが出来る.



 TOC 

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, 暗号化アルゴリズムを含むアルゴリズムを選択することが出来る.



 TOC 

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.



 TOC 

Appendix E.  Document History

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

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01

-00



 TOC 

Appendix F.  翻訳者

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



 TOC 

Authors' Addresses

  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
URI:  http://self-issued.info/
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Nat Sakimura
  Nomura Research Institute
Email:  n-sakimura@nri.co.jp