A JSON Web Token (JWT) is an open standard (RFC 7519) that specifies a compact and self-contained method for securely transmitting information as a JSON object between parties. Since it is digitally signed, this information can be checked and trusted. A hidden or a public/private key pair may be used to sign JWT.
Structure of JWT is broken up to three pieces and follows as:
So, what does HEADER, PAYLOAD, and SIGNATURE mean?
The type of token, which is JWT, and the hashing algorithm, such as HMAC SHA256 or RSA, are usually included in the header.
The first portion of the JWT is made up of this JSON that has been Base64Url encoded.
The payload, which includes the arguments, is the second component of the token. The majority of our JWT, also known as the JWT Claims, will be carried by the payload. This is where we’ll store the data we want to send as well as other details about our token. We can make a range of statements for you. This includes registered claims , public claims, and private claims.
What do I mean by registered claims , public claims, and private claims?
Registered Claims: A collection of predefined claims that aren’t required but are highly recommended in order to have a set of useful, interoperable claims.
Public Claims: Those that use JWT should describe them as they see fit.
They should, however, be specified to avoid collisions.
Private Claims: These are non-registered or public claims that were made to exchange information between parties that agreed to use them.
An example of payloads:
Our final part of the JWT is the signature. You must sign the encoded header, the encoded payload, a secret, and the algorithm defined in the header to construct the signature element.
Then it’s time to bring it together. The following shows a JWT that is signed with a secret and has the previous header and payload encoded.
I hope this blog has helped you understand JWT a bit more, and will help you in the future! Thanks for reading.