One fine morning, Amrith pinged me there is an issue with Login on the iOS DeltaX mobile app. I was curious to know why this is happening and how should I go about fixing it. Since this was also the first time I was dealing with login module on DeltaX. The real cause of the issue was cookies being blocked by Safari and hence session cookies were not being sent on future requests. We decided to migrate our iOS login to use DeltaX API with JWT to avoid the cookies issue. There was no ready to use .NET MVC module for JWT and hence we decided to write a custom validator for the JWT token generated by the DeltaX API.
Let me take you through some of the basics of JWT.
What is JWT Token?
A JSON web token (JWT) is a JSON Object which is used to securely transfer information over the web. Okay! Let me explain in simple words:
JWT (JSON Web Token)
It is used to create access tokens for an application.
Transmits information between parties as a JSON object in a secure way
How it works:
The server generates a token that certifies the user identity and sends it to the client.
The client will send the token back to the server for every subsequent request, so the server knows the request comes from a particular identity
When should you use JSON Web Tokens?
Here are some scenarios where JSON Web Tokens are useful:
One is for Authorization
The other is for Exchange of Information
In the first case, which is one of the cases which I have dealt with is Authorization.
For example consider DeltaX platform which we use daily, here once the user is logged in, each subsequent request will include the JWT, that must be saved locally, allowing the user to access the resource that is permitted with that token
And the other case is the Information Exchange which I had gone through. It is quite interesting to know that JWT has Signature that has been calculated from the header and the payload which are the parts of JWT token which I will explain to you later. And because of that signature, we can be sure that senders are who they say they are.
When JSON has encoded its size is so smaller and compact compared to other web tokens
JSON parsers are common in most programming languages because they map directly to objects
Since it is used at Internet scale, it eases client-side processing of the JSON Web token on multiple platforms, especially mobile.
What is the Structure Of JWT tokens And How do they look like?
JSON Web Tokens consist of three parts separated by dots (.), which are:
Therefore, a JWT typically looks like the following.
Okay! Let me break down all the different parts and explain them to you!
The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used.
The second part of the token is the payload, which contains the claims. Claims are nothing but the user and additional data. There are different types of claims like registered, public, and private claims. Registered claims are usually recommended, to provide useful data. Some of them include iss (issuer), exp (expiration time), sub (subject), etc.
In my case, I was using both issuer and expiration time. The issuer is to find who is the issuer and the expiration time is to find the token’s expiry time so that we can decide if the token is valid or not. And the remaining claims are not mandatory but using that we can provide extra information.
To create the signature part we have to take the encoded header, the encoded payload, and using the algorithm specified in the header, and sign that.
Putting it all together, we will get three Base64-URL strings separated by dots which is our JWT token.
To get all the information present in JWT, we need to decode it. So that we can get the signature and verify if it’s from the sender we are expecting. Decoding JWT is very easy.
In ASP. Net MVC project, install the JWT package and import it using this code;
Then wherever you need to decode write:
var handler = new JwtSecurityTokenHandler(); var token = handler.ReadToken(yourAccessToken) as JwtSecurityToken;
After decoding start verifying from Header and check for the claims in Payload. In my case, I have checked for the userData, issuer, authentication, and Uri in Payload.
Challenges I Have faced:
In JWT, as said above, the Signature will always be calculated from Header and Payload. In my case, the signature generated by my code was wrong and it was not matching with an error mentions it as an invalid token. It was because of the signing algorithm which I used was different from the signing algorithm being used in DeltaX API.
As part of this story, I got to learn about JWT by reading resources online. I recommend using JWT as its a simply JSON object, and can be easily parsed. Using it will also make our web app independent of sessions.