How are you securing your web applications? Are you using session cookies? Third party-based authentication? SAML? Today I’m going to introduce you...
For further actions, you may consider blocking this person and/or reporting abuse
Important to keep in mind that the payload is signed but not encrypted so don’t put anything in there you don’t want the user to see.
Also this token is (likely) going to be sent with every request so try to keep the size down.
Also also python-jose is a more general purpose JWT library you can use in Python.
Yes, I always say JWT is like a glass box, if is Broken it's invalid. But all can see inside.
This is a really good analogy thank you.
JWTs should not be used to store authentication cookies for sessions. They are larger, slower, and vastly less secure than cookies. More details on why right here: gist.github.com/samsch/0d1f3d3b474...
TL;DR: JWTs became popular because of a marketing stunt and now people use them without truly appreciating how wrong it is to replace cookies with them. They have their application in cross-domain stuff, but are not an appropriate cookie replacement. Cookies don't need replacement, they're fine.
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
Please be aware of xss if you save the token in localstorage and csrf if you save the token in cookies even with httponly and secure flag. See samesite attribute (lax/strict).
Nice article, thanks!
I also recently wrote one on mocking a JWT /JWKS in automated tests which I think compliments your article quite nicely: dev.to/mestrak/testing-secure-apis....
Wow, awesome article, i will recommend it to some friends. 😉
Thank you!
The article is really good but JWT is something that has been on the table for a while and you are presenting it like something really new.
It still presents a different perspective that few people might find easy to understand
Very good article, thanks! I would also like to add that it is impossible to invalidate a jwt token before it expires without using a database or changing the secret key.
Yep! A common way to deal with this problem is to use a redis database or similar to store tokens you've marked as invalid, or I've even seen modules for Python that will track revoked tokens in-memory (with a potentially significant performance overhead).
Thanks for the write up and good comments which almost make up to a new article .