Do you really need JWT based authentication at back end?

Neo Liu
Neo Liu
Oct 20, 2019 · 5 min read
Do you really need a JWT token?

For many developers who first knew JWT authentication, the confusion isn’t about “How” but “Why”.

In order to understand if your web server really needs JWT authentication, you first have to understand how an authentication process works and what a normal token authentication is.

Basically, authentication is the verification of a unique key only shared between server and client. A unique key can be anything such as a number, string or object.

Authentication behind your login process

Simplified user login authentication

As we mentioned, the authentication process is a verification of the unique key. In a normal login process, the unique key is the combination of user’s username and password. A typical login process work in this way:

1. User agent(browser) send the unique key (username & password) to the server

2. Server search the database with the unique key

3. Database returns either the found result or a null

4. Server returns login status to the user agent to continue or stop

Till now, the authentication of the user’s identity has finished. If the user agent receives a positive response then the user will be able to access the restricted resources, otherwise, access won’t be permitted.

Re-authenticate on page reload

Now we know how the authentication process works when user logins, then we need to handle the followed problem: how to re-authenticate the user identity when the page is reloaded.

Since JavaScript front end can’t remember the HTTP response after reload, so we have to send the unique key for re-authenticating user’s identity. To do that, here are two problems we need to handle first:

  • Do you have to send the request along with username and password to the server every time?
Token based re-authentication

You can, but it’s not safe and necessary. A proper solution is to use a unique token only available to server and client to represent the user’s identity after user login. The server needs to generate a unique token and send it back to the client. After that, the server just need to compare the tokens from client and database.

if(tokenFromClient === tokenFromDb){
//do something
}else{
throw new Error("Authentication error");
}

If the tokens are same then it means the user is whom he is claiming, otherwise it’s a malicious attempt.

Note: we can use the token comparison result to check the user identity is based on two assumptions : 1) the token will be generated only if the user successfully login and only the user knows his/her own username & password 2) your site is safe from XSS and an attacker won’t be able to retrieve the token from localStorage

  • Where should we store the token?

We have two choices: cookies or localStorage then we can either save our unique key in Web API localStorage or Cookies with HttpOnly flag. Many people believe localStorage is safe from XSRF but not XSS, and in contrast, Cookies is safe from XSS but not XSRF. Forget about it, the paradox is if your site is XSS vulnerable, then everything stored in cookies won’t be secure at all because the attacker can send AJAX request in your website’s context containing all cookies data, and if your site is XSS-proof then why do you need to store token in Cookies to expose your clients to the XSRF attacks. So just simply go for localStorage.


JSON Web Token (JWT) vs A Simple Token

From the lase section, we know a token can be used to represent a user’s identity, so why and when we will need a JSON Web Token? Well, this depends on your web application. If your website’s front end behaves all the same for all users and no user info will affect the back end operations, then probably a simple token is enough for your website.

Login process with JWT token

If your website’s front end needs some complicated user role checks and the users details will affect the consumption of APIs then probably a JWT token is more appropriate. Besides, a simple token doesn’t have a expiry time which is not the best practice, while you can easily set a expiry time for a JWT token.

According to JWT’s official documentation, JWT is a way to securely transmitting information between parties.

The login process using JWT is almost the same with a normal login process but the result will have a JWT for later requests Authorization header.

request = request.clone({
setHeaders: {
Authorization: `Bearer ${currentUser.token}
}
});

JWT Re-authenticate on page reload

In above section, we mentioned the re-authentication process needs to pull the token from the database and make a comparison between the tokens sent from client and database. However, querying database is painful and will significantly increase the response time.

Re-authentication process with JWT

With JWT, in theory, you don’t need to pull the database every time, since you signed it with a private key and you can also simply verify the token with that private key.

Wrapping Up

The JWT itself has nothing to do with security. It is just a way to secure data initially signed at the server side won’t be changed when it is sent back from the client.


Neo Liu

Written by

Neo Liu

I am always on the way of learning. I like writing articles because it helps me re-organise and consolidate my learnings.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade