JSON web tokens are NOT meant for authenticating the same user repeatedly: Use session tokens instead

I am sorry for sounding harsh, but everything written here is highly misleading and extremely dangerous. I would plead with the author to do more research and update the contents of the article. No, session tokens should not be used today under any circumstances unless the developer is lazy or have not caught up on basics of web security in the past decade. And no, it is completely false that JWTs do not have expiration. It is actually their main feature that made the popular. On top of it the same token allows to take care of both authorization and authentication which is a very nice add-on. Furthermore, there are established procedures for token revocation, and JWT allows for seamless horizontal scaling. Short-lived token auth with automatic token update on every API call is the only secure way to battle intercept or leaking of auth info because it invalidates the token on the next response. Refresh tokens are what is used to allow long-term access to the resources and storing those requires extra care. All of it is well established and formalized in OAUTH 2.0 standard
en.m.wikipedia.org/wiki/OAuth

To revoke a JWT, you can change the secret you used to sign those tokens, this invalidates all the tokens you issued. This works like a master reset for you service in case your tokens got compromised.

Also, when signing a token, using a version identifier in token's data can be useful whenever you want to revoke this token for a specific user. So if a user "forgets his password" or logs out, you can change the version identifier in the DB. Now, if the user tries to log in with his old JWT, you will know as the version of his JWT and version stored in DB are not the same.

This is my understanding of using JWTs for web authentication but I totally see the point of using sessions. In most cases I also prefer to use sessions but knowing how to solve the problem of invalidating JWTs is still helpful.

I think that both solutions have merits but are designed to work best for different scenarios.

JWTs really shine when you have a dedicated or 3rd party issuer like Google or GitHub or even your own solution that can issue a JWT that can be used with another application. The refreshing of the JWT can be managed by the issuer which would be directly talking to the frontend (think serverless).

Sessions on the other hand are really for when you are communicating with a single server (or a cluster using the same store) once you introduce external services or even micro services things start to get more complex or even impossible.

It's about using the right tool for the job and understand how those tools work.

I don't think you actually explained why jwts shouldn't be used.

It's extremely common for them to be stored in local storage. Can you give an example of a xss attack?

It's also very common to store them in a db on the server, using jwt for both auth and refresh tokens. The db is accessed on every request but you said session tokens require this anyway. You can store tokens in redis for improved performance.

If the user logs out, you can delete the tokens from the db+redis. So jwt lifetime won't matter.

Take a look at this article:
dev.to/gkoniaris/how-to-securely-s... and its comments (i made one)

Session tokens and JWT are different beasts with pros and cons. You identified some of them.
I'm assuming you're trying to authenticate a user on a web app.

For ages, session token were the way to identify a user on a website. It's still the case for most sites.
Like the "ASP.NET_SessionId" cookie in a .Net Framework website for example. The cookie simply contains an id, thus the network overhead is very small.
The id is stored in-memory from the server that generated it, and an in-memory dictionnary is provided to store whatever you want for that session.
It thus makes things easy to store things while a user is browsing your website, like a shopping cart or the last form choices...

It's easy, but still highly unsufficient for a decent secure application because:

