I respectfully disagree - JWTs aren't necessarily a replacement for cookies. In fact, they are commonly stored as cookies, as I wrote about above.
In fact, comparing JWTs to cookies doesn't quite make sense:
A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens.
They aren't opposites - rather, they can be used either together or independently. The correct comparisons are "sessions vs. JWT" and "cookies vs. Local Storage
I've built plenty of applications that store JWTs in cookies, so there isn't necessarily any overhead that you wouldn't have with cookies. The maximum size for a cookie is about 4 Kb, which is absolutely tiny given that most network speeds are measured in hundreds of megabits per second or even in gigabits per second. It's also an immaterial amount of memory given that most programs run with gigabytes of memory. Any other performance overhead is going to be so small that it's completely unnoticeable to the end user.
Using JWTs securely with cookies is entirely possible, since per the MDN specs I linked to, there are multiple mechanisms you can use to mitigate the effects of XSS on session cookies.
There's definitely something to be said for avoiding localStorage and sessionStorage if you're worried about XSS, but the most correct answer to that problem is to have good coding and security practices that prevent and mitigate XSS, since XSS can result in a complete takeover of your site.
I would personally hesitate to call an IETF RFC a marketing stunt. I suspect that many developers are moving towards using JWT because the JSON payload is easy to consume with today's modern JavaScript stacks.
It's also worth noting that I'm not advocating using JWTs for sessions - most modern RESTful APIs and the web applications that are often built on top of them don't have a concept of sessions (since RESTful APIs are by definition stateless).
I would say that it depends on the use case. The most common case is for authentication/authorization. In that case if you store in cookie, IMHO why do you even need JWT in the first place. Done a tons of reading and came to the conclusion that jwt is just not secure for the web, works for a phone/tablet, gui apps.... not for the web. And whatever you do for trying to make it secure. it will look like you are implementing the old session/cookie stuff.
Having building many application with jwt cookie does not really mean anything, yeah it works, but you could also have done it simply with sessionid on cookie at this point.
I respectfully disagree - JWTs aren't necessarily a replacement for cookies. In fact, they are commonly stored as cookies, as I wrote about above.
In fact, comparing JWTs to cookies doesn't quite make sense:
I've built plenty of applications that store JWTs in cookies, so there isn't necessarily any overhead that you wouldn't have with cookies. The maximum size for a cookie is about 4 Kb, which is absolutely tiny given that most network speeds are measured in hundreds of megabits per second or even in gigabits per second. It's also an immaterial amount of memory given that most programs run with gigabytes of memory. Any other performance overhead is going to be so small that it's completely unnoticeable to the end user.
Using JWTs securely with cookies is entirely possible, since per the MDN specs I linked to, there are multiple mechanisms you can use to mitigate the effects of XSS on session cookies.
There's definitely something to be said for avoiding localStorage and sessionStorage if you're worried about XSS, but the most correct answer to that problem is to have good coding and security practices that prevent and mitigate XSS, since XSS can result in a complete takeover of your site.
I would personally hesitate to call an IETF RFC a marketing stunt. I suspect that many developers are moving towards using JWT because the JSON payload is easy to consume with today's modern JavaScript stacks.
It's also worth noting that I'm not advocating using JWTs for sessions - most modern RESTful APIs and the web applications that are often built on top of them don't have a concept of sessions (since RESTful APIs are by definition stateless).
I would say that it depends on the use case. The most common case is for authentication/authorization. In that case if you store in cookie, IMHO why do you even need JWT in the first place. Done a tons of reading and came to the conclusion that jwt is just not secure for the web, works for a phone/tablet, gui apps.... not for the web. And whatever you do for trying to make it secure. it will look like you are implementing the old session/cookie stuff.
Having building many application with jwt cookie does not really mean anything, yeah it works, but you could also have done it simply with sessionid on cookie at this point.
JWT thrives in microservices setting, it's a PITA having to validate session per service, especially when you have a remote authorization server