In this vast growing technology world, where the decentralization and distributed architectures are taking place rapidly, validation / authentication of source is one of the key considerations that developers need to take care of. Now sending another JSON field to the destination to source DOESN’T MAKE ANY SENSE. As, anyone can hack it. So how to make that source encrypted and digitally signed? JWT comes to rescue from this situation. This will not only Authorizes the tokens but also helps in information exchange. Let us check how it does so.
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted (basically, JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA).
This can be used in two scenarios:
- Information Exchange
Authentication is one of the most widely used verification of JWT, take an example of the scenario where used has logged into an account. Post log in, for every request it is not feasible to do authentication for every request. The solution is JWT here. Now for scenarios where SSO is not present there also JWT can be used to make sure the request and response is proper and signature can be calculated accordingly.
Structure of JWT:
It consists of three parts: Header, Payload and Signature (it looks like: xxheaderxx.xxpayloadxx.xxsignaturexx).
- The header is a signed header and it consists of type of the token and the algorithm used to encrypt (HMAC SHA256 or RSA).
So ideally the JSON for header looks like:
“algo” : “HS256”,
“type” : “JWT”
Now, here the problem does not get solved. So, on the top of the same, the header is decoded in Base64Url for more secure transaction.
- Second part is the payload which contains the claim details, which can be public, private or registered. This part is needed to get the user’s details. For the first example, where the user logs in using SSO and post that sends and receives request and response, to get the user claim part is very much mandatory and required part of the token. Amongst them private claim is one of the most secure claim to send and receive request or response. Example of a payload is:
“name”: “Debojyoti Mahapatra”,
This is also encoded with Base64Url.
- Signature is last but not the least part in a JWT token. To create the signature user has to take the encoded header, the encoded payload, a secret, the algorithm specified in the header (SHA2 or RSA), and sign that.
Now let’s join all the three dots and create a JWT token.
But before that, we need either jose or jjwt library.
Let me share the part using jjwt. The same way (but different jose libary classes) this can be done:
This generates the below output:
TOKEN :: eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJkYmM1NzU4NTdjNzM0ZmMwOWJkY2I5NGM0YWQ3ZDA0ZCIsImlhdCI6MTU0NjE4NjEzOSwibmJmIjoxNTQ2MTg2MTM5LCJleHAiOjE1NDYxODYxNjksInN1YiI6IlRlc3QgU3ViamVjdCBGb3IgRGVtbyIsImlzcyI6IkFIIiwiYXVkIjoiR2Vla3MxOEF1ZGllbmNlIn0.sWEdXEI6aMFi5BuLQxwQAr834vd8Z9VQ03Tqnp4UbC0
Subject: Test Subject For Demo
Expiration : Sun Dec 30 22:49:24 IST 2018
Not Before : Sun Dec 30 22:48:54 IST 2018
Audience :: Geeks18Audience
In the same way the token can be read in the receiver end: