Nested JSON Web Token (JWT)
Avaya
425 Legget Drive
Ottawa
Ontario
Canada
+1-613-595-9106
rifaat.ietf@gmail.com
Security
OAuth Working Group
OAuth
NJWT
Nested JWT
This specification extends the scope of the Nested JSON Web Token (JWT) to
allow the enclosing JWT to contain its own Claims Set in addition to the enclosed JWT.
JSON Web Token (JWT) is a mechanism that is used to transfer claims between
two parties across security domains. Nested JWT is a JWT in which the payload
is another JWT. The current specification does not define a means by which
the enclosing JWT could have its own Claims Set, only the enclosed JWT would
have claims.
This specification extends the scope of the Nested JWT to allow the enclosing
JWT to contain its own Claims Set in addition to the enclosed JWT.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .
RFC7519 defines Nested JWT as 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.
To indicate that the payload of an enclosing JWT is yet another JWT, the
value of the Content Type Parameter of the JOSE header, i.e. "cty", must be
set to "JWT", which means that the enclosing JWT cannot have its own claims.
This document updates the enclosing JWT content to allow it to represent a
Claims Set and an enclosed JWT, using JSON data structures, and updates the
Content Type to indicate this new nested content.
The use case is for a telephony application that is based on the "Native Apps
Using the Browser" flow defined in RFC8252.
The Native App needs access to a telephony and non-telephony services that are
controlled by different authorization servers, where the Native App can validate
tokens issued by only one of these authorization servers.
The Native App starts the process by interacting with a Client that requires the
user to authenticate itself using a Browser.
The Browser starts by contacting an AS, which redirects it to an OP. The user
authenticates to the OP and obtains a Code, and then gets redirected back to AS.
The Native App gets access to the Code, then sends the Code to the AS, which then
interacts with the OP to exchange the Code for an ID Token and OP Access Token.
Since the Native App has no way of validating the OP Access Token, when the AS
creates an AS Access Token, it embeds the OP Access Token inside the AS Access
Token, and returns it back to the Native App.
The Native App gets the AS Access Token and is able to validate it and extract
the OP Access Token, and access the different services protected with these tokens.
The JOSE Header contains an optional parameter that could be used to
indicate the type of the payload of a JWT. With a typical Nested JWT, the
value of the "cty" header must be "JWT". To indicate that the payload
contains a Claims Set in addition to the JWT, the value of the "cty" header
must be "NJWT".
The payload of the enclosing JWT is JSON object that contains the Claims Set,
and one new claim that is used to hold the enclosed JWT.
This document defines a new claim, "njwt", that is used to contain the enclosed JWT.
Key words for use in RFCs to Indicate Requirement Levels