JWT (15.12.2022 3M)

Question 1

JWT standard number

Answer 1

rfc7519

Question 2

What is JWT abstractly?

Answer 2

JSON Web Token (JWT) is a compact claims representation format
intended for space-constrained environments such as HTTP Authorization headers and URI query parameters. Used to transfer claims between two parties.

The claims in a JWT are encoded as a JavaScript Object Notation (JSON).

JWT must be JWS or JWE.

JWS enables the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC).
JWE enables the claims to be encrypted.

Question 3

What is JWT by definition of rfc7519?

Answer 3

A string representing a set of claims as a JSON object that is encoded in encoded JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.

Question 4

What is JWT Claim Set by definition of rfc7519?

Answer 4

A JSON object that contains the claims conveyed by the JWT.

Question 5

What is Claim by definition of rfc7519?

Answer 5

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.

Question 6

What is Nested JWT?

Answer 6

The idea behind nested JWT is you create the JWT from JWT Claims Set first using JWS or JWE. And then use the resulting JWT and create another JWT using JWS or JWE.

While it’s technically possible to perform the operations in any order to create a nested JWT. A more common approach is to create JWS from JWT Claims Set and then create JWE from the resulting JWS.

If JWT is carrying Nested JWT, “cty” parameter of JOSE must have the value “JWT”

Question 7

What is StringOrURI by definition of rfc7519? How values of this type are compared?

Answer 7

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. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.

Question 8

What is NumericDate by definition of rfc7519?

Answer 8

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.

Question 9

How many claims can Claim Set contain?

Answer 9

Zero or more

Question 10

What does JOSE stand for?

Answer 10

JOSE (Javascript Object Signing And Encryption) is a header used in JWT. This is not HTTP header, but just the first part of JWT string. It looks like a JSON object. For example {“typ”:”JWT”, “alg”:”HS256”}

It’s important to understand that JOSE header is part of JWS and JWE standards. Which are used as “container” for JWT.

The contents of the JOSE Header describe the cryptographic operations applied to the JWT and optionally, additional properties of the JWT.

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.

Question 11

How JWT is represented?

Answer 11

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.

Question 12

How to manage JWT Claim Names duplication?

Answer 12

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

Question 13

What is the set of claims that a JWT must contain to be considered valid?

Answer 13

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.

Question 13

Name three classes of JWT Claim Names.

Answer 13

Registered Claim Names, Public Claim Names, and Private Claim Names.

Question 14

What is Registered Claim Names class?

Answer 14

The Registered Claim Names are registered in the IANA “JSON Web Token Claims”.

None of the Registered Claim Names 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.

Question 15

Name Registered Claim Names defined in rfc7519.

Answer 15

• “iss” (Issuer) Claim
• “sub” (Subject) Claim
• “aud” (Audience) Claim
• “exp” (Expiration Time) Claim
• “nbf” (Not Before) Claim
• “iat” (Issued At) Claim
• “jti” (JWT ID) Claim

Question 16

Describe “iss” (Issuer) Claim.

Answer 16

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.

For example URI of authorization server: “https://login.backup.net”

Question 17

Describe “sub” (Subject) Claim.

Answer 17

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.

For example id of the user, for which claims are about: “< guid >”

Question 18

Describe “aud” (Audience) Claim.

Answer 18

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.

Question 19

Describe “exp” (Expiration Time) Claim.

Answer 19

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

Question 20

Describe “nbf” (Not Before) Claim.

Answer 20

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.

Question 21

Describe “iat” (Issued At) Claim.

Answer 21

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.

Question 22

Describe “jti” (JWT ID) Claim.

Answer 22

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.

Question 23

What is Public Claim Names class?

Answer 23

Class defines custom claims for public consumption. If you create public claims, you must either register them in IANA “JSON Web Token Claims” or use collision-resistant names through namespacing and take reasonable precautions to make sure you are in control of the namespace you use.

Question 24

What is Private Claim Names class?

Answer 24

A producer and consumer of a JWT MAY agree to use Claim Names that are Private Names: names that are not Registered Claim Names or Public Claim Names.

This is application specific claims. You must avoid using the same names as for public claim names and registered claims names.

And It’s recommended to be precautions because of collisions. You can still use namespaces to prevent collisions.

Question 25

Tell about Replicating Claims as Header Parameters.

Answer 25

In some applications using JWE, 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.

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

For example, specification registers the “iss” (issuer), “sub” (subject), and “aud” (audience) Header Parameter names for the purpose of providing unencrypted replicas of these claims in JWE for applications that need them.

Question 26

What is Unsecured JWT? Why you may need unsecured JWT?

Answer 26

An Unsecured JWT is a JWS using the “alg” Header Parameter value “none” and with the empty string for its JWS Signature value.

It means that Unsecured JWT contains claim set, but it’s no way to validate it intergrety or confidentiality.

The Unsecured JWTs are designed to allow other ways of securing JWTs. For example secured transport, signing/encryption of data structure that incapsulate JWT.

Example:

Header
{“alg”:”none”}

Payload
{“iss”:”joe”, “exp”:1300819380, “http://example.com/is_root”:true}

eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.

Question 27

Is JWT possible to be used separately from JWS or JWE?

Answer 27

No. JWT must conform to either JWS or JWE.