JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
JSON Web Token (JWT) は、2つの当事者間で転送されるクレームを表すためのコンパクトでURLセーフな手段です。JWTのクレームは、JSON Web Signature (JWS) 構造のペイロードとして使用されるJSONオブジェクトとしてエンコードされるか、JSON Web Encryption (JWE) 構造の平文として使用され、クレームをデジタル署名またはメッセージ認証コード（MAC）によって整合性保護することができます。また、暗号化することもできます。
This is an Internet Standards Track document.
これはインターネット標準トラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）によって公開承認されました。インターネット標準に関する詳細は、RFC 5741のセクション2で説明されています。.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7519.
この文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報については、 http://www.rfc-editor.org/info/rfc7519 を参照してください。
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
この文書は、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）にしたがう必要があります。これらの文書をよく確認し、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.
JSON Web Token (JWT) は、HTTP Authorization ヘッダーや URI クエリパラメーターなどのスペースが制限された環境向けに設計されたコンパクトなクレーム表現形式です。JWT は、JSON Web Signature (JWS) [JWS] 構造のペイロードとして使用される JSON [RFC7159] オブジェクトとして転送されるクレームをエンコードし、または JSON Web Encryption (JWE) [JWE] 構造の平文として使用され、クレームをデジタル署名またはメッセージ認証コード (MAC) によって整合性保護することができます。また、暗号化することもできます。JWT は、常に JWS Compact Serialization または JWE Compact Serialization を使用して表現されます。
The suggested pronunciation of JWT is the same as the English word "jot".
JWT の推奨発音は、英語の「jot」と同じです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、 「要求されています（REQUIRED）」、 「することになります（SHALL）」、「することはありません（SHALL NOT）」、 「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、 「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、 「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 [RFC2119]に記載されているとおりに解釈されるものとします。 これらの用語がすべて大文字で表示される場合にのみ、解釈を適用する必要があります。
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", and "Unsecured JWS" are defined by the JWS specification [JWS].
「JSON Web Signature (JWS)」、「Base64url エンコーディング」、「ヘッダーパラメーター」、「JOSE ヘッダー」、「JWS Compact Serialization」、「JWS Payload」、「JWS Signature」、および「Unsecured JWS」の用語は、JWS 仕様書 [JWS] で定義されています。
The terms "JSON Web Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Serialization", "JWE Encrypted Key", and "JWE Initialization Vector" are defined by the JWE specification [JWE].
「JSON Web Encryption (JWE)」、「Content Encryption Key (CEK)」、「JWE Compact Serialization」、「JWE Encrypted Key」、および「JWE Initialization Vector」の用語は、JWE 仕様書 [JWE] で定義されています。
The terms "Ciphertext", "Digital Signature", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
「Ciphertext」、「Digital Signature」、「Message Authentication Code (MAC)」、および「Plaintext」の用語は、「Internet Security Glossary, Version 2」[RFC4949] で定義されています。
These terms are defined by this specification:
この仕様書で定義される用語は次のとおりです。
JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.
JSON Web Token (JWT) JWS または JWE でエンコードされた JSON オブジェクトとして表されるクレームのセットを表す文字列であり、クレームをデジタル署名または MAC によって整合性保護および/または暗号化することができます。
JWT Claims Set A JSON object that contains the claims conveyed by the JWT.
JWT Claims Set JWT によって伝達されるクレームを含む JSON オブジェクト。
Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
クレーム 主体に関して主張された情報の一部。クレームは、クレーム名とクレーム値からなる名前/値ペアとして表されます。
Claim Name The name portion of a claim representation. A Claim Name is always a string.
クレーム名 クレーム表現の名前部分。クレーム名は常に文字列です。
Claim Value The value portion of a claim representation. A Claim Value can be any JSON value.
クレーム値 クレーム表現の値部分。クレーム値は任意の JSON 値であることができます。
Nested JWT A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.
ネストされた JWT ネストされた署名および/または暗号化が使用されている JWT。ネストされた JWT では、JWT がそれぞれ JWS または JWE 構造のペイロードまたは平文値として使用されます。
Unsecured JWT A JWT whose claims are not integrity protected or encrypted.
未保護 JWT クレームが整合性保護または暗号化されていない JWT。
Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
衝突耐性名前 名前空間内の名前を割り当てるための方法を提供し、他の名前と高い確率で衝突しないようにします。衝突耐性名前空間の例には、ドメイン名、ITU-T X.660 および X.670 勧告シリーズで定義されたオブジェクト識別子 (OID)、および Universally Unique IDentifiers (UUIDs) [RFC4122] が含まれます。管理委任された名前空間を使用する場合、名前の定義者は、名前を定義するために使用する名前空間の一部を管理していることを合理的に確認する必要があります。
StringOrURI A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.
StringOrURI JSON 文字列値であり、任意の文字列値を使用できるが、":" 文字を含む値は URI [RFC3986] である必要があるという追加要件がある。StringOrURI 値は、変換や正規化が適用されない大文字小文字を区別する文字列として比較されます。
NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure. This JSON object is the JWT Claims Set. As per Section 4 of RFC 7159 [RFC7159], the JSON object consists of zero or more name/value pairs (or members), where the names are strings and the values are arbitrary JSON values. These members are the claims represented by the JWT. This JSON object MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159].
JWT は、JWS および/または JWE 構造でエンコードされた JSON オブジェクトとして、クレームのセットを表します。この JSON オブジェクトは JWT クレームセットと呼ばれます。RFC 7159 のセクション 4 [RFC7159] に従い、JSON オブジェクトは、名前が文字列で値が任意の JSON 値である 1 つ以上の名前/値ペア (またはメンバ) で構成されます。これらのメンバは JWT によって表されるクレームです。この JSON オブジェクト MAY は、RFC 7159 のセクション 2 [RFC7159] に従い、JSON 値または構造文字の前後に空白と/または改行を含めることができます。
The member names within the JWT Claims Set are referred to as Claim Names. The corresponding values are referred to as Claim Values.
JWT クレームセット内のメンバ名は、クレーム名と呼ばれます。対応する値は、クレーム値と呼ばれます。
The contents of the JOSE Header describe the cryptographic operations applied to the JWT Claims Set. If the JOSE Header is for a JWS, the JWT is represented as a JWS and the claims are digitally signed or MACed, with the JWT Claims Set being the JWS Payload. If the JOSE Header is for a JWE, the JWT is represented as a JWE and the claims are encrypted, with the JWT Claims Set being the plaintext encrypted by the JWE. A JWT may be enclosed in another JWE or JWS structure to create a Nested JWT, enabling nested signing and encryption to be performed.
JOSE ヘッダーの内容は、JWT クレームセットに適用される暗号操作を記述します。JOSE ヘッダーが JWS 用である場合、JWT は JWS として表され、クレームはデジタル署名または MAC によって整合性保護され、JWT クレームセットが JWS ペイロードとなります。JOSE ヘッダーが JWE 用である場合、JWT は JWE として表され、クレームは暗号化され、JWT クレームセットが JWE によって暗号化された平文となります。JWT は、ネストされた JWT を作成するために別の JWE または JWS 構造に包まれることがあり、ネストされた署名および暗号化を実行することができます。
A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters. Each part contains a base64url-encoded value. The number of parts in the JWT is dependent upon the representation of the resulting JWS using the JWS Compact Serialization or JWE using the JWE Compact Serialization.
JWT は、URL セーフな部分のシーケンスで表され、各部分はピリオド ('.') 文字で区切られます。各部分には、base64url エンコードされた値が含まれます。JWT の部分数は、JWS Compact Serialization または JWE Compact Serialization を使用して得られた JWS の表現に依存します。
The following example JOSE Header declares that the encoded object is a JWT, and the JWT is a JWS that is MACed using the HMAC SHA-256 algorithm:
次の JOSE ヘッダーの例は、エンコードされたオブジェクトが JWT であり、JWT が HMAC SHA-256 アルゴリズムを使用して MAC された JWS であることを宣言しています。
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
To remove potential ambiguities in the representation of the JSON object above, the octet sequence for the actual UTF-8 representation used in this example for the JOSE Header above is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first and second lines, the second line has one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing the UTF-8 representation of the JOSE Header in this example (using JSON array notation) are:
JSON オブジェクトの表現における曖昧さを排除するために、上記の JOSE ヘッダーで使用された実際の UTF-8 表現のオクテットシーケンスも以下に含まれています。 (異なるプラットフォームでの行区切りの表現 (CRLF と LF)、行の先頭と末尾のスペースの違い、最後の行に行区切りがあるかどうかなど、異なる原因により曖昧さが生じることがあります。この例で使用される表現では、最初の行には先頭または末尾のスペースがなく、CRLF 行区切り (13, 10) が最初の行と 2 番目の行の間に挿入され、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]
[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]
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
JOSE ヘッダーの UTF-8 表現のオクテットを base64url エンコードすると、次のエンコードされた JOSE ヘッダー値が得られます:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The following is an example of a JWT Claims Set:
以下は、JWT クレームセットの例です:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The following octet sequence, which is the UTF-8 representation used in this example for the JWT Claims Set above, is the JWS Payload:
以下は、この例で使用される 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] Base64url encoding the JWS Payload yields this encoded JWS Payload (with line breaks for display purposes only):
[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] Base64url encoding the JWS Payload yields this encoded JWS Payload (with line breaks for display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly 9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly 9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Computing the MAC of the encoded JOSE Header and encoded JWS Payload with the HMAC SHA-256 algorithm and base64url encoding the HMAC value in the manner specified in [JWS] yields this encoded JWS Signature:
エンコードされた JOSE ヘッダーとエンコードされた JWS ペイロードの MAC を HMAC SHA-256 アルゴリズムで計算し、HMAC 値を [JWS] で指定された方法で base64url エンコードすると、次のエンコードされた JWS シグネチャが得られます:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):
これらのエンコードされた部分をこの順序でピリオド ('.') 文字で連結すると、次の完全な JWT が得られます (表示目的の改行を含む):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. The Claim Names within a JWT Claims Set MUST be unique; JWT parsers MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
JWT クレームセットは、JWT によって伝達されるクレームを表す JSON オブジェクトであり、そのメンバはクレームを表します。JWT クレームセット内のクレーム名は一意である必要があります。JWT パーサーは、重複するクレーム名を持つ JWT を拒否するか、ECMAScript 5.1 のセクション 15.12 ("The JSON Object") で指定されているように、レキシカルに最後の重複メンバ名のみを返す JSON パーサーを使用する必要があります。
The set of claims that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of JWTs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.
JWT が有効と見なされるために含まれる必要があるクレームのセットは、文脈に依存し、この仕様の範囲外です。JWT の特定のアプリケーションでは、実装が特定の方法でいくつかのクレームを理解して処理する必要があります。ただし、そのような要件がない場合、実装に理解されないすべてのクレームは無視されるMUSTです。
There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.
There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.
The following Claim Names are registered in the IANA "JSON Web Token Claims" registry established by Section 10.1. None of the claims defined below are intended to be mandatory to use or implement in all cases, but rather they provide a starting point for a set of useful, interoperable claims. Applications using JWTs should define which specific claims they use and when they are required or optional. All the names are short because a core goal of JWTs is for the representation to be compact.
以下のクレーム名は、セクション 10.1 で設立された IANA「JSON Web Token Claims」レジストリに登録されています。以下で定義されたクレームのいずれも、すべての場合において使用または実装することを必須とするものではありません。代わりに、有用で相互運用可能なクレームのセットの出発点を提供します。JWT を使用するアプリケーションは、使用する特定のクレームと、必須またはオプションである場合を定義する必要があります。すべての名前は短くなっています。なぜなら、JWT のコアゴールは表現がコンパクトであることです。
The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
"iss" (issuer) クレームは、JWT を発行したプリンシパルを識別します。このクレームの処理は一般にアプリケーション固有です。"iss" の値は、StringOrURI 値を含む大文字と小文字を区別する文字列です。このクレームの使用はオプションです。
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
"sub" (subject) クレームは、JWT の主体であるプリンシパルを識別します。JWT 内のクレームは通常、主体に関する文を表します。"sub" の値は、発行者の文脈でローカルに一意であるようにスコープが設定されているか、グローバルに一意である必要があります。このクレームの処理は一般にアプリケーション固有です。 "sub" の値は、StringOrURI 値を含む大文字と小文字を区別する文字列です。このクレームの使用はオプションです。
The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.
"aud" (Audience) クレームは、JWT が意図する受信者を識別します。JWT を処理する各プリンシパルは、"aud" クレーム内の値で自己を識別する必要があります。このクレームが存在する場合、クレームを処理するプリンシパルが "aud" クレーム内の値で自己を識別しない場合、JWT は拒否される必要があります。一般的な場合、"aud" の値は、StringOrURI 値を含む大文字と小文字を区別する文字列の配列です。JWT に受信者が1つしかない場合、"aud" の値は、StringOrURI 値を含む大文字と小文字を区別する単一の文字列である場合があります。受信者値の解釈は、一般的にアプリケーション固有です。このクレームの使用はオプションです。
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.
「exp」（有効期限）クレームは、JWTが処理される前に受け入れてはならない有効期限を識別します。「exp」クレームの処理には、現在の日付/時刻が「exp」クレームにリストされた有効期限日時の前である必要があります。
Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
実装者は、クロックスキューを考慮に入れるために、通常数分以内のわずかな余地を提供することができます。その値は、NumericDate値を含む数値である必要があります。このクレームの使用はオプションです。
The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the "nbf" claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the "nbf" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
"nbf" (有効開始日時) クレームは、JWTが処理される前に受け入れてはならない有効開始日時を識別します。「nbf」クレームの処理には、現在の日付/時刻が「nbf」クレームにリストされた有効開始日時の後である必要があります。実装者は、クロックスキューを考慮に入れるために、通常数分以内のわずかな余地を提供することができます。その値は、NumericDate値を含む数値である必要があります。このクレームの使用はオプションです。
The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
"iat" (発行日時) クレームは、JWTが発行された時刻を識別します。このクレームは、JWTの年齢を決定するために使用できます。その値は、NumericDate値を含む数値である必要があります。このクレームの使用はオプションです。
The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case- sensitive string. Use of this claim is OPTIONAL.
"jti" (JWT ID) クレームは、JWTの一意の識別子を提供します。識別子の値は、異なるデータオブジェクトに誤って同じ値が割り当てられる可能性が極めて低いように割り当てる必要があります。アプリケーションが複数の発行者を使用する場合、異なる発行者によって生成された値の間で衝突が防止されなければなりません。 「jti」クレームは、JWTの再生を防止するために使用できます。 「jti」の値は、大文字と小文字を区別する文字列です。このクレームの使用はオプションです。
Claim Names can be defined at will by those using JWTs. However, in order to prevent collisions, any new Claim Name should either be registered in the IANA "JSON Web Token Claims" registry established by Section 10.1 or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Claim Name.
クレーム名は、JWTを使用する人々によって自由に定義できます。ただし、衝突を防ぐために、新しいクレーム名は、セクション10.1で確立されたIANA「JSON Web Token Claims」レジストリに登録されるか、パブリック名である必要があります。パブリック名とは、衝突耐性のある名前を含む値のことです。いずれの場合も、名前または値の定義者は、クレーム名を定義するために使用する名前空間の一部を制御していることを確認するために合理的な注意を払う必要があります。
A producer and consumer of a JWT MAY agree to use Claim Names that are Private Names: names that are not Registered Claim Names (Section 4.1) or Public Claim Names (Section 4.2). Unlike Public Claim Names, Private Claim Names are subject to collision and should be used with caution.
JWTの生成者と消費者は、登録されたクレーム名（セクション4.1）または公開クレーム名（セクション4.2）ではないプライベートクレーム名を使用することに同意することができます。公開クレーム名とは異なり、プライベートクレーム名は衝突の可能性があるため、注意して使用する必要があります。
For a JWT object, the members of the JSON object represented by the JOSE Header describe the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. Depending upon whether the JWT is a JWS or JWE, the corresponding rules for the JOSE Header values apply.
JWTオブジェクトの場合、JOSEヘッダーによって表されるJSONオブジェクトのメンバーは、JWTに適用される暗号操作と、オプションでJWTの追加プロパティを説明します。 JWTがJWSまたはJWEであるかどうかに応じて、JOSEヘッダー値の対応するルールが適用されます。
This specification further specifies the use of the following Header Parameters in both the cases where the JWT is a JWS and where it is a JWE.
この仕様では、JWTがJWSである場合とJWEである場合の両方で、次のヘッダーパラメーターの使用方法がさらに指定されています。
The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used by JWT applications to declare the media type [IANA.MediaTypes] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL.
"typ" (Type) ヘッダーパラメーターは、[JWS] および [JWE] によって定義され、JWTアプリケーションで使用されます。このパラメーターは、JWTオブジェクトが含まれるアプリケーションデータ構造にもJWT以外の値が存在する場合に、JWTアプリケーションがこの完全なJWTのメディアタイプ[IANA.MediaTypes]を宣言するために使用されます。アプリケーションは、この値を使用して、存在する可能性のある異なる種類のオブジェクトを区別することができます。オブジェクトがJWTであることが既にわかっている場合、通常はアプリケーションによって使用されません。このパラメーターは、JWT実装によって無視されます。このパラメーターの処理は、JWTアプリケーションによって実行されます。存在する場合、このオブジェクトがJWTであることを示すために、値を「JWT」にすることが推奨されます（RECOMMENDED）。メディアタイプ名は大文字小文字を区別しないため、レガシー実装との互換性のために、常に大文字で「JWT」と綴ることが推奨されます（RECOMMENDED）。このヘッダーパラメーターの使用は選択できます（OPTIONAL）
In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is NOT RECOMMENDED. In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWT", to indicate that a Nested JWT is carried in this JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. See Appendix A.2 for an example of a Nested JWT.
通常、ネストされた署名または暗号化操作が使用されていない場合、このヘッダーパラメーターの使用は推奨されません（NOT RECOMMENDED）。ネストされた署名または暗号化が使用されている場合、このヘッダーパラメーターは必ず存在しなければなりません（MUST）。この場合、値は「JWT」である必要があります（MUST）。これは、このJWTにネストされたJWTが含まれていることを示すために使用されます。メディアタイプ名は大文字小文字を区別しないため、レガシー実装との互換性のために、常に大文字で「JWT」と綴ることが推奨されます（RECOMMENDED）。ネストされたJWTの例については、付録A.2を参照してください。
In some applications using encrypted JWTs, it is useful to have an unencrypted representation of some claims. This might be used, for instance, in application processing rules to determine whether and how to process the JWT before it is decrypted.
暗号化されたJWTを使用する一部のアプリケーションでは、一部のクレームの暗号化されていない表現が有用です。これは、例えば、JWTが復号化される前にJWTを処理する必要があるかどうか、およびどのように処理するかを決定するためのアプリケーション処理ルールで使用される場合があります。
This specification allows claims present in the JWT Claims Set to be replicated as Header Parameters in a JWT that is a JWE, as needed by the application. If such replicated claims are present, the application receiving them SHOULD verify that their values are identical, unless the application defines other specific processing rules for these claims. It is the responsibility of the application to ensure that only claims that are safe to be transmitted in an unencrypted manner are replicated as Header Parameter values in the JWT.
この仕様では、JWT Claims Setに存在するクレームを、アプリケーションが必要に応じてJWTのヘッダーパラメーターとして複製することができます。このような複製されたクレームが存在する場合、受信するアプリケーションは、これらの値が同一であることを検証することが推奨されます（RECOMMENDED）。ただし、アプリケーションがこれらのクレームに対して他の特定の処理ルールを定義している場合は、異なる値を許容することができます。JWT内のヘッダーパラメーター値として送信することが安全なクレームのみが、ヘッダーパラメーター値として複製されるように、アプリケーションが責任を持って確認する必要があります。
Section 10.4.1 of this specification registers the "iss" (issuer), "sub" (subject), and "aud" (audience) Header Parameter names for the purpose of providing unencrypted replicas of these claims in encrypted JWTs for applications that need them. Other specifications MAY similarly register other names that are registered Claim Names as Header Parameter names, as needed.
この仕様のセクション10.4.1では、「iss」（発行者）、 「sub」（主題）、および「aud」（聴衆）ヘッダーパラメーター名が登録され、これらのクレームの暗号化されていないレプリカを必要とするアプリケーションのために提供されます。他の仕様では、必要に応じて登録されたクレーム名をヘッダーパラメーター名として登録してもよいです（MAY）。
To support use cases in which the JWT content is secured by a means other than a signature and/or encryption contained within the JWT (such as a signature on a data structure containing the JWT), JWTs MAY also be created without a signature or encryption. An Unsecured JWT is a JWS using the "alg" Header Parameter value "none" and with the empty string for its JWS Signature value, as defined in the JWA specification [JWA]; it is an Unsecured JWS with the JWT Claims Set as its JWS Payload.
JWTの内容がJWT内に含まれる署名や暗号化以外の手段（例えば、JWTを含むデータ構造に対する署名）によって保護されるユースケースをサポートするために、署名または暗号化なしでJWTを作成してもよいです（MAY）。未保護のJWTは、JWA仕様[JWA]で定義されているように、「alg」ヘッダーパラメーター値「none」を使用し、JWSシグネチャ値に空の文字列を使用したJWSです。未保護のJWTは、JWSペイロードとしてJWT Claims Setを持つ未保護のJWSです。
The following example JOSE Header declares that the encoded object is an Unsecured JWT:
次の例のJOSEヘッダーは、エンコードされたオブジェクトが未保護のJWTであることを宣言しています。
{"alg":"none"}
{"alg":"none"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
JOSEヘッダーのUTF-8表現のオクテットをBase64urlエンコードすると、次のエンコードされたJOSEヘッダー値が生成されます:
eyJhbGciOiJub25lIn0
eyJhbGciOiJub25lIn0
The following is an example of a JWT Claims Set:
以下は、JWT Claims Setの例です:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Base64url encoding the octets of the UTF-8 representation of the JWT Claims Set yields this encoded JWS Payload (with line breaks for display purposes only):
JWT Claims SetのUTF-8表現のオクテットをBase64urlエンコードすると、次のエンコードされたJWSペイロード値が生成されます（表示目的のために改行が含まれています）:
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The encoded JWS Signature is the empty string.
エンコードされたJWSシグネチャは空の文字列です。
Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):
これらのエンコードされた部分をこの順序でピリオド（「.」）文字で連結すると、次の完全なJWTが生成されます（表示目的のために改行が含まれています）:
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
To create a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
JWTを作成するには、以下の手順を実行します。入力と出力の間に依存関係がない場合、手順の順序は重要ではありません。
1. Create a JWT Claims Set containing the desired claims. Note that whitespace is explicitly allowed in the representation and no canonicalization need be performed before encoding.
1. JWT Claims Setを作成し、必要なクレームを含めます。表現には明示的に空白が許可されており、エンコードする前に正準化する必要はありません。
2. Let the Message be the octets of the UTF-8 representation of the JWT Claims Set.
2. メッセージを、JWT Claims SetのUTF-8表現のオクテットとします。
4. Depending upon whether the JWT is a JWS or JWE, there are two cases:
4. JWTがJWSまたはJWEであるかに応じて、2つの場合があります:
* If the JWT is a JWS, create a JWS using the Message as the JWS Payload; all steps specified in [JWS] for creating a JWS MUST be followed.
* JWTがJWSである場合、JWSのペイロードとしてメッセージを使用してJWSを作成します。JWSを作成するために[JWS]で指定されたすべての手順を守らなければなりません。
* Else, if the JWT is a JWE, create a JWE using the Message as the plaintext for the JWE; all steps specified in [JWE] for creating a JWE MUST be followed.
* さもなければ、JWTがJWEである場合、メッセージをJWEの平文として使用してJWEを作成します。JWEを作成するために[JWE]で指定されたすべての手順を守らなければなりません。
5. If a nested signing or encryption operation will be performed, let the Message be the JWS or JWE, and return to Step 3, using a "cty" (content type) value of "JWT" in the new JOSE Header created in that step.
5. ネストされた署名または暗号化操作が実行される場合は、メッセージをJWSまたはJWEとし、そのステップで作成された新しいJOSEヘッダーで「cty」（コンテンツタイプ）値を「JWT」に設定して、ステップ3に戻ります。
6. Otherwise, let the resulting JWT be the JWS or JWE.
6. さもなければ、結果として得られたJWTをJWSまたはJWEとします。
When validating a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fail, then the JWT MUST be rejected -- that is, treated by the application as an invalid input.
JWTを検証する場合、以下の手順が実行されます。入力と出力の間に依存関係がない場合、手順の順序は重要ではありません。リストされた手順のいずれかが失敗した場合、JWTは無効な入力としてアプリケーションによって拒否される必要があります（MUST）。
1. Verify that the JWT contains at least one period ('.') character.
1. JWTに少なくとも1つのピリオド（'.'）文字が含まれていることを確認してください。
2. Let the Encoded JOSE Header be the portion of the JWT before the first period ('.') character.
2. JWTの最初のピリオド（'.'）文字の前にある部分をエンコードされたJOSEヘッダーとしてください。
3. Base64url decode the Encoded JOSE Header following the restriction that no line breaks, whitespace, or other additional characters have been used.
3. エンコードされたJOSEヘッダーを、改行、空白、その他の追加文字が使用されていない制限に従ってBase64urlデコードしてください。
4. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JOSE Header be this JSON object.
4. 変換されたオクテットシーケンスが、RFC 7159に準拠した完全に有効なJSONオブジェクトのUTF-8エンコードされた表現であることを検証してください。JOSEヘッダーはこのJSONオブジェクトとします。
5. Verify that the resulting JOSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood.
5. 変換されたJOSEヘッダーには、理解され、サポートされる構文と意味を持つパラメーターと値のみが含まれるか、理解されない場合に無視されることが指定されているパラメーターと値のみが含まれることを確認してください。
6. Determine whether the JWT is a JWS or a JWE using any of the methods described in Section 9 of [JWE].
6. JWTがJWSまたはJWEであるかどうかを、[JWE]のセクション9で説明されている方法のいずれかを使用して決定してください。
7. Depending upon whether the JWT is a JWS or JWE, there are two cases:
7. JWTがJWSまたはJWEであるかどうかに応じて、2つの場合があります。
* If the JWT is a JWS, follow the steps specified in [JWS] for validating a JWS. Let the Message be the result of base64url decoding the JWS Payload.
* JWTがJWSである場合、JWSの検証について[JWS]で指定された手順に従ってください。JWSペイロードをBase64urlデコードした結果をメッセージとしてください。
* Else, if the JWT is a JWE, follow the steps specified in [JWE] for validating a JWE. Let the Message be the resulting plaintext.
* さもなければ、JWTがJWEである場合、[JWE]で指定されたJWEの検証手順に従ってください。結果の平文をメッセージとしてください。
8. If the JOSE Header contains a "cty" (content type) value of "JWT", then the Message is a JWT that was the subject of nested signing or encryption operations. In this case, return to Step 1, using the Message as the JWT.
8. JOSEヘッダーに「cty」（コンテンツタイプ）値が「JWT」である場合、メッセージはネストされた署名または暗号化操作の対象となったJWTです。この場合、メッセージをJWTとして使用してステップ1に戻ります。
9. Otherwise, base64url decode the Message following the restriction that no line breaks, whitespace, or other additional characters have been used.
9. さもなければ、メッセージをBase64urlデコードしてください。改行、空白、その他の追加文字が使用されていない制限に従ってください。
10. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.
10. 変換されたオクテットシーケンスが、RFC 7159 [RFC7159]に準拠した完全に有効なJSONオブジェクトのUTF-8エンコードされた表現であることを検証してください。このJSONオブジェクトをJWT Claims Setとしてください。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it SHOULD reject the JWT.
最後に、特定のコンテキストで使用できるアルゴリズムはアプリケーションの決定によることに注意してください。JWTが正常に検証されたとしても、JWTで使用されるアルゴリズムがアプリケーションにとって許容可能でない場合、アプリケーションはJWTを拒否しなければなりません（MUST）。
Processing a JWT inevitably requires comparing known strings to members and values in JSON objects. For example, in checking what the algorithm is, the Unicode [UNICODE] string encoding "alg" will be checked against the member names in the JOSE Header to see if there is a matching Header Parameter name.
JWTを処理するには、既知の文字列をJSONオブジェクトのメンバーや値と比較する必要があります。 たとえば、アルゴリズムを確認する場合、Unicode [UNICODE] 文字エンコーディング「alg」は、JOSEヘッダーのメンバー名と照合され、ヘッダーパラメーター名と一致するかどうかを確認します。
The JSON rules for doing member name comparison are described in Section 8.3 of RFC 7159 [RFC7159]. Since the only string comparison operations that are performed are equality and inequality, the same rules can be used for comparing both member names and member values against known strings.
メンバー名の比較に使用されるJSONルールについては、RFC 7159 [RFC7159]のセクション8.3で説明されています。比較される文字列の比較操作が等価性と不等価性のみであるため、同じルールが既知の文字列に対してメンバー名とメンバー値の両方を比較するために使用できます。
These comparison rules MUST be used for all JSON string comparisons except in cases where the definition of the member explicitly calls out that a different comparison rule is to be used for that member value. In this specification, only the "typ" and "cty" member values do not use these comparison rules.
これらの比較ルールは、メンバーの定義がそのメンバー値に対して異なる比較ルールを使用することを明示的に指定していない限り、すべてのJSON文字列比較に使用しなければなりません（MUST）。 この仕様では、「typ」と「cty」のメンバー値のみがこれらの比較ルールを使用しないことが指定されています。
Some applications may include case-insensitive information in a case- sensitive value, such as including a DNS name as part of the "iss" (issuer) claim value. In those cases, the application may need to define a convention for the canonical case to use for representing the case-insensitive portions, such as lowercasing them, if more than one party might need to produce the same value so that they can be compared. (However, if all other parties consume whatever value the producing party emitted verbatim without attempting to compare it to an independently produced value, then the case used by the producer will not matter.)
いくつかのアプリケーションでは、DNS名を「iss」（発行者）クレーム値の一部として含めるなど、大文字小文字を区別する値に大文字小文字を含める場合があります。 その場合、複数の当事者が同じ値を生成する必要がある場合は、比較できるように、大文字小文字を小文字に変換するなど、大文字小文字を区別しない部分を表すための正準なケースの規約を定義する必要があります。 （ただし、他のすべての当事者が、独立して生成された値と比較することなく、生成当事者が出力した値をそのまま消費する場合、生成者が使用したケースは重要ではありません。）
This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").
このセクションでは、この仕様のアルゴリズムと機能のうち、実装する必要があるものを定義します。この仕様を使用するアプリケーションは、使用する実装に対して追加の要件を課すことができます。たとえば、1つのアプリケーションは、暗号化されたJWTとネストされたJWTのサポートを必要とし、別のアプリケーションは、P-256曲線とSHA-256ハッシュアルゴリズム（「ES256」）を使用して楕円曲線デジタル署名アルゴリズム（ECDSA）でJWTを署名するサポートを必要とする場合があります。
Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations. It is RECOMMENDED that implementations also support RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm ("RS256") and ECDSA using the P-256 curve and the SHA-256 hash algorithm ("ES256"). Support for other algorithms and key sizes is OPTIONAL.
JSON Web Algorithmsで指定された署名およびMACアルゴリズムのうち、準拠するJWT実装で実装する必要があるのは、HMAC SHA-256（「HS256」）および「none」のみです。実装は、RSASSA-PKCS1-v1_5を使用したSHA-256ハッシュアルゴリズム（「RS256」）およびP-256曲線とSHA-256ハッシュアルゴリズムを使用したECDSA（「ES256」）もサポートすることが推奨されます（RECOMMENDED）。他のアルゴリズムおよびキーサイズのサポートは選択できます（OPTIONAL）。
Support for encrypted JWTs is OPTIONAL. If an implementation provides encryption capabilities, of the encryption algorithms specified in [JWA], only RSAES-PKCS1-v1_5 with 2048-bit keys ("RSA1_5"), AES Key Wrap with 128- and 256-bit keys ("A128KW" and "A256KW"), and the composite authenticated encryption algorithm using AES-CBC and HMAC SHA-2 ("A128CBC-HS256" and "A256CBC-HS512") MUST be implemented by conforming implementations. It is RECOMMENDED that implementations also support using Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) to agree upon a key used to wrap the Content Encryption Key ("ECDH-ES+A128KW" and "ECDH-ES+A256KW") and AES in Galois/Counter Mode (GCM) with 128- and 256-bit keys ("A128GCM" and "A256GCM"). Support for other algorithms and key sizes is OPTIONAL.
暗号化されたJWTのサポートは選択できます（OPTIONAL）。実装が暗号化機能を提供する場合、[JWA]で指定された暗号化アルゴリズムのうち、2048ビットの鍵を使用したRSAES-PKCS1-v1_5（「RSA1_5」）、128ビットおよび256ビットの鍵を使用したAES Key Wrap（「A128KW」と「A256KW」）、およびAES-CBCおよびHMAC SHA-2を使用した複合認証暗号アルゴリズム（「A128CBC-HS256」と「A256CBC-HS512」）のみが、準拠する実装で必ず実装しなければなりません（MUST）。実装は、ECDH-ES（Elliptic Curve Diffie-Hellman Ephemeral Static）を使用してContent Encryption Keyをラップするために使用されるキーに同意するためにECDH-ES+A128KWおよびECDH-ES+A256KWを使用すること、および128ビットおよび256ビットの鍵を使用したAES in Galois/Counter Mode（GCM）（「A128GCM」と「A256GCM」）もサポートすることが推奨されます（RECOMMENDED）。他のアルゴリズムおよびキーサイズのサポートは選択できます（OPTIONAL）。
Support for Nested JWTs is OPTIONAL.
ネストされたJWTのサポートは選択できます（OPTIONAL）。
This specification registers the URN "urn:ietf:params:oauth:token-type:jwt" for use by applications that declare content types using URIs (rather than, for instance, media types) to indicate that the content referred to is a JWT.
この仕様では、コンテンツタイプを示すためにメディアタイプの代わりにURIを使用するアプリケーションが、参照されるコンテンツがJWTであることを示すために使用するためにURN「urn:ietf:params:oauth:token-type:jwt」を登録します。
This section establishes the IANA "JSON Web Token Claims" registry for JWT Claim Names. The registry records the Claim Name and a reference to the specification that defines it. This section registers the Claim Names defined in Section 4.1.
This section establishes the IANA "JSON Web Token Claims" registry for JWT Claim Names. The registry records the Claim Name and a reference to the specification that defines it. This section registers the Claim Names defined in Section 4.1.
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example").
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example").
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear.
Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear.
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
Claim Name: The name requested (e.g., "iss"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
Claim Name: The name requested (e.g., "iss"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
Claim Description: Brief description of the claim (e.g., "Issuer").
Claim Description: Brief description of the claim (e.g., "Issuer").
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
This section registers the value "token-type:jwt" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755], which can be used to indicate that the content is a JWT.
This section registers the value "token-type:jwt" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755], which can be used to indicate that the content is a JWT.
This section registers the "application/jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in RFC 6838 [RFC6838], which can be used to indicate that the content is a JWT.
This section registers the "application/jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in RFC 6838 [RFC6838], which can be used to indicate that the content is a JWT.
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
This section registers specific Claim Names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] for use by claims replicated as Header Parameters in JWEs, per Section 5.3.
This section registers specific Claim Names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] for use by claims replicated as Header Parameters in JWEs, per Section 5.3.
All of the security issues that are pertinent to any cryptographic application must be addressed by JWT/JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
All of the security issues that are pertinent to any cryptographic application must be addressed by JWT/JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 ("JSON Security Considerations") and 10.13 ("Unicode Comparison Security Considerations") of [JWS] apply equally to the JWT Claims Set in the same manner that they do to the JOSE Header.
All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 ("JSON Security Considerations") and 10.13 ("Unicode Comparison Security Considerations") of [JWS] apply equally to the JWT Claims Set in the same manner that they do to the JOSE Header.
The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.
The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.
While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.
Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.
A JWT may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted using protocols utilizing encryption that support endpoint authentication, such as Transport Layer Security (TLS). Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues.
A JWT may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted using protocols utilizing encryption that support endpoint authentication, such as Transport Layer Security (TLS). Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues.
This section contains examples of JWTs. For other example JWTs, see Section 6.1 of this document and Appendices A.1 - A.3 of [JWS].
This section contains examples of JWTs. For other example JWTs, see Section 6.1 of this document and Appendices A.1 - A.3 of [JWS].
This example encrypts the same claims as used in Section 3.1 to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
This example encrypts the same claims as used in Section 3.1 to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
The following example JOSE Header declares that:
The following example JOSE Header declares that:
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
Other than using the octets of the UTF-8 representation of the JWT Claims Set from Section 3.1 as the plaintext value, the computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], including the keys used.
Other than using the octets of the UTF-8 representation of the JWT Claims Set from Section 3.1 as the plaintext value, the computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], including the keys used.
The final result in this example (with line breaks for display purposes only) is:
The final result in this example (with line breaks for display purposes only) is:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52 YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a 1rZgN5TiysnmzTROF869lQ. AxY8DCtDaGlsbGljb3RoZQ. MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8. fiK51VwhsxJ-siBMR-YFiA
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52 YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a 1rZgN5TiysnmzTROF869lQ. AxY8DCtDaGlsbGljb3RoZQ. MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8. fiK51VwhsxJ-siBMR-YFiA
This example shows how a JWT can be used as the payload of a JWE or JWS to create a Nested JWT. In this case, the JWT Claims Set is first signed, and then encrypted.
This example shows how a JWT can be used as the payload of a JWE or JWS to create a Nested JWT. In this case, the JWT Claims Set is first signed, and then encrypted.
The inner signed JWT is identical to the example in Appendix A.2 of [JWS]. Therefore, its computation is not repeated here. This example then encrypts this inner JWT to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
The inner signed JWT is identical to the example in Appendix A.2 of [JWS]. Therefore, its computation is not repeated here. This example then encrypts this inner JWT to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
The following example JOSE Header declares that:
The following example JOSE Header declares that:
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
The computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], other than that different JOSE Header, plaintext, JWE Initialization Vector, and Content Encryption Key values are used. (The RSA key used is the same.)
The computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], other than that different JOSE Header, plaintext, JWE Initialization Vector, and Content Encryption Key values are used. (The RSA key used is the same.)
The JWE Initialization Vector value used (using JSON array notation) is:
The JWE Initialization Vector value used (using JSON array notation) is:
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
This example uses the Content Encryption Key represented by the base64url-encoded value below:
This example uses the Content Encryption Key represented by the base64url-encoded value below:
GawgguFyGrWKav7AX4VKUg
GawgguFyGrWKav7AX4VKUg
The final result for this Nested JWT (with line breaks for display purposes only) is:
The final result for this Nested JWT (with line breaks for display purposes only) is:
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
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
Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating security tokens with greater expressivity and more security options than supported by JWTs. However, the cost of this flexibility and expressiveness is both size and complexity. SAML's use of XML [W3C.CR-xml11-20060816] and XML Digital Signature (DSIG) [RFC3275] contributes to the size of SAML Assertions; its use of XML and especially XML Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their complexity.
Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating security tokens with greater expressivity and more security options than supported by JWTs. However, the cost of this flexibility and expressiveness is both size and complexity. SAML's use of XML [W3C.CR-xml11-20060816] and XML Digital Signature (DSIG) [RFC3275] contributes to the size of SAML Assertions; its use of XML and especially XML Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their complexity.
JWTs are intended to provide a simple security token format that is small enough to fit into HTTP headers and query arguments in URIs. It does this by supporting a much simpler token model than SAML and using the JSON [RFC7159] object encoding syntax. It also supports securing tokens using Message Authentication Codes (MACs) and digital signatures using a smaller (and less flexible) format than XML DSIG.
JWTs are intended to provide a simple security token format that is small enough to fit into HTTP headers and query arguments in URIs. It does this by supporting a much simpler token model than SAML and using the JSON [RFC7159] object encoding syntax. It also supports securing tokens using Message Authentication Codes (MACs) and digital signatures using a smaller (and less flexible) format than XML DSIG.
Therefore, while JWTs can do some of the things SAML Assertions do, JWTs are not intended as a full replacement for SAML Assertions, but rather as a token format to be used when ease of implementation or compactness are considerations.
Therefore, while JWTs can do some of the things SAML Assertions do, JWTs are not intended as a full replacement for SAML Assertions, but rather as a token format to be used when ease of implementation or compactness are considerations.
SAML Assertions are always statements made by an entity about a subject. JWTs are often used in the same manner, with the entity making the statements being represented by the "iss" (issuer) claim, and the subject being represented by the "sub" (subject) claim. However, with these claims being optional, other uses of the JWT format are also permitted.
SAML Assertions are always statements made by an entity about a subject. JWTs are often used in the same manner, with the entity making the statements being represented by the "iss" (issuer) claim, and the subject being represented by the "sub" (subject) claim. However, with these claims being optional, other uses of the JWT format are also permitted.
Both JWTs and SWTs [SWT], at their core, enable sets of claims to be communicated between applications. For SWTs, both the claim names and claim values are strings. For JWTs, while claim names are strings, claim values can be any JSON type. Both token types offer cryptographic protection of their content: SWTs with HMAC SHA-256 and JWTs with a choice of algorithms, including signature, MAC, and encryption algorithms.
Both JWTs and SWTs [SWT], at their core, enable sets of claims to be communicated between applications. For SWTs, both the claim names and claim values are strings. For JWTs, while claim names are strings, claim values can be any JSON type. Both token types offer cryptographic protection of their content: SWTs with HMAC SHA-256 and JWTs with a choice of algorithms, including signature, MAC, and encryption algorithms.
The authors acknowledge that the design of JWTs was intentionally influenced by the design and simplicity of SWTs [SWT] and ideas for JSON tokens that Dick Hardt discussed within the OpenID community.
The authors acknowledge that the design of JWTs was intentionally influenced by the design and simplicity of SWTs [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 [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document.
Solutions for signing JSON content were previously explored by Magic Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document.
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:
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, 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.
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 and Derek Atkins chaired the OAuth working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
Hannes Tschofenig and Derek Atkins chaired the OAuth working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.