JSON Web Token(JWT)
Introduction to JWT
From this quick article, I am going to give you a basic understanding of JSON web tokens, the way it works, and finally some advantages of JWT. First, let’s see what is called by a JSON web token.
What is a JSON Web Token?
The token we will be using, contain JSON data and this will call as JSON Web Token. JWT is a JSON object that is defined as a safe way to represent a set of information between two parties.
A JWT typically looks like this:
JSON Web Token is an open standard (RFC 7519). It defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a or a public/private key pair using RSA or ECDSA. JWTs can be encrypted to also provide secrecy between parties. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties.
JSON Web Token structure
The token is composed of three parts separated by dots (.) and they are as follows,
- Header
- Payload
- Signature
Therefore, JWT is just a string with the following format.
Header.payload.signature — xxxxx.yyyyy.zzzzz
Header
The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm is being used. Headers contain metadata about the type of token and the cryptographic algorithms used to secure its contents.
The header is comprised of a set of Header Parameters that typically consist of a name/value pair: the hashing algorithm being used (e.g., HMAC SHA256 or RSA) and the type of the JWT.
For example:
{
“alg”: “HS256”,
“typ”: “JWT”
}
Payload
This contains the claims. Claims are statements about an entity and additional data. They are verifiable security statements, such as the identity of the user and the permissions they are allowed. There are three types of claims.
· Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience).
· Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
· Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.
In this example, our entity is a user.
{
“sub”: “1234567890”,
“name”: “Ann Michelle”,
“admin”: true
}
When working with JWT claims, you should be aware of the different claim types and naming rules
Signature
Signature is used to validate that the token is trustworthy and has not been tampered with. When you use a JWT, you must check its signature before storing and using it. To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithms specified in the header, and sign that.
For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)
The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.
How does it work?
Authentication using JWT can be simply described as follows.
A user inserts his login data in the application or a trusted authentication service.
When the authentication is successful, the service grants a token to the user containing information about this user (unique identifier, full name, role, etc.).
When further addressing the application, the token is transferred in the user’s requests (in cookies, request headers, post- or get-parameters, etc.).
After receiving the token, the application verifies its signature.
It makes sure the signature is valid; the application extracts the user’s data out of the payload part and authorizes the user.
Advantages of using JWT compared with a classic authentication scheme
The application does not have to issue and verify tokens by itself, as a separate authentication service is often used for these purposes.
Token use makes it possible not to store information about all the issued tokens. When a user addresses the application, he transfers their token. The application verifies the signature and extracts necessary fields out of the payload.
The application can store almost any data in the payload part that can substantially increase the application efficiency if its architecture is correct.
It is possible to organize a single-entry point to various services with the same login data. After going through the authentication procedure once, the user with the token will be able to get access to those resources that trust this authentication service.
Hope you enjoyed my article and think this would be helpful for you to know something on JWT.
Thank You !
