JSON Web Tokens
If you have ever had the chance of working on API authentication, you will understand the struggle that is needed against an incoming requests every single time. According to the usual practice i.e. not making the use of a JSON web token, you’d need to create a unique hash for a client, then store that unique hash in the database and finally you have to verify that hash when a request is made. This unique hash is usually present in the cookies, head or the body of the request. Now imagine, every single time your client accesses a restricted area, you have to make a database query every time and repeat the whole process. How would that look for user experience and performance? I can tell you from experience that it does not look good.
The JWT Approach
That is why JWT was invented. The JWT works in a very similar way as explained above, only skipping the database query part every single time, the client accesses a restricted area. A JSON web token is basically a string that is sent in HTTP request from the client to the server, in order to validate the authenticity of the client. By making the use of this method, you don’t have to save JWT in database upon every request, instead it is being saved on the client side only.
How JWT works?
Each JWT when created has a secret key, which is exclusive to you. Every time you receive a JWT from a client, it can be verified by making the use of that secret key and if a modification has been made in the web token, it will result into a verification failure.
Each JWT is a simple string consisting of three base64 encoded parts separated with dots. The first part is the header, which contains information about the algorithm of JWT encryption. The second part called payload is all the data that you want included in the JWT. The last part is a signature, which is a string encrypted with a secret key, and is not publically readable.
Traditional Sessions are an alternative to JWT and have been used in the web security industry for a while now. This method generally involves making database tables in which all the session tokens are mapped to the user id. Other details like device type and expiry are also stored in the DB tables. JWT has a number of advantages over the traditional Sessions.
First of all, JWT involves fewer DB tables and thus automatically making the response faster. JWT also helps bring the costs down in case you’re using a paid services that charge per query basis. JWT can also help you cut down on development times, if your security basics are clear and you architecture doesn’t use client Sessions. One of the major advantage of using a JWT is that it can be used across services. All you need to do is have one authorization server, which deals with Login process and generates the token, any requests you make later have to go through this authorization server. This particular advantage is especially useful in corporate systems, where the users are connected to an intranet to login but once they are in the system, any public server can verify and proceed on.