JSON Web Tokens, also known as JWTs, have been becoming increasingly popular as a means of authentication, whether it would be for a mobile app or a public API. But what exactly are they, and why should we be using them?
What they are
A JSON Web Token is essentially a string that is generated on your server at authentication, and is then sent back to your client. The client stores this token locally, for example in:
- Web cookies
- iOS keychain
Your client now uses the token to authenticate future requests to your resource server.
This is what a JWT typically looks like:
You might be able to tell that the token is made up of three parts, separated by a period. These parts are:
- The header
Identifies which algorithm is used to generate the signature.
- The payload
Contains information, as per defined by the developer. (for example: the user ID or the user’s username)
- The signature
Signs the token, and is later used to verify that the token is intact and unaltered.
If you would like to learn more about how the actual token is generated, take a look at the Wikipedia article.
There are some advantages to using JWT over other ways of authentication.
- The tokens are compact and URL-safe.
- The tokens are self-contained.
You do not necessarily need to store any data relevant to the token on your server. The token’s payload can contain all the information that you would like it to contain. For example: user ID, role, username etc.
(This will of course impact the size of the end token)
- If properly utilized, JWTs will have little to no impact on your application’s performance.
Because the tokens are self-contained, you are saving yourself some database queries that would otherwise create a new session. The functions used to sign and verify JWTs are typically not intensive at all.
- Can be used across devices/platforms.
The aforementioned advantages sure make it sound like JWT is a great solution for your application’s authentication. And it is, but not in all cases. You should bear in mind that there are major disadvantages to JWT.
- You will (likely) need to query your database anyways.
JWTs give the impression that you, as a developer, won’t have to query your database because the information is contained in the token itself. For the typical app, this isn’t really the case. You will likely have to still query your database in order to retrieve page content, user information etc.
- No practical way of listing authenticated clients.
Imagine wanting to display a list of authenticated clients for a specific user. By default you would not be able to do this, as there is no information in your database that is tied to the authenticated clients. And if you would begin to store the authenticated clients in your database, it would defeat part of the purpose of the JWT.
- Could potentially be compromised
JWT relies on a single secret key that is stored on the server to generate signatures. If this secret key were to be leaked, your entire authentication is exposed. Anyone with a basic understanding of JSON Web Tokens is now able to manipulate (e.g. change their authenticated user ID or role) and re-sign their token.
- Size / Bandwidth usage
JSON Web Tokens are (typically) larger than “normal” session tokens. This is especially the case when you decide to store additional information in the token payload. That being said, a large token size could lead to a higher bandwidth usage.
So, should I use it?
It’s hard to say with confidence whether or not you should use JSON Web Tokens. In the end, it all depends on your application. Ask yourself the following questions:
- Are you willing to sacrifice some extra bandwidth due to the large(r) token size?
- Are you confident enough that your secret/private key won’t be leaked?
- Will using JWT save you database queries?
- Is it okay that you won’t be able to list, update or invalidate individual authenticated clients?
If the answer to those questions is yes, JWT could be a good means of authentication for your application.