Why is JWT popular?

Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: bytebytego.ck.page/subscribe
Thumbnail based on Rohit Sehgal's security zines. Follow him on Twitter at / sec_r0
Animation tools: Adobe Illustrator and After Effects.
Checkout our bestselling System Design Interview books:
Volume 1: amzn.to/3Ou7gkd
Volume 2: amzn.to/3HqGozy
The digital version of System Design Interview books: bit.ly/3mlDSk9
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

[@sandipb]

Important thing to remember, is that when an user logs out, the JWT is still usable. The log out process just removes it from client cookies/local storage. So unless the server application has implemented token blacklisting on logout, a malware can still use the jwt till it expires.

[@M3t4lstorm]

Sure if you don't implement it properly, but that goes for everything, so...

[@EtailaxiA]

How about just add a table call "signout_jwt" on db, add it on the table when user signout, than check when log in, if find that is on the db than reject the sign in. After the jwt is timeout, than delete it from the db 🤔

[@imsergiohere]

Not with OpenID wich exposes a /logout endpoint. Also, JWT MUST MUST MUST be used to identify YOU, but not to AUTHORIZE you. system: OK so you say that you are Sandipb, let me check and I will store your sesssion if true. OK, this is you, nice, I'm going to check that you are authorized to do this. OK, go for it. Next time I will not go to identity server to check your token, they can callback me if you logout.

[@backdownhipi]

This is why its best to only allow a jwt a 5 minute window, at which point a new jwt needs to be authed before more api use.

[@fcnealvillangca7943]

@@backdownhipi isn't this will make your user log in every 5 minutes? I still don't get the essence of refresh token for this

[@luis96xd]

Great video, everything was well explained, thanks!

[@animanaut]

one antipattern i witnessed is to put stuff into the payload that would rather belong into a rest path. like a for example GET for a particular resource where the resource key/resource had to be provided via payload instead of rest path. there is potential for missuse like that too, not only security.

[@invisibleinvisible83]

Thank you so much for this video🙏🏻

[@rasmusjensen8219]

This is a good intro to JWTs. Although, I do think that JWT, oauth and oidc is being somewhat mixed together. JWT's does not necessarily provide authorization or authentication. JWT is just a standard for signing JSON claims.

[@wovasteengova]

So can we set a time on the User when they log out so that if a request comes in and we validate that the user is logged in. First. But there would have to way to store JWT on db huh.

[@edblarney9456]

This is an absolutely amazing channel.

[@gus473]

Really good, understandable explanation (plus your superior graphics)! Thanks! 😎✌️

[@isophistchambers6694]

Thank you for this explanation

[@saiki4116]

Really clear, concise explanantion.

[@smritisharan-sfdcamplified]

excellent work and presentation. May i ask which TOOL HAS BEEN USED FOR ANIMATION?

[@neeleshsalian1912]

It amazed me when I heard it is pronounced as "jot"

[@kjyu4539]

that is disgusting 😡

[@mintchocolatechippy]

For me: json => JAY-SONG(silent G) jwt => J.W.T

[@nyantaro1]

Excellent video. What is the ideal way to authenticate and authorize these days?

[@jizhang2407]

Amazing animation.

[@maratchardymov2690]

Nice video, but I'd love to see comparison with cookies, for example cookies are used as default session store in Rails and can be stateless as JWT

[@aakarshan4644]

cookies are difficult in case of microservice authentication

[@ldelossantos]

The cookies are good for browsers, they are handle automatically by then, and modern implementation allows you to hide the cookie from JS for example, avoiding for example to allow somene to stole your session with script injection flaws. But JWT is really easy to implement in any layer, APIs are not only between your browser and your server, are also server trough server, if you try to handle cookies in your server code you will realize the difference.

[@OverG88]

Cookies have nothing to do with JWT, even with sessions.

[@HelloThere-xs8ss]

please read what a cookie is.

[@siddhantkumarkeshri6990]

thanks for explanation

[@rotatopotato5212]

Your voice is so calming. Thank you for another great lesson!

[@raj_kundalia]

Thank you!

[@yogashvari4294]

Good explanation 👍👍👍

[@tinnick]

As third party cookies are being deprecated in favor of FedCM, even with JWT we will not be able to implement SSO around mid 2024. JWT can still be used for logins without SSO though.

[@ReflectionOcean]

- Understand JWT structure and usage (0:34) - Ensure sensitive payload data is encrypted (2:02) - Choose the right signing algorithm for your needs (2:17) - Implement best practices for JWT security (4:02)

[@rishiraj2548]

Thanks

[@punpompur]

Couldn't agree more. Session management with JWT was a problem for me in a project because for one of the clients they wanted only one active session for a user.

[@OverG88]

Authorization services such as Keycloak can control that. Most likely through a number of issued refresh tokens.

[@Kriishna47]

Is it not possible to look at the JWT payload and get the user details and maintain the session data to determine the concurrent sessions?

