I think there's way too much hype around it and people are using JWT because it's shiny!

As our industry shifts our paradigm from monoliths to microservices, knowing JWT is quickly becoming a requirement. Sometimes it is good to use the new shiny toy as an excuse to learn it. Even if your app serves less than 4,000 requests per minute and JWT would be overkill for your application, learning JWT and having practical knowledge of it is also of value.

Many articles will show you how to setup and login with JWT but they ignore the hard parts - Logging users out and blacklisting users

This is one area that is definitely overlooked and also complex. The most common solution for this is on the auth server itself, which will keep a list of users that are authenticated, expiring them when they log out. On each request the token will need to be checked against the auth server to see if the token is still valid. This adds significant overhead.

More commonly, most companies will decrease the expiry of the JWT, so it must be refreshed more often. This is due to the difficulty and overhead of managing a true logout experience.

“JWT is secure”

JWT is secure, but it is at the same time less secure than session based authentication. For example, the JWT is more vulnerable to hijacking and has to be designed to prevent hijacking. An unexpiring JWT can become a security risk.

You are also trusting the token signature cannot be compromised. This can happen if you are using weak encryption, encryption that becomes vulnerable in the future, or having the the private keys compromised. This vulnerability doesn't exist with sessions.

So while JWT is secure, it introduces new attack vectors that need to be considered.

There are valid reason to use JWTs:

• API back end - Your site is static and your back end is an API.
• Micro-service architecture - A very common way of authenticating across disconnected systems.
• To Learn JWT - Implementing JWT in smaller projects is a good way to start learning JWTs.
• Externalizing your authentication to a 3rd party provider like Auth0.

JWTs do not come without their own complixity:

• Security is more complex and needs to be understood.
• Just like how micro-services add complexity, JWT adds the same complexity as the auth is disconnected.
• Simple things like logout become complex and might require changing your expectations and business requirements.
• Doing JWT right is hard.

How can you avoid any curious customer don't call console.log() to show the jwt-secret?.

You don't keep secrets in the JWT. Everything in a JWT should be considered public.

Actually, it's assumed that generation of JWT and exchange of it has to be conducted through SSL for security reasons.

So I don't really think JWT is redundant since it's use case is more suited for API gateway backend to authenticate API services of a given user.

Good article, but I can't agree on the ideas you brought up. An http cookie is a technology that originated from the browser world. JWT is agnostic and is not bounded to any platform or technology. We use JWT to store userId only. Sure both cookies and JWTs can be used in similar ways, but it's all about the intention of the code/solution you are building. And when using JWT the intention is a universal token that can be used anywhere and stored any where and not a cookie.

I've been fighting several days to convince the other developers of the startup that I work for that JWT is not the ideal solution for authentication, I'm happy that there are other people who are talking about this :D

I think there's way too much hype around it and people are using JWT because it's shiny!

I think they all suggest JWT because it's easy to setup and lots of tutorials about single page applications just re-iterate that since it can be controlled by JS.

So are cookies. Cookies are just an HTTP header. Any HTTP client can read and set headers. The cookies header also has 20+ years of security and functionality built in to it for browsers (HTTPS only, expiration, site scope, blocking access from JavaScript) and there are well known and understood fixes for issues like CSRF tokens for forgery.

Exactly. That to me is the weakest argument

There was a really interesting discussion one year ago about using JWT and the local storage here if you're interested:

Please Stop Using Local Storage

Randall Degges ・ Jan 30 '18 ・ 11 min read

#programming #security #javascript

This is my favorite resource so far on the argument JWT and sessions: Stop using JWT for sessions, part 2: Why your solution doesn't work

ps. dev.to doesn't use JWT for the session, just to store additional user info.

The Jwt is for your back end, not your UI. The web client doesn't need to validate it, only pass it along with it's requests.

I think a big part of JWT should be some type of API Gateway.

In an example case (microservices) we take an API key from the client and the API Gateway creates a signed JWT with relevant user info. This is where blocked/logout checks will be handled.

With this, the JWT gets passed to the corresponding API service and it won't have to check again with the API Gateway on the given JWT. The JWT can also be passed to subsequent services if needed on behalf of the parent service.

1 call to user info is needed in this scenario. And the N microservices within the API request scope doesn't not need to check user auth.

Great observation.

I would refute with two points:

1) Your application doesn't need it now but if it's a real application then you should always be getting ready for the future. JWT support is extremely easy to add now-a-days as any production-ready web framework will support out of the box or with a plugin.

2) JWT is a common standard for handling several different concerns. Having it implemented out of the box means it will already be there when you actually do need it.

I personally design everything with a scaling-first mentality. It's easy to neglect scaling until your awesome app crashes at the awesomest time ever and you lose all of your awesome users and you awesome clients don't feel awesome about paying you an awesome amount of money.

You don't need JWT, so don't take it that way; but I think you've perhaps had some difficulties and you're perhaps missing a thing or two:

• on transience: a session cookie has transience too -- and it can be stolen just as effectively as a jwt. Anything which has "physical" access to the document can hijack cookies or localStorage. Anything "on the page" can steal my auth cookie too. Cookies won't save you here.
  • naturally, the fix is to make your jwt have a short lifespan and include a renew token which is automatically used when a web call encounters a 401. Handling expired tokens isn't really your problem -- there are already good frameworks to deal with this, and good auth providers (like Auth0) so you can have someone else deal with this complexity and the security of your user data in a professional manner.
• No-one said you had to include the JWT as a bearer token. You can use it however you like, including as a cookie
• There must be no secret data in a JWT. If there is, you're doing it wrong. The point of the JWT is to allow the front-end to make display decisions based on the user's scopes. Your backend still has to implement real security. The front-end should be able to validate the JWT, if it really wants to, by hitting and endpoint. NO JWT SECRETS MUST BE AT THE CLIENT. You should be using something like the OpenID Connect flow, where your login and secrets are done server-side, giving back a token to the web client. The other flows are meant for server-to-server processing, so if you're using them in the client, yes, you're doing it wrong and yes you're not secure at all

All of this is not to say you can't (or shouldn't) use session-based auth -- go ahead! JWTs just make it easier to:

• make client-side display decisions for the user (eg if she doesn't have access to the admin area, don't show the links)
• centralize your authentication and authorization in one service which doesn't have to be duplicated across web apps. This service can be queried for token validation as and when necessary.

Doing JWTs properly is hard. I've done it a few times -- and wrong a few of those times! But where I'm standing, the friction to get them working with something like IdentityServer is so low and the benefits for "heavier" client-side web applications outweigh the small setup cost.

But how do you check wether an user is authenticated or not in a single page application? What if I'm running an app and web app on the same API?

Thanks for all the responses. Love the community here. Some interesting points and discussion.

I just hope this article might make people consider if they are using JWT to solve a specific problem for their application rather than just using it by default :) Especially people new to web development using a "starter" or doing a course that only shows them JWT in local storage.

Quoting joelnet - "Doing JWT right is hard." !

there are well known and understood fixes for issues like CSRF tokens for forgery.

These also add a stateful component to the API. If you want people to still be logged in after node restart or if you ever need to scale beyond one node, then you have to make sure your sessions/CSRF tokens are stored in a shared database (e.g. Redis). This creates extra failure modes to handle (session store down or overloaded) vs verifying the JWT signature. Session cookies are a great solution for many cases, but it has trade-offs too.

A brand new approach regarding the usage of JWT, which is the combination of the two very famous security mechanisms JWT and TOTP for the first time in their digital lives.

check it out

Great article. Good points on JWT and how much attention it gets while not being the complete solution some make it out to be. I think you are also making a good point about shiny new technology in general. It happens a lot where something comes out and becomes the new big thing and it gets misrepresented as something it is not.

All good, but - what about "microservices" architecture? Where several servers cannot validate the cookie session? Do you have a solution other than JWT?

Article about JWT. Ctrl-F "PASETO". "No results found".

Am dissapoint.

github.com/paragonie/paseto

paseto.io

No role changes or payment status changes might have occurred since the JWT was issued?

Can't we revoke JWT in that case?

By no means a JWT advocate btw.

Branca