Pros and cons in using JWT (JSON Web Tokens)

Rahul Golwalkar
7 min readAug 21, 2016

For apps that require a sever-side implementation, the clients (mobile app or web browser)generally have to prove their identity to the server. i.e. a user using Chrome to open facebook.com that he was previously logged into, sends some data to the FB server proving his identity. This is necessary, as HTTP calls (and even initial Websocket Connects) are stateless. Up until recently, it was done using Server Side Session that are stored in the DB. Now, a new standard called JWT has emerged and is been used by quite a few systems.

Here we compare traditional Sessions vs JWT

My comparison will be biased towards Sessions, as JWT is relatively new for me and have have exploited the sessions for my architectures that cannot be used along with JWT :-) . As well I am a bit of security freak and JWT has its drawbacks

How each works

In both cases, once the user is authenticated for the first time, the server sends a seemingly random string to the client, which the client stores it in persistent storage (e.g. web storage, cookies, NSUserDefaults) and with every subsequent request, it will send the string which is used to identify the user-id on the server.

Session : This generally involves, a DB table that has all the session tokens mapped to the user-id. The Session token string is generated randomly. Whenever the user queries, eg. Self Profile, the server fetches the user-id from the table and returns the profile from a profile table.

--

--