• If you copy this id and inject it into requests from another computer, you are automatically logged in
  Counter measures: httpOnly attribute, csrf token, store info like ip adress or user agent at session creation, and check it doesn't change on each request, ...
  See more : cheatsheetseries.owasp.org/cheatsh...
  [if you're using ASP.Net forms authentication ticket, check that the the sessionId is associated to the same forms authentication ticket]

• It doesn't provide a "remember me" option in the login form:
  When you close your browser, the cookie is destroy thus you loose authentication
  A "remember me" option requires to store a cookie with an explicit date that your browser keep.

• Scalability is an issue. As soon as you have 2 servers (which you should for an high availability website), you need sticky sessions to load balance requests to the corresponding servers. Which make it challenging to load balance users across servers.
  That's the main issue with session token: it's not stateless
  Counter measures: session store like you said. Which is easier nowadays with fast system like redis.
  But it's still challenging in some web app because you also store some data locally on the server between requests and it breaks without sticky session

JWT is more recent and allows you to exchange claims between 2 parties and verify the integrity of claims.
It means:

• this time, we can store key:value pairs inside
• each token can be validated on server side with the signature (this prevent a fake forms authentication ticket)

This allows to make stateless requests : any server can validate the request (and use info for the jwt payload).

As you correctly identified, there are 2 main downsides:

• refresh tokens allows you to genereated as many access token as you wish. thus even though they are not used often, their storage is critical.
  it's hard to prevent them to be stolen or brutforced

• There is no expiration mecanism by default
  For this, you'll have to rely on your library or code it yourself.
  Take a look at this python library it's cool: pypi.org/project/Flask-JWT-Extended/
  I invite you to take a look at this page to get the refresh concepts: flask-jwt-extended.readthedocs.io/...
  Basically this idea is to create an access token a few minutes before expiration.

But also:

• A JWT token with a big payload (lots of key:value) will add significant network overhead for EACH REQUEST

• A copied JWT token is valid. Even if the user hit logout in his browser: the token can still be reused.
  (again the issue might occur with xss: an injected script might copy the token to a bad actor website)
  Similar to the session id we have to use counter measures here. Csrf token is a must.

One other idea is the blacklist: as soon as a user logout, you add this jwt token to a blacklist.
Which requires a redis-like server also...

So, were to go from here?
It all comes down to what you are trying to achieve...
Is this a web app?
How often and long the user are connecting?
Do you want a remember me feature?
Can a user be connected from 2 locations at a time?
Do I want scalability with stateless applications that i can kill/restart without impacting users?
Is there also a REST api with authentication? Is the REST api called only from your website or also from the public?

For a simple calendar application where members can authenticate and make comments, I used a flask python app with Flask-JWT-Extended.
This idea was to play with JWT rather than session based token.
There is also a REST api used by the web app itself.

With session based token, there was a notion of "sliding expiration" which doesn't exist with jwt:
If the user keep making requests, the server in-memory session expiration is pushed back in time. This is not easy with JWT (needs refresh token).

I decided not to use refresh token because it's not practical in my case.
When the user login, a 1H token is created. If the user keep browsing and make a request 1H and 1s later, he's immediately disconnected.
That sucks but 1H is ok for my app usage. And i don't have to manage refresh tokens.

On the login form, there is a remember me checkbox. I decided to create a 30days access token in that case.
It's not the best but hey good luck bruteforcing that jwt token^^
You can also add counter measures to bruteforce attemps (slow them by responding slower and slower).

My REST api does can use both cookie tokens or http header token.
flask-jwt-extended.readthedocs.io/...

If you just want to play with the REST api from an external client: no need for cookies

• i got an enpoint /api/auth/login to generate an access token
• it is returned as json response, NOT cookie
• access token valid for 15min only, without payload.
• each subsequent requests need to specify the token with "Authorization: Bearer " header

The web app can use the rest api by forwading automatically the cookie token (same domain).
But xhr request should also transport the csrf token like so:

var csrf_cookies = document.cookie.split('; ')
  .map(x => x.split('='))
  .filter(x => x[0] === 'csrf_access_token');
if (csrf_cookies.length)
{
  csrf = csrf_cookies[0][1];
}

var xhr; // make ajax request
//...
xhr.setRequestHeader('X-CSRF-TOKEN', csrf);

see there doc. : flask-jwt-extended.readthedocs.io/...

Hope that provides some answers!

The problem with most articles that most people are reading is that they aren't articles about security, what it means, or what it should look like. Part of the problem is that people go looking for these exact articles (ie: how do I do security). Not only that, most resources for the why, how it works, examples of in the form of real production "grade" solutions, and the like are dismissed because "I'm just making a POC" or "I don't expect any users", or "I know enough, it's just auth! How hard can it be? It's like user input and hashing right?", or "I'm just learning", "I'm just looking for something simple or easy", etc.. etc... etc... That's all great. If you want to learn how databases work you can totally write your own but you should probably, for the sake of your users, simply use an existing database for a "real" product. Unless of course your product in fact is a database. This is very similar to the countless individuals who cowboy code their way to success rebuilding wheels and reinventing concepts (generally very poorly) because the resources they were searching for were how to do something (how do I use JWTs, how do I access redis in node, etc...) instead of why you would want to do something, what it means, how it works, what things have evolved over time by a collective of incredibly smart people that I can learn from by their example, etc... Emphasis should be on learning and understanding not just on doing. Too many people skip straight to "how do I do?" Those "how I do" articles rarely if ever go over how you should do it essentially teaching you the bare minimum, at a very low bar of quality, absolute minimum to do XYZ and rarely talk about what it means and why you shouldnt do this tutorials and that stack overflows copypasta's in a real product.

All of that being said there are numerous resources for understanding what security is, can be, why it's important to standardized it, and there are several organizations which have been thinking about, studying, and evolving security concepts and standards for years and years. These are the resources one should look to when trying to understand what security means, which standards and expectations to follow, and how they may fit for a given product or company. If you're interested in understanding what security is, what it means, and how it may fit into your product, in the context of identity and authorization, I implore you to check out the following couple resources and start looking for resources which aren't just tutorials and "how I do" articles.

identityblog.com/wp-content/images...

openid.net/2021/04/10/the-7-laws-o...

idsalliance.org/

Imho storing the jwt in a httpOnly cookie does only increase security a little bit. It only prevents stealing the jwt.

But an attacker using a xss vulnerability in your app has still full access and could easily do every attack from within your app with your credentials assigned.

Changing the attack from stealing a jwt to running the malicious request directly in your browser is pretty easy. So if you think you are save with httpOnly you're unfortunately wrong.

That said: security is a layered approach. The more layers the better. But I think this specific layer does not add a big barrier for an attacker and does make other things harder (for example reading the content of the jwt).

I would still save my jwt in local storage. If you have a case vulnerability you are screwed anyways 😅

Ben Awad seriously? It would have been worth reading if you would have referenced owasp guidelines on JWT auth .

cheatsheetseries.owasp.org/cheatsh...

One more thing, the whole point of JWT is to make auth stateless and should not be stored on server.
It fulfils REST constraints that requires requests to be stateless.

Once you get past the title of this article (which I think really needs to change to something more like "Which is best for a simple website: token or session auth?" but I get the desire to be clickbaity) the quote which I think is the core of this argument is:

This is why Awad (2019) says he uses session tokens, not JWTs, for a simple web app.

and that's pretty reasonable especially if, as the rest of the post suggests, you intend to implement the token auth yourself rather than using a service.

I think a big piece missing from this is that session auth is not a standard and is often a roll-your-own kinda deal where you need a user database with passwords and some session["isLoggedIn"] thing going on but token auth is a standard and the more usual way to implement that is to use a library or an external token service. The advantage here being that token auth is more secure by default and if you use an external service you don't have concerns about secure password storage, refresh tokens, etc someone else already solved that problem.

From that point of view token auth via an external service is actually a better choice for a simple website because you write zero code and zero code means zero bugs and that you can spend that time implementing the features you can't just buy off the shelf.

From my point of view this is comparing apples to oranges. Presumably OAUTH access tokens could even be implemented as session tokens if you so chose. I think it is brave to make public notes like this while at the early stages of understanding, so I commend you for that. I think there is much to learn on this topic and putting yourself out there like this is a good way to go about it. As they say: fail, but fail fast.

It is also good you added strong caveats that this is a note to yourself, not guidance.