Table of contents
JWT token is a piece of information which is use to authorize a user . User has to attach this JWT token in each http request , so that the server understands the user is authorized and server can accept the request from user .
Authorization
It is a check to see if a User has the privilege to access a particular resource . If the user is having the privilege then only user can access that resource . We will try to understand it by some examples .
Restaurant Example
Suppose you are hungry and you see a restaurant near by . Now you can go inside the restaurant pick a table and order something to eat . So as a customer you are having a right to access only the public area of restaurant like dining area , washroom etc . But you can’t enter inside a kitchen only the cook and managers/owners have the authorization to enter inside the kitchen . A cook can’t enter the billing area or cash collection area , cook is also having access to some part of the restaurant . So the access rights are properly divided by the type of customer/employee you are .
Customer : Dining , Washroom
Cook : Dining , Washroom , Kitchen
Manager : Dining , Washroom , Kitchen , billing , Cash
Social Networking Apps Example
Example 2 : We all are using whatsapp or facebook in our day to day life , so we all are aware about the “Groups” in those applications . Suppose a group is of 100 members out of which 3 are group-administrators and the remaining 97 are just group-members . The group-members are having the rights to post a content in the group or exit from the group . But a group-administrator will have the right to add any new member to the group , remove any member from the group or post a content .
From the above examples we came to know that based on the designation or position we can access a particular resource . So if a user is valid and the user have a right to access a resource then we call it as Authorization .
Monolithic Server Architecture
In the early days we use to host a application on only one server and old servers used a concept of session-id to remember a user .
Ex : Suppose you signed up on facebook.com . It means you have a username and password to login into facebook.com . Say you have logged in to facebook using your credentials and landed on facebook’s homepage . Now you want to see your profile info so you click on Profile icon . As soon as you click Profile icon you land on login page again instead of Profile page . How you will feel ? Will you like to use this application again in future . Here the server is not able to remember if it is the same user who logged in earlier since it don’t remember that is why it delegates you to login page again instead of Profile page .
To solve the above problem concept of session was introduced . Suppose you login to facebook.com using the credentials . If the credentials are proper then server will generate a session-id , store it in its memory and also pass this session-id to your browser . Now whenever you click on profile icon then browser will send the same session-id to the server . Server will match the session-id which you sent with the session-id stored on server . If the session-id matches then server remembers it is the same user which has logged in earlier hence it will delegate the user properly to Profile page instead of Login page ( Server also checks the database to see if the user is having the rights to access that resource )
Drawbacks of monolithic Server architecture :
In the modern era application is hosted on multiple servers . Say facebook.com is hosted on 3 servers , this is all done for load balancing . Suppose if thousands of user are logging to facebook.com at the same time and if facebook is having only one server then it is possible they user’s might face some technical issues like slow loading of pages etc . So as to improve this , facebook uses 3 servers and the traffic will be equally distributed between all the servers .
Say user1 logs into facebook.com and the login request is sent to server1 . Server1 will check the credentials of user1 . If the credentials are fine then user1 will land on a homepage and server1 will create a session-id and store it in the memory and also send the same session-id to user1 browser . Now user1 wants to check the Profile so he clicks the profile icon . As soon as the user clicks the profile icon , web browser will trigger a view Profile request with the previous session-id . But this time the request does not go to server1 instead the request goes to server2 . So what will happen now ?
Server2 do not recognize the user1 because the session-id was created by server1 and the session-id is stored with server1 . As the server2 don’t recognize user1 so server2 will delegate the user1 to a login page again and this is a very bad behaviour because We as a user don’t care what is happening in background , we don’t care how many servers facebook is managing , we just want to have a smooth communication and get the required output .
Multi-Server Architecture
Say facebook.com is hosted on 3 servers . Now user1 logs into facebook.com and the login request is sent to server-1 . Server1 will check the credentials of user1 , if the credentials are fine then user1 will land on a homepage . Now server1 will create a session-id and store it in Shared cache/Shared database ( which is shared among 3 servers ) and it is sent to user1 browser . Now user1 wants to check the Profile so he clicks the profile icon . As soon as the user clicks the profile icon , web browser will trigger a view Profile request with the previous session-id . But this time the request does not go to server1 instead the request goes to server2 . So what will happen now ?
As user1 has sent the view profile request and session-id to server2 hence server2 will check the shared cache if any session-id is stored for user1 . Here server2 will find the session-id in the cache and remembers it is the same user and will allow the user1 to access the resource ( server2 also checks the database to see if the user1 is having the rights to access that resource )
Is their any issue with above approach ? Yes Shared cache is a single point of failure . If by any means Shared cache went down then we will lose the session related data . To overcome the above behaviours token came into picture .
JWT token In Multi-Server Architecture
Say facebook.com is hosted on 3 servers . Now say user1 logs into facebook.com and the login request is sent to server1 . So server1 will check the credentials of user1 , if the credentials are fine then user1 will land on a homepage and server1 will create a signed jwt token ( Using a private key ) .
This signed token will be sent to user1 but this time server will not store the signed token anywhere . Now user1 wants to check the Profile so he clicks the profile icon . As soon as user clicks the profile icon web browser will send a view profile request with the signed token . This time the request do not come to server1 instead the request goes to server2 . So what will happen now ?
As user1 has sent a view profile request and signed token to server2 . Server2 can verify the signed token ( Using the public key ) . If the verification is success then user will get the authorization to continue and access the profile page .
Structure of JWT
JWT token never comes alone either it is a JWS ( Json Web Signature ) or JWE ( Json Web Encryption ). We will talk about JWS format here . JWS consists of header , payload and a signature which are separate by a dot symbol . The JWS usually looks like : xxx.yyy.zzz
Header : It contains some meta data .
– Algorithm name which we will use for signing the data
– Content type of the information
Ex : {
“typ”:”JWT”,
“alg”:”RS256″
}
We have to Base64 Url encode the header .
Payload : This data is related to the user like what all resources a user can access and also some additional information as well . Anyone can read this information so we should not send any private/confidential data in the payload . The JWT payload is also called as claims . We have to Base64 Url encode the payload as well .
Signature : It means creating a hash ( some alpha-numeric value ) on header and payload using some hashing algorithm . Then encrypting that hash using some cryptographic algorithm and a private/secret key . Signature looks like below :
RSASHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload) , private-key )SHA is a algorithm to create a hash and RSA is a algorithm to encrypt the created hash . Now putting header , payload and signature together we get :
base64UrlEncode(header)
.base64UrlEncode(payload)
.RSASHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), private-key)
This is how we create a JWS . If you like this article please share it . If you want to add anything extra please comment below and write to me if i have gone wrong anywhere .