DEV Community

Cover image for Demystifying JWT: How to secure your next web app

Demystifying JWT: How to secure your next web app

Kyle Mistele on January 05, 2021

How are you securing your web applications? Are you using session cookies? Third party-based authentication? SAML? Today I’m going to introduce you...
Collapse
 
dbanty profile image
Dylan Anthony

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.

Collapse
 
hansyes profile image
Anselmo Martín

Yes, I always say JWT is like a glass box, if is Broken it's invalid. But all can see inside.

Collapse
 
omawhite profile image
Omar White

This is a really good analogy thank you.

Collapse
 
eslachance profile image
Lucas Lachance

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.

Collapse
 
kmistele profile image
Kyle Mistele

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).

Collapse
 
stunaz profile image
stunaz • Edited

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.

Thread Thread
 
steventhan profile image
Steven Than

JWT thrives in microservices setting, it's a PITA having to validate session per service, especially when you have a remote authorization server

Collapse
 
kylereeman profile image
KyleReemaN

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).

Collapse
 
mestrak profile image
MeStrak

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....

Collapse
 
bevilaquabruno profile image
Bruno

Wow, awesome article, i will recommend it to some friends. 😉

Collapse
 
kmistele profile image
Kyle Mistele

Thank you!

Collapse
 
erescobar profile image
erescobar

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.

Collapse
 
monfernape profile image
Usman Khalil

It still presents a different perspective that few people might find easy to understand

Collapse
 
aiosifelis profile image
Andreas Iosifelis

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.

Collapse
 
kmistele profile image
Kyle Mistele

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).

Collapse
 
drgrey profile image
Dr-Grey

Thanks for the write up and good comments which almost make up to a new article .