What is the structure of a JSON Web Token

JSON Web Tokens are made by using (.) Is composed of three separate parts, which are:

• Header
• Payload
• Signature (Signature)

Because of the above organization, a JWT usually looks like this.

xxxxx.yyyyy.zzzzz
Copy the code

Let’s analyze the above form in detail.

Header

In the header data

It contains two parts: the type of token, in this case the character JWT, and the signature encryption algorithm used, such as SHA256 or RSA.

For example, the following format:

{
"alg": "HS256",
"typ": "JWT"
}
Copy the code

Then hash the above JSON data format using the Base64Url algorithm, and you get the first part of JWT.

Payload

The second part of JWT is the load, which consists of claims. Claims are entities (usually users) and other pieces of information.

There are three types of claims

.

and

.

Registered Claims: These claims are predefined, and the contents of these configurations are not required but recommended, and therefore provide a set of conventions for use. For example, iss (Issuer), exp (expiration time), Sub (Subject), AUD (audience), and some more configurations.

Note that these conventions are commonly known as configurations of only three characters to facilitate the compression of data volumes.

Public Claims: These data can be defined freely by JWT users, but to avoid conflicts, you need to refer to the IANA JSON Web Token Registry to define them, or define them as URIs, and avoid possible conflicts.

Private Claims: These are custom claims that are used to convert data during short data transfers. This data is not defined between registered and public.

An example load:

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Copy the code

Payload

Is also encrypted with Base64Url, and this part of the encrypted content makes up the second part of JWT.

Please note that the signature for this part of the token has been tampered with. However, this section can still be decrypted, so do not put any secret keys in this section unless your secret key is already encrypted.

Signature (Signature)

To create an encrypted part, you need to have the encoded header and payload, and then you need a secret key and an encryption algorithm already specified in the header to sign it.

For example, if you want to use the HMAC SHA256 algorithm for signature, then the data used in this algorithm is:

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Copy the code

The signature is used to verify that the Token data is not tampered with during transmission.

If your token is signed with a private key, you can also verify that the JWT sender is using a valid signature.

Put it all together

The contents of the three parts are encoded using Base64-URL, and the data of each part is directly used with dot (.). To ensure that token data can be easily transmitted over the network in HTTP and HTML environments.

For tokens that use XML, such as SAML, JWT is much cleaner and more efficient.

Here is an example of a JWT token that uses header information, payload information, and a digital signature combined together:

If you want to use JWT and decrypt an existing JWT token, you can use jwt. IO /#debugger-i… The website provides tools to program JWT strings, checksum and produce a JWT token.