Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7519 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Token (JWT)
Abstract
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.
Status of This Memo
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.
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.
Jones, et al. Standards Track [Page 1]
RFC 7519 JSON Web Token (JWT) May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones, et al. Standards Track [Page 2]
RFC 7519 JSON Web Token (JWT) May 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 6
3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Registered Claim Names . . . . . . . . . . . . . . . . . 9
4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . 9
4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . 9
4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9
4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . 10
4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . 10
4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . 10
4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10
5. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11
5.3. Replicating Claims as Header Parameters . . . . . . . . . 12
6. Unsecured JWTs . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Example Unsecured JWT . . . . . . . . . . . . . . . . . . 12
7. Creating and Validating JWTs . . . . . . . . . . . . . . . . 13
7.1. Creating a JWT . . . . . . . . . . . . . . . . . . . . . 13
7.2. Validating a JWT . . . . . . . . . . . . . . . . . . . . 14
7.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15
8. Implementation Requirements . . . . . . . . . . . . . . . . . 16
9. URI for Declaring that Content is a JWT . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
10.1.1. Registration Template . . . . . . . . . . . . . . . 18
10.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
10.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . 19
10.2.1. Registry Contents . . . . . . . . . . . . . . . . . 19
10.3. Media Type Registration . . . . . . . . . . . . . . . . 20
10.3.1. Registry Contents . . . . . . . . . . . . . . . . . 20
10.4. Header Parameter Names Registration . . . . . . . . . . 20
10.4.1. Registry Contents . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . 21
11.2. Signing and Encryption Order . . . . . . . . . . . . . . 21
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Jones, et al. Standards Track [Page 3]
RFC 7519 JSON Web Token (JWT) May 2015
Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 26
A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 26
A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . 26
Appendix B. Relationship of JWTs to SAML Assertions . . . . . . 28
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
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.
The suggested pronunciation of JWT is the same as the English word
"jot".
1.1. Notational Conventions
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.
2. Terminology
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].
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].
The terms "Ciphertext", "Digital Signature", "Message Authentication
Code (MAC)", and "Plaintext" are defined by the "Internet Security
Glossary, Version 2" [RFC4949].
Jones, et al. Standards Track [Page 4]
RFC 7519 JSON Web Token (JWT) May 2015
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.
JWT Claims Set
A JSON object that contains the claims conveyed by the JWT.
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.
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.
Unsecured JWT
A JWT whose claims are not integrity protected or encrypted.
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.
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.
Jones, et al. Standards Track [Page 5]
RFC 7519 JSON Web Token (JWT) May 2015
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.
3. JSON Web Token (JWT) Overview
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].
The member names within the JWT Claims Set are referred to as Claim
Names. The corresponding values are referred to as Claim Values.
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.
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.
Jones, et al. Standards Track [Page 6]
RFC 7519 JSON Web Token (JWT) May 2015
3.1. Example JWT
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:
{"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:
[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:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The following is an example of a JWT Claims Set:
{"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:
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
Jones, et al. Standards Track [Page 7]
RFC 7519 JSON Web Token (JWT) May 2015
Base64url encoding the JWS Payload yields this encoded JWS Payload
(with line breaks for display purposes only):
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:
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):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
This computation is illustrated in more detail in Appendix A.1 of
[JWS]. See Appendix A.1 for an example of an encrypted JWT.
4. JWT Claims
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].
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.
There are three classes of JWT Claim Names: Registered Claim Names,
Public Claim Names, and Private Claim Names.
Jones, et al. Standards Track [Page 8]
RFC 7519 JSON Web Token (JWT) May 2015
4.1. Registered Claim Names
The following Claim Names are registered in the IANA "JSON Web Token
Claims" registry established by