[@siddhantkumarkeshri6990]

informative

[@ToanTrancodeblog]

Nice video

[@Yorgarazgreece]

i always pronounced them jay double u tees. first time i am hearing joughts lol

[@unknowrabbit666]

wow so much information /s

[@pif5023]

I still fail to understand the security part of JWTs. If they are sent as unencrypted headers and can be easily stolen why should we rely on them for user authentication and by consequence for authorization?

[@alastairzotos]

They're not that easily stolen if you send them over HTTPS. The payload may not be encrypted, but an attacker can't modify the payload (i.e. replace your email or user ID with their own) because they would have to make a new signature for that payload, which requires them to have access to the signing key that only the server has

[@Euquila]

User supplies information to server to authenticate (like username/password or oauth token). Server mints new JWT and sends it back to client, who then stores it in browser storage/cookies. Client makes subsequent requests to server like POST /data to transmit data or GET /user to get their profile or even check if they are still authenticated using this JWT (since a status 401 on GET /user indicates your JWT is no longer good and client can re-route to sign-in page)

[@ianokay]

They're no more or less likely to be stolen than any alternative access token. The video itself is confusing

[@vicaya]

The video appears to be confused about different layers of security. JWT is just a serialization format to encode auth metadata. The actual security is guaranteed by the underlying protocols, like OIDC/OAuth2 etc, which mandate state and nonce fields, as well as https/TLS 1.2+ transport.

[@vicaya]

@@alastairzotos you also need additional mechanisms (state and nonce etc.) to avoid CSRF and replay attacks.

[@Applecitylightkiwi]

V good

[@Jen-kx3oh]

technically accurate but low effort video. also doesn't really address the title, explaining why there is popularity over other mechanisms (any relationship to sessions, cookies, etc would be a good start). would have appreciated more detail on why token revocation is "difficult", key management, different types of claims (you're really just gonna say what one of them is, and just vaguely??), any examples of weak vs strong hashing algorithms, the baseline assumption that this is all over https, etc, i could go on.. and i don't believe adding any of this would drastically increase the video length or complexity, considering the graphical density.. wish some of the animation was used for any of these things.

[@ianokay]

It doesn't make any sense to suggest hijacking is a failure of JWT ("vulnerable to theft") since it's just an access token (with verifiably authentic user information). Access tokens could be hijacked as well, so it's no better or worse than the alternatives as a Bearer token. ☝🤔

[@patenlikoyun]

You can disable an access token if it's leaked

[@patenlikoyun]

I just realized after sending the message that jwts can be disabled also

[@ianokay]

@@patenlikoyun Yes because they aren't different except for what I noted

[@alps747]

@@patenlikoyunyou can't invalidate individual jwt tokens since they are not stored on the server. you can just delete the private key, so all tokens signed using that get invalidated which is a big impact as compared to invalidating individual sessions.

[@M3t4lstorm]

You can also put the client's IP (as seen by the server) in the JWT when creating it. Validate it just as you would the signature, issuer etc. Any attacker getting ahold of the JWT would have to perform the attack from the client's network, rather than sending it back to a Command and Control server/their network.

[@TobiasSette]

I missed an example showing how to not use JWT in sessions

[@stratboy2]

I thought it was a video about the james webb telescope..

[@sirinath]

What do you use for these animations?

[@roauf-]

Nobody knows, I asked and got no replies 😔

[@TF242]

If I was to guess After Effects

[@akankshagupta3687]

I also have same question

[@FarishKashefinejad]

It is in the description, illustrator and after effects.

[@CasimiroBukayo]

Probably After Effects. But it can also be done using Manim

[@the_black_astronaut7534]

Ok

[@mad_t]

I still prefer custom access tokens to jwt.

[@stevenhe3462]

Was expecting James Webb Telescope.

[@danielmutuba9621]

A comment at minute 2:30, asymmetric encyption is where encyption uses public key, but decryption uses private key, but you say otherwise in the video. A great video nonetheless

[@Reza1984_]

I thought this first, but it's used for signing not encryption.

[@arjundureja]

You sign with the private key so that anyone with the public key can verify the signature

[@nonamespls3468]

the graphics look complex, and it disrupts the listener, too many unneeded visuals running around, this could have been explained in a more simple way

[@Smoonwalkerm]

I don't like to enconde user data in JWT...specially if you have to send roles and permissions

[@biomorphic]

You should never send roles and permissions, that would be a huge security breach. You check roles and permissions based on the ID.

[@Gringohuevon]

@@biomorphic Based on the claims?

[@Smoonwalkerm]

@@biomorphic anyways... I always have doubts on this matter... Because consulting an endpoint that returns your roles and permissions in a normal http request seems very insecure to me

[@M3t4lstorm]

There isn't any security issues putting roles and permissions in a JWT.

[@aakarshan4644]

