JSON Web Tokens

 

What is the use of JSON Web Token?

Not the conventional question to start with but makes a lot of sense to understand the use of JSON Web Tokens before trying to understand what it looks like and how JWT works.

You have surely heard of the the same origin policy in web applications environment owing to which one website can’t directly share its cookies or session information with another site or application. Such a situation is a sort of a roadblock if a business wants to setup Single Sign-On on a group of websites it owns and runs since, being separate domains, they would be disallowed to share customers’ session information. This is where standards like JSON Web Token and SAML come into play. SAML is also similar to JSON Web Token, or JWT, in its implementation but the difference lies in the standard. SAML is based on the XML markup language while JWT is based on the lightweight JSON format. JWT is among the three most popular means of implementing Web Single Sign-On for web applications, the other two being SAML and Multipass. The use of JWT lies in its ability to help transmit user session information - if he or she is already logged in -  in an encoded format to another domain for the purpose of authentication into the subsequently accessed web applications. This negates the need for the customer to sign in each time a new website, within a grouping bound by Single Sign-On, is accessed. On the other side, it can also be used for simple information exchange between two web applications.

What is a JSON Web Token?

JSON Web Token is basically an internet standard defined in the RFC 7519 as “a compact, URL-safe means of representing claims to be transferred between two parties.” Information is transmitted as an encoded JSON object called the payload of the JWT. JSON Web Tokens are secure and can be digitally signed with algorithms like HMAC or RSA. In simple analogical terms, a JWT is just like a rocket carrying payload to another planet. The other planet could be like a different web application and the payload is just information about a customer wishing for login without having to enter his or her credentials again. A JSON Web Token contains an identifying header, the payload in the form of a JSON Object and a digital signature so nobody opens up the rocket and tampers with the payload. And just like a rocket, a JWT carries everything it requires without having to return again for some extra information or fuel.

Well, shunning the analogies, a JSON Web Token is really cool to use because it is extremely lightweight and compact. In fact, it can be embedded into a URL to be transmitted to the other party. This is really useful in a web applications environment where lightweight is the most preferred word. On a serious note, compact standards help improve the overall user experience on the client side since metrics like page load times are positively affected.

If you are more into the really technical side of already technical things, you can try reading the original standards document RFC 7519 to get a grip on JWT.

How does JWT work?

The actual step by step procedure could be a little complex to represent so we will try to skim the smaller details and present the broad picture of how Web Single Sign-On is implemented and how JWT helps in accomplishing this. In a Web Single Sign-On environment, for instance, let’s consider there are two ecommerce websites: one for general shopping and another dedicated to fashion clothing and apparel. And a single business owns the two booming websites but wants to link them through Single Sign-On so customers coming on board for general shopping don’t have to separately register or login to the fashion website but can just jump on directly and still have an account there. Of course, the first website to be accessed by a customer will have to be logged into.

So, upon the first login request, the website-1 (either of the two) first checks for an existing JSON Web Token stored with the customer locally. If not found, it redirects the customer to the common authentication server. The customer is logged in and a JSON Web Token is created by the server and stored with the customer locally. The JSON Web Token contains information about the customer and validates that he or she is logged in with an active session. When he or she requests access to website-2, the website doesn’t redirect to the authentication server but checks for the JWT which was stored locally. This time, it is right there and after parsing it, the user is directly authenticated. Subsequent logins are controlled at the client side itself improving page load times massively.

Is JWT the best option?

We really can’t say that. But, we can’t say if it is not the best option either. It is one of the options. And if you want to use JWT or SAML or Multipass really depends on the implementation environment. But suffice to say that it is extremely easy to work with JWT. This is for the reason that JSON is a very simple and light format whose parsing is also extremely simple. On the other hand, XML - on which SAML is based - is bloated though it provides a lot of overhead capabilities that JSON doesn’t. The inference is that in web application environments where user experience is really the key metric, JSON is a good pick simply because it is lightweight.