6

I have been using Passport.JS session for a long time without really caring about security concern. For next project I thought of replacing session with JWT but security related concerns arise as I research more about JWT.

So if I use JWT for authentication, there are two types of tokens, an auth token and a refresh token. When I log in, I get a refresh token and this is used to communicate with authentication server to receive an auth token which will be used to get any sensitive information from the data server. The refresh token should be comparatively long lived, as opposed to the auth token which is short lived and be refreshed by the refresh token.

This refresh token should be stored somewhere. Common suggestion has been local storage but then a token that can generate infinite number of auth tokens is exposed to the client side - this doesn't feel safe.

Same applies to sessions. When we store sessions using libraries like Passport.JS ID is (usually) serialized into session storage. Then another client can take the serialized session and use it to authenticate in another device (is this true?).

So none of these two methods seem very secure (if what I have said above is correct). Are we using JWT and sessions with the mentioned security risks or am I understanding this wrong?

Anders
  • 64,406
  • 24
  • 178
  • 215
forJ
  • 161
  • 2

2 Answers2

3

I think your understanding is on par with what the technolgoy does. Both methods have inherent security risks and security pros. But I think JWT wins for me as it allows you to do without sessions and I deal with session apps everyday, they can be a security nightmare.

There are several articles that can address the security concern for storing refresh/auth tokens if that is your main concern. Here is a JWT article by Auth0. Here is another Article using nodeJS and JWT.

The point I'm making here is, if you are going to utilize either of these technologies, securing where your sessions or refresh tokens are saved needs to be carefully done as compromising that may lead to a security headache.

Note however in the case of JWT and refresh tokens, they can be easily blacklisted by the authentication server, requiring generating new ones which invalidates your old auth/refresh tokens.

geforceGTX480
  • 91
  • 7
2

There are multiple things at play here. Let's tackle them one-by-one and then answer your questions.

JWTs are Bearer tokens. If someone has the token, he wields any powers associated with it. Moreover, JWTs are also self-describing. They are meaningful without external data (valid or invalid, based on the signature and time)*. This makes them easy to use and also makes exposing them a graver problem.

To decrease the exposure, and therefore the likelihood of compromise, the concept of refresh and auth tokens were born. They work as you described. Short-lived access tokens are exposed a lot (they travel through the wire with every request), while refresh tokens only travel once in a while.

Sessions management is another topic that can be combined with the other two you mentioned. You can do session management with or without JWT, and with or without refresh and access tokens. Which way to go depends on your requirements.

If you need full-blown session management, go with cookies, if you are okay with some caveats (no logout, no idle timeout, etc.), feel free to go with JWT. Read a post I wrote about session management.

Common suggestion has been localstorage but then a token that can generate infinite number of auth token is exposed to the client side - this doesn't feel safe.

It depends on who you are protecting the token from. If the attacker can read local storage (with XSS), you are in a pretty bad situation, and there isn't much you can do. If you are worried about offline attacks, like someone taking your hard-drive and doing forensics on it to find a JWT, well, that's another threat-model.

Then another client can take the serialized session and use it to authenticate in another device (is this true?).

This very much depends on the implementation. With JWTs, this is likely as they were designed to be carried around, and likely nothing binds the initial user's browser to the token (although it is possible to do). With cookies and classic session management, this is less likely as the session is usually bound to the originator (IP, browser).

Are we using JWT and sessions with the mentioned security risks, or am I understanding this wrong?

How people use it depends on their requirements. Some go without JWTs if real session management is needed. Others do stateless sessions and are okay with the drawbacks. Still, some implement JWT blacklisting to deal with some of the disadvantages.

*Other checks on the contents of the JWT might cause you to store data on the server-side as well.
Daniel Szpisjak
  • 1,825
  • 10
  • 19