@@biomorphic or maybe the authZ policies can be handled at the gateway. btw apart from the roles being public, I don't see any other issue especially if you want the request to be authZ stateless. Preferably I think the best way is to incorporate zanzibar adjacent open source tools to deal with user/service policy at an atomic level.

[@biomorphic]

You do assume that the token is generated server side, which is not always the case. If your client is a mobile app, then it is much better if you generate the token on the client. The mobile app generates a new token for every new call, signing the token with the private key. The token would then be verified with the public key. The pair (private/public key) is generated during the sign up/sign in process. The public key is stored on the server, the private key in stored on the device keychain. No replay attack is possible in this configuration. Implemented for two different apps, first time 6 years ago. Most people creates a server side token, which is not as secure, because you can steal the token. And generally this token expires after days, otherwise you would have to issue a new token, and maybe ask to relogin every day, which is really annoying.

[@doxologist]

Although its possible to do it like this, I've never seen anyone generate JWTs on the client side. This entire flow sounds extremely inefficient and counter-productive. You may as well use cookies+session management if you were to implement it like this...

[@marklnz]

@@doxologistAgreed - general rule is to never trust the client, and that would extend to JWT. @Biomorphic, consider that if your private key is in the mobile app, then you basically just *gave it to an attacker to use themselves*. Generating client side is a crappy idea.

[@biomorphic]

It is not inefficient. Generating a token is not really time consuming. And it is much more secure, and never requires to relogin or to use a session, which are indeed slow and dangerous.@@doxologist

[@biomorphic]

You are wrong. How do you steal a secret that is stored in the keychain? You need to have access to the device, and you need to know the device password to access the keychain, and even if you have access, the value stored in the keychain can be encrypted. At that point you would need to debug the app itself to see which key is used to decrypt. Considering apps are sandboxed, you are not going to do that, not in a million years. And if you manage, that means you have full control of the device. You can't do shit if you don't have access to the device. But you can steal a token generated on the server any time. Also the token generated by the client can't be reused, because it changes for every call, so you cannot even perform a replay attack. And you don't need any fuckin session. To be able to act like that client you need to be able to generate a token with uid, did, exp, nbf, and sign it with the private key, which means you need to have access to it. You can steal the token as many times you want but you cannot ever use it. Meanwhile if you steal a token generated by the server, you can use it multiple times, and even alter it. And by the way, generating a token on the client is what Apple does. You all go for the easiest, or better, the most used solution, which is often the worst. Sessions should never be used. @@marklnz

[@marklnz]

@@biomorphic 1) not all apps are on Apple. 2) Not all clients are apps. 3) You are naive in the EXTREME if you think for one second that ANY secret on ANY client is completely safe. I'm not going to go into the specifics of anything but attacks on the keychain HAVE been successful in the past. If you build an app and say "I'm generating the token here so I need the private key" then you're making that a requirement for ALL clients of the service you're securing. So a website that uses the same API, for example. That website is going to then ALSO have to have a copy of the private key. Do you see where I'm going with this yet? You're also assuming that all users of the app are *legitimate* users. "You need to have access to the device, and you need to know the device password to access the keychain" - if I'm trying to access your API by generating a fake token then I'm just gonna go ahead and install your app on my device - then guess what? I *have* the device and I *know* the password. FFS man! Get it through your head - NEVER store secrets on a CLIENT!!!! Also, your assumption that I use sessions is wrong. I've NEVER done it that way. Always use JWT, just with *server signing* as you're SUPPOSED TO DO.

[@robpearce]

0:58 - "Easy for humans to read and write".... you have a syntax error, lol.

[@DemPilafian]

I wouldn't have been able to read that file at all. If that error was easy for you to spot, you must be one of those humans.

[@vladimir0rus]

Actually JSON is not simple to machines to parse and generate. Any binary format much easier for machines.

[@Misteribel]

1:03, that's illegal json. You can only use straight quotes, not stylized quote characters (fun fact: just about every tech video makes this mistake, you'd expect tech nerds to know how to fix quotes, right). Rant aside, very clear explanation, thanks!

[@fumanchu332]

JSON lightweight? That's rich... 🤣🤣🤣

[@EricScheid]

"jots" ?? Surely, they should be pronounced as "juuts"

[@jay_wright_thats_right]

This info is too basic. I think you draw in people because they get excited over animations. LOL! Well done. 🤣🤣🤣🤣

[@sumanmodak7859]

Very poor explaination

[@user-fed-yum]

Don't use JWT. Its just overhead that serves no benefit and makes your life more complex. Spend your time on security hardening on your server. Crazy idea designed by clever people focused on their front end skills, with insufficient backend experience designing extremely secure systems.

[@M3t4lstorm]

Tell me you don't know what a JWT is without telling me you don't know what a JWT is 😉

[@vivekpaliwal1876]

Nobody is explaining how to manage session across login, logout and others requests. Across all apps.