Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
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.
As our industry shifts our paradigm from monoliths to microservices, knowing JWT is quickly becoming a requirement.
Unless scaling your system has driven you to microservices as a point of last resort, they're usually the wrong answer. Over the next couple of years, people are going to figure that out the hard way.
I don't know why JWT would be a requirement for microservices, though. A user connects to an HTTP server, the JWT token is checked there, and the HTTP server connects to other microservices with the user information as part of its request. There's no reason to pass the JWT around.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Unless scaling your system has driven you to microservices as a point of last resort, they're usually the wrong answer
I am going to disagree with this statement. It sounds like you are suggesting JWT is a BAD option and should only be used as a last resort. JWT is just an option. And what you choose is will depend on your specific application and needs. So there are times when JWT is the BEST option.
To make a blanket statement saying JWT is always a BAD option is just not valid.
I don't know why JWT would be a requirement for microservices, though.
No technology is never a requirement, but an option... A tool available to us to choose and use.
There's no reason to pass the JWT around.
Blanket statements like show extreme bias and because of this bias become easily dismissed. To prove "no reason" is impossible. There's always a reason.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Unless scaling your system has driven you to microservices as a point of last resort, they're usually the wrong answer. Over the next couple of years, people are going to figure that out the hard way.
I can't disagree with this sentiment more strongly. While I've seen many a distributed system setup incorrectly, I've never seen one worse than a monolithic architecture.
the HTTP server connects to other microservices with the user information as part of its request. There's no reason to pass the JWT around.
That's a hard shell, soft center security approach which is very vulnerable to attack.
Jillian Estrella is an accomplished creator of immersive and interactive LED art, a physicist, and a Software Engineering Manager specializing in Design Systems and Developer Experience (DevX)
Location
Colorado, USA
Education
M.S.
Pronouns
she/her
Work
Software Engineering Manager, Design Systems and Developer Experience at Northwestern Mutual
Static site with API backend is not a use case for using JWT.
I use “static” frontends regularly with GraphQL backends and still use sessions with secure httpOnly cookies so they can’t be accessed by the browser.
IMO JWTs are okay for what I refer to as “loose” authentication (when you quickly want to hide some nonsensitive data behind a login using a service such as Auth0 but your not necessarily exposing sensitive data).
Always, when exposing potentially sensitive data, use sessions with secure httpOnly cookies.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Static site with API backend is not a use case for using JWT.
it is also not NOT a use case.
I like JWT when you have multiple distributed systems that need to share a single authentication that a single system doesn't have the authority to maintain itself.
Authentication as a Service.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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, 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:
JWTs do not come without their own complixity:
Unless scaling your system has driven you to microservices as a point of last resort, they're usually the wrong answer. Over the next couple of years, people are going to figure that out the hard way.
I don't know why JWT would be a requirement for microservices, though. A user connects to an HTTP server, the JWT token is checked there, and the HTTP server connects to other microservices with the user information as part of its request. There's no reason to pass the JWT around.
I am going to disagree with this statement. It sounds like you are suggesting JWT is a BAD option and should only be used as a last resort. JWT is just an option. And what you choose is will depend on your specific application and needs. So there are times when JWT is the BEST option.
To make a blanket statement saying JWT is always a BAD option is just not valid.
No technology is never a requirement, but an option... A tool available to us to choose and use.
Blanket statements like show extreme bias and because of this bias become easily dismissed. To prove "no reason" is impossible. There's always a reason.
I wasn't saying that JWT was usually the wrong answer. I was saying that microservices are usually the wrong answer.
Can you provide a scenario where passing a JWT around among microservices is a good idea?
I'm starting to feel like I am being Sealioned here.
Not my intention. I genuinely would like to know of such a scenario, since I can't think of one.
I can't disagree with this sentiment more strongly. While I've seen many a distributed system setup incorrectly, I've never seen one worse than a monolithic architecture.
That's a hard shell, soft center security approach which is very vulnerable to attack.
Static site with API backend is not a use case for using JWT.
I use “static” frontends regularly with GraphQL backends and still use sessions with secure httpOnly cookies so they can’t be accessed by the browser.
IMO JWTs are okay for what I refer to as “loose” authentication (when you quickly want to hide some nonsensitive data behind a login using a service such as Auth0 but your not necessarily exposing sensitive data).
Always, when exposing potentially sensitive data, use sessions with secure httpOnly cookies.
it is also not NOT a use case.
I like JWT when you have multiple distributed systems that need to share a single authentication that a single system doesn't have the authority to maintain itself.
Authentication as a Service.