JWT (JSON Web Token) is a very popular way to do user authorization in microservices. It is a standard which is used to create access tokens for an application and enables secure communication between between two parties.
The Industry standard specification RFC7519 outlines how information in JWT should be structured.
It is widely used in microservices based architecture, so let us understand why is this a popular way for authorization.
HTTP is a stateless protocol because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends the connection between the browser and the server is also lost.
In a traditional monolithic web application, once a user is authenticated a session object is created on the server which contains user preferences, access rights etc and a session id is generated.
This session id is used in all subsequent requests to the application to associate the request with the current session.
This works well in the context of monolithic application but this is not suited to work well with microservices based architecture because microservices are designed to be self-contained and stateless so they can be deployed separately and scaled across multiple servers or containers.
When each service is deployed independently , if we build a separate service to store the session and fetch user session details with every request then it will not only increases the load on this session management service but it will also become a bottleneck and If you store session in each service then replicating the user details in each service and managing it becomes another problem.
Therefore we need a better solution and JWT helps to solve this problem.
In this design the authentication server generates a token that certifies the user identity, and sends it to the client.The client will send the token back to the server for every subsequent request, so the server knows the request comes from a particular identity.
When a request is made by the client, it first communicates with the Authorization server and gets an access-token which is encrypted. This access token contains user details and it is sent to microservices. Services can now validate and decode the token to know which user is accessing it
This architecture proves to be very effective in modern web and microservices based application, where after the user is authenticated we perform API requests either to a REST or a GraphQL API.
JWT normally contains a header (information on encryption algorithm) and a payload (information on the authorization and its expiry), signed with the identity service secret (HMAC) or private key (RSA).
In the above picture, left hand side contains JWT which is Base64 encoded and right side shows decoded JWT
The payload part of the JWT is what contains the information about the user, so you can have roles of the user etc added in that part . Since JWTs can be easily decoded by any Base 64 decoding library you should not put any passwords or confidential information in it.
Header and the signature part in JWT is what lends authenticity to this.
Header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
Signature is used to validate if the token is trustworthy and has not been tampered with.
The purpose of signature is not to encrypt or hide the message in the token but it is to ensure that the token is not tampered or changed after its issued by the server.
JWTs are signed with a secret key when they are generated and then validated with a secret key upon receipt so we can verify that they haven’t been modified in transit.
Transmitting JWT over HTTPS ensures confidentiality and integrity.
JWT based authorization offers scalable and efficient solution in a microservices based architecture but there are some cons of it too.
If a user account needs to be blocked or deactivated, the application will have to wait for the token to expire.
If a user needs to change their password and if an authentication has been performed beforehand, then a token generated with the previous password will still be valid until expiry.
To deal with these challenges, some JWT libraries add a layer above the standard specification and allow refresh token mechanisms as well as some features like forcing a user to re-authenticate, if need be.
JWT enables securing REST APIs or any stateless back-end service. It might not be the most secure one but using JWT along with right libraries helps to handle most of the common attack vectors.
Let me know your thoughts in the comments. Thank You
