JWT Token

The situation is:

The user opens the app and provides his login credentials. Now, most probably the app is interacting with a REST backend service. REST is stateless, there isn't a way to authorize access to the APIs. Hence, so far in the discussion, there is no way to check if an authorized user is accessing the APIs or is just some random requests coming through.

Now to be able to solve this problem, we need a way to know that the requests are coming from an authorized user. So, what we did was to introduce something called an access token. So now once the user is authenticated successfully, he is issued an access token. This token is supposed to be a long and highly random token (to ensure that it can not be guessed). This is where the JWT comes into the picture. Now you may/may not want to store any user-specific details in a JWT token. Ideally, you would want to just store very simple, extremely non-sensitive details in the JWT. The manipulation of the JWT hash to retrieve other user's details (IDOR etc.) is taken care of by JWT (the library being used) itself.

So, for now, our problem with authorized access is solved.

Now we talk of an attack scenario. Let's say using all of the above user Alice, using the app, has the authorized access token and now her app can make requests to all the APIs and retrieve the data as per her authorization.

Assume that SOMEHOW Alice loses the Access Token or put another way, an adversary, Bob, gets access to Alice's access token. Now Bob, despite being unauthorized, can make requests to all the APIs that Alice was authorized to.

SOMETHING WE IDEALLY DON'T WANT.

Now the solution to this problem is :

1. Either detect that there is something of this sort happening.
2. Reduce the attack window itself.

Using just the access token alone, it is hard to achieve condition 1 above, because be it Alice or Bob, it's the same authorized token being used and hence requests form the two users are not distinguishable.

So we try achieving 2 above and hence we add an expiration to the validity of the access token, say the access token is valid for 't' (short-lived) time.

How does it help? Well, even if Bob has the access token, he can use it only while it is valid. As soon as it expires, he will have to retrieve it again. Now, of course, you could say that he can get it the same way he got it the first time. But then again there's nothing like 100% security!

The above approach still has a problem and in some cases an unacceptable one. When the access token expires, it would require the user to enter his login credentials and obtain an authorized access token again, which at least in case of mobile apps, is a bad (not acceptable) user experience.

Solution: This is where the refresh token comes in. It is again a random unpredictable token that is also issued to the app along with the access token in the first place. This refresh token is a very long-lived special token, which makes sure that as soon as the access token expires, it requests the server for a new access token, thus removing the need for the user to re-enter his login credentials to retrieve a new authorized access token, once an existing one has expired.

Now you may ask, Bob can have access to the refresh token as well, similar to the way he compromised the access token. YES. He can. However, now it becomes easy to identify such an incidence, which was not possible in the case of an access token alone, and take the necessary action to reduce the damage done.

How?

For every authenticated user (in case of a mobile app, generally), a one to one mapped refresh token and access token pair is issued to the app. So at any given point in time, for a single authenticated user, there will be only one access token corresponding to a refresh token. Now assume that if Bob has compromised the refresh token, he would be using it to generate an access token (because access token is the only thing which is authorized to access resources through the APIs). As soon as Bob (attacker) requests with the newly generated access token because Alice's (genuine user) access token is still valid, the server would see this as an anomaly, because for a single refresh token there can be only one authorized access token at a time. Identifying the anomaly, the server would destroy the refresh token in question and along with it all, it's associated access tokens will also get invalidated. Thus preventing any further access, genuine or malicious, to any authorization requiring resources. The user, Alice, would be required to once again authenticate with her credentials and fetch a valid pair of a refresh and access tokens.

Of course, you could still argue that Bob could once again get access to both refresh and access tokens and repeat the entire story above, potentially leading to a DoS on Alice, the actual genuine customer, but then again there is nothing like 100% security.

Also as a good practice, the refresh token should have an expiry, although a pretty long one.

Implementing JSON Web Tokens

There are many ways of implementing JWTs however it is very common to use the following approach:

• Client authenticates into the application;
• If successful, the server creates the JWT, signs it with a secret key and sends the JWT in the response body;
• The JWT is then stored client-side and in subsequent interactions with the server, the JWT is included in a HTTP header;
• The server validates the JWT with the secret key, the identity and permissions of the user and sends back the response to the client whether or not it can access the resource.

The concerning bit in this process is where the JWT is being stored in the client-side because storing it insecurely would provide an attacker the possibility of hijacking it. Since the JWT is a session token can be used to access the resources that the compromised token has access to.

JWT storage

The JWT token needs to be stored in the client side in order to be used in the subsequent requests after authentication. The most common methods of storing the JWT are through HTML5 Web Storage or Cookies.

There are two ways of storing the JWT via HTML5 Web Storage as follows:

Local storage

Session storage

They are very similar in a way that both provide a key/value storage location within the browser for an application to query. The difference between both methods is that in local storage the JWT token becomes available across tabs in the same browser and therefore can be shared between tabs. The session storage prevents tabs in the same browser accessing the JWT and it is destroyed when closing the tab.

Another method of storing the JWT token is via Cookies, the JWT is sent and set with each HTTP request and response.

The implementation of these approaches is simple since both receive a JWT token from the server and this is stored in the browser. They are stateless since all information needed is in the JWT. Passing JWT token to the server is also simple since it can be sent via HTTP Authorisation Header or Cookie.

How about security?

Web storage is accessible via JavaScript which means that all JavaScript running in the application will have access to the JWT token. The security concern here is the possibility of the application being vulnerable to Cross-Site Scripting (XSS) vulnerability. This vulnerability allows an attacker to inject JavaScript into the vulnerable input and this could be leveraged to hijack the authentication JWT token.

Although there are ways of protecting the applications from being vulnerable to XSS by escaping and encoding all input, it is very common that the applications use JavaScript files from external sources which can be compromised. Resulting in malicious JavaScript payloads being included in the compromised JavaScript file. Consequently, the JWT token could be hijacked without being noticed.

Additionally, with local storage, the JWT token is not destroyed after closing the browser which can be compromised by an attacker if the users’ computer is compromised.

On the other hand, cookies are known to be a candidate to remediate this security issue because they have a security flag called ‘HttpOnly’ which prevents cookies from being accessed through JavaScript. Therefore, even if the application is vulnerable to XSS, an attacker would not be able to take advantage of this to hijack the JWT because this token is stored on the cookie and consequently protected from being accessed by JavaScript.

There is also the ‘Secure’ flag that can be configured in the cookie, preventing it from being sent over unencrypted communications.

Taking action

JWTs are authentication tokens that are simple to use and stateless, making them commonly used in many applications and APIs.

There are several approaches that can be used to store the authentication JWT token on the client-side however there are also security risks associated with its storage that can be leveraged by threat actors to hijack JWTs.

Cookies are the best approach to store the JWT token considering the additional security that it provides which can be used to prevent JWT to be hijacked.