Engineering July 26, 2018 3 min read

JWT may not be the holy grail… You must choose, but choose wisely!

Photo by rawpixel on Unsplash

The technological landscape changes at a fast pace. It’s nearly impossible to keep up with it. Fortunately, at Runtime Revolution we have a strong team always dealing on the forefront, using the greatest & latest solutions, to solve complex business issues. We know that what is true today may not be so tomorrow, and that is the beauty of what we do.

A recent challenge I have faced in the project I’m currently working on was to expose an API for a different set of clients (web and mobile). We had to guarantee not only that this was a secure and controlled access but also that we kept track of who was accessing it and when. For billing reasons we had to maintain this record and, due to the high volume of requests per second, we needed to guarantee the service was not sluggish.

All the requirements we had were pointing us towards one direction: JSON Web Tokens (more commonly known as simply: JWT), which has been around for long enough to prove itself a mature and reliable solution. Also, JWT has benefited from the evolution and correction the community has been providing by spotting and fixing bugs. But, like every other option we could have gone for, it must be used the way it was designed to be.

Think of it as a keycard you pick up at the front desk of an Hotel when you check in. This card has the information to access a range of resources you are supposed to get and it works while you’re at the resort. The same way a Token is generated by the server (like the front desk) to give you access to the API (the resources). This is a secure way to let you use your API, from a wide range of clients without having to “check in” every time they need to access your resources.

The main reasons that lead us to choose JWT:

1) No Database: eliminates DB queries leading to faster response time.

2) Cross-service availability: After you have the token from the auth server, all subsequent requests will used this token to access protected resources. You can even rely on JWT to move from service to service with no extra hassle of re-authenticate.

3) reduced implementation time: in this specific project we were using Django, but for any stack you might be working on there are libraries available to help you implement JWT authentication.

Keep in mind that there is also a user base that harbours no special feelings for JWT. You have both voices in the market and, truth to be told, there’s room for both of them. You just need to understand if and how JWT can be the best fit for your particular use case!

Any feedback you might have is very welcome.
I work at
Runtime Revolution with a bunch of great developers and designers where we help our clients build the tools they need to take their business to the next level.