As the world is moving from Monolithic application to Microservice architecture, the concept of SessionID & Session management is becoming obsolete in industry nowadays.
Whenever a user (client) logs into the system, a session is created in the server and a sessionID is generated which is returned to client through cookies. Now in the next subsequent request sent by the client, it has to send the SessionID as cookies again to the server, the server verifies that ID and then only a particular resource in the server is given access to the client.
Which summarizes that for every request for API call, client must send the SessionID to the server. Then as the client logs out of the system then that session is deleted from the server.
As we can see in the above image, there are 3 backend services to which the client is communicating through a load balancer. The Session is managed with shared Redis cache in microservice system.
But there are problem using this scheme that scalability is a problem, and if the Redis cache instance goes down then all the sessions will be deleted for current logged in users and the entire system will remain non-functional, though the services are live.
To solve this problem JWT (JSON Web Token) comes into picture...
Whenever we visit the doctor, he writes a prescription, then in the next visit we must take the prescription along with us for reference, because the doctor may forget about the patient. So the analogy is, the prescription is like a token with which a patient can authorize itself to the doctor that he is an old patient and neither the patient nor the doctor have to spend time to discuss about the disease again.
In this image picture, there is a Authorization Server with a database along with other databases which are required and no Redis Cache. The Authorization server is the JWT authorization server, which is responsible for generating tokens and issuing it to client.
When a client (user) tries to log into the system, he enters Username and Password, these usernames and passwords are stored in the databases associated with the authorization server.
After the user is logged in successfully with correct credentials, the Authorization server generates a JWT (json web token) and returns it to the client. Now the client can make subsequent API calls or request for resources with the token issued to it.
Client can store the token in local storage or cache of the browser and when it needs to make a API call, it must send that token in header of the request. The service will validate the JWT which is sent along with the request. Once the token gets validated then, its allowed to access the information.
This is what a JWT looks like, it has three parts which are separated by two periods.
- First part: HEADER (contains the algorithm and token type)
- Second part: PAYLOAD (contains the data: name, sub - whom the token refers to, timestamp)
- Third part: SIGNATURE (contains Base64 encoded header and payload in the form of => base64UrlEncode(header) + "." + base64UrlEncode(payload) and the Client Secret)
With the help of Client Secret it is verified that the token is an authentic token or not, because Payload's data can change but Client Secret doesn't change, and if it changes then the token is considered as invalid.
One of the main problems in Session management system was that if the Redis instance goes down then all the current user will be logged out, but with JWT this is solved.
Since the token is stored with the client and all the other services have the functionality to validate the token, so if the Authorization server goes down, then also the current logged in users will not be logged out
This JWT authorization is done nowadays with OAuth2 which is the industry standard protocol for authorization.
JWT is also used in Service to Service authorization, for example: we get login options like Login with Google, Login with Facebook. These all are application of JWT authorization....