Why is JWT popular?

  Рет қаралды 272,396

ByteByteGo

ByteByteGo

6 ай бұрын

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.

Пікірлер: 143
@sandipb
@sandipb 6 ай бұрын
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
@M3t4lstorm 5 ай бұрын
Sure if you don't implement it properly, but that goes for everything, so...
@EtailaxiA
@EtailaxiA 5 ай бұрын
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
@imsergiohere 5 ай бұрын
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
@backdownhipi 5 ай бұрын
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
@fcnealvillangca7943 4 ай бұрын
@@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
@luis96xd 6 ай бұрын
Great video, everything was well explained, thanks!
@animanaut
@animanaut 6 ай бұрын
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.
@saiki4116
@saiki4116 6 ай бұрын
Really clear, concise explanantion.
@rasmusjensen8219
@rasmusjensen8219 6 ай бұрын
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
@wovasteengova 4 ай бұрын
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.
@saattlebrutaz
@saattlebrutaz 6 ай бұрын
This is an absolutely amazing channel.
@gus473
@gus473 6 ай бұрын
Really good, understandable explanation (plus your superior graphics)! Thanks! 😎✌️
@invisibleinvisible83
@invisibleinvisible83 6 ай бұрын
Thank you so much for this video🙏🏻
@isophistchambers6694
@isophistchambers6694 5 ай бұрын
Thank you for this explanation
@neeleshsalian1912
@neeleshsalian1912 6 ай бұрын
It amazed me when I heard it is pronounced as "jot"
@kjyu4539
@kjyu4539 6 ай бұрын
that is disgusting 😡
@pineappl3pizzzasoju
@pineappl3pizzzasoju 6 ай бұрын
For me: json => JAY-SONG(silent G) jwt => J.W.T
@jizhang2407
@jizhang2407 5 ай бұрын
Amazing animation.
@rotatopotato5212
@rotatopotato5212 3 ай бұрын
Your voice is so calming. Thank you for another great lesson!
@raj_kundalia
@raj_kundalia 6 ай бұрын
Thank you!
@siddhantkumarkeshri6990
@siddhantkumarkeshri6990 5 ай бұрын
thanks for explanation
@yogashvari4294
@yogashvari4294 2 ай бұрын
Good explanation 👍👍👍
@nyantaro1
@nyantaro1 5 ай бұрын
Excellent video. What is the ideal way to authenticate and authorize these days?
@rishiraj2548
@rishiraj2548 6 ай бұрын
Thanks
@smritisharan-sfdcamplified
@smritisharan-sfdcamplified Ай бұрын
excellent work and presentation. May i ask which TOOL HAS BEEN USED FOR ANIMATION?
@tinnick
@tinnick 5 ай бұрын
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.
@maratchardymov2690
@maratchardymov2690 6 ай бұрын
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
@aakarshan4644 6 ай бұрын
cookies are difficult in case of microservice authentication
@ldelossantos
@ldelossantos 6 ай бұрын
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
@OverG88 6 ай бұрын
Cookies have nothing to do with JWT, even with sessions.
@HelloThere-xs8ss
@HelloThere-xs8ss 5 ай бұрын
please read what a cookie is.
@jacobwwarner
@jacobwwarner 24 күн бұрын
Good short form video summary. Its more conceptual rather than technical, so i think the delivery method fulfilled the overall purpose.
@princezuko7073
@princezuko7073 19 күн бұрын
I am a newbie on this. Can you explain why it's conceptual than technical?
@jacobwwarner
@jacobwwarner 19 күн бұрын
@@princezuko7073 It didn't go into how you build a solution in code or using different libraries, frameworks, etc.
@princezuko7073
@princezuko7073 19 күн бұрын
@@jacobwwarner got it. Any good resources you’d recommend to practice in coding, using frameworks or libraries? NB: I am learning Django.
@ToanTrancodeblog
@ToanTrancodeblog 6 ай бұрын
Nice video
@unknowrabbit666
@unknowrabbit666 6 ай бұрын
wow so much information /s
@ReflectionOcean
@ReflectionOcean 6 ай бұрын
- 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)
@siddhantkumarkeshri6990
@siddhantkumarkeshri6990 5 ай бұрын
informative
@punpompur
@punpompur 6 ай бұрын
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
@OverG88 6 ай бұрын
Authorization services such as Keycloak can control that. Most likely through a number of issued refresh tokens.
@Kriishna47
@Kriishna47 2 ай бұрын
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?
@jimdixxTubersSTV
@jimdixxTubersSTV 29 күн бұрын
@@Kriishna47 OIDC and JWT Token bring benefits of stateless application approach. Maintaining a session between a client and a server omits this benefit and the application becomes stateful by the principle. In this case, you may bring another authentication mechanism -> cookies, to track the user's session, typically. Also, you have to store the sessions on the server side. Good luck with easy horizontal scaling, as this adds another complexity to the whole architecture as you must store the session information in some key-value database for all the instances. Stateful applications also require a slightly different approach of security, such as CSRF protection and many more to avoid session theft, which does not differ from JWT token compromise attacks, which may be protected by refresh token rotation, etc, etc. In my opinion, if you can avoid it, do not use stateful approach, but some applications must be stateful (I know). However... mixing stateful and stateless approaches together are an anti-pattern in my opinion, adding unnecessary complexity to the system architecture.
@rahulsalivendra
@rahulsalivendra 22 күн бұрын
Hi, what are various ways we can encrypt and decrypt the payload using jwt?
@Applecitylightkiwi
@Applecitylightkiwi 6 ай бұрын
V good
@Yorgarazgreece
@Yorgarazgreece 6 ай бұрын
i always pronounced them jay double u tees. first time i am hearing joughts lol
@pif5023
@pif5023 6 ай бұрын
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
@alastairzotos 6 ай бұрын
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
@Euquila 6 ай бұрын
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
@ianokay 6 ай бұрын
They're no more or less likely to be stolen than any alternative access token. The video itself is confusing
@vicaya
@vicaya 6 ай бұрын
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
@vicaya 6 ай бұрын
@@alastairzotos you also need additional mechanisms (state and nonce etc.) to avoid CSRF and replay attacks.
@TobiasSette
@TobiasSette 5 ай бұрын
I missed an example showing how to not use JWT in sessions
@the_black_astronaut7534
@the_black_astronaut7534 2 ай бұрын
Ok
@stratboy2
@stratboy2 4 ай бұрын
I thought it was a video about the james webb telescope..
@mad_t
@mad_t 6 ай бұрын
I still prefer custom access tokens to jwt.
@ianokay
@ianokay 6 ай бұрын
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
@patenlikoyun 6 ай бұрын
You can disable an access token if it's leaked
@patenlikoyun
@patenlikoyun 6 ай бұрын
I just realized after sending the message that jwts can be disabled also
@ianokay
@ianokay 6 ай бұрын
@@patenlikoyun Yes because they aren't different except for what I noted
@alps747
@alps747 6 ай бұрын
@@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
@M3t4lstorm 6 ай бұрын
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.
@withanujmittal2800
@withanujmittal2800 2 күн бұрын
best
@Jen-kx3oh
@Jen-kx3oh 4 ай бұрын
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.
@sirinath
@sirinath 6 ай бұрын
What do you use for these animations?
@roauf-
@roauf- 6 ай бұрын
Nobody knows, I asked and got no replies 😔
@TF242
@TF242 6 ай бұрын
If I was to guess After Effects
@akankshagupta3687
@akankshagupta3687 6 ай бұрын
I also have same question
@FarishKashefinejad
@FarishKashefinejad 6 ай бұрын
It is in the description, illustrator and after effects.
@CasimiroBukayo
@CasimiroBukayo 6 ай бұрын
Probably After Effects. But it can also be done using Manim
@danielmutuba9621
@danielmutuba9621 6 ай бұрын
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_
@Reza1984_ 6 ай бұрын
I thought this first, but it's used for signing not encryption.
@arjundureja
@arjundureja 5 ай бұрын
You sign with the private key so that anyone with the public key can verify the signature
@stevenhe3462
@stevenhe3462 2 ай бұрын
Was expecting James Webb Telescope.
@nonamespls3468
@nonamespls3468 4 ай бұрын
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
@Smoonwalkerm 6 ай бұрын
I don't like to enconde user data in JWT...specially if you have to send roles and permissions
@biomorphic
@biomorphic 6 ай бұрын
You should never send roles and permissions, that would be a huge security breach. You check roles and permissions based on the ID.
@Gringohuevon
@Gringohuevon 6 ай бұрын
@@biomorphic Based on the claims?
@Smoonwalkerm
@Smoonwalkerm 6 ай бұрын
@@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
@M3t4lstorm 6 ай бұрын
There isn't any security issues putting roles and permissions in a JWT.
@aakarshan4644
@aakarshan4644 6 ай бұрын
@@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.
@vladimir0rus
@vladimir0rus 4 ай бұрын
Actually JSON is not simple to machines to parse and generate. Any binary format much easier for machines.
@biomorphic
@biomorphic 6 ай бұрын
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
@doxologist 6 ай бұрын
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
@marklnz 6 ай бұрын
@@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
@biomorphic 6 ай бұрын
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
@biomorphic 6 ай бұрын
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
@marklnz 6 ай бұрын
@@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
@robpearce 6 ай бұрын
0:58 - "Easy for humans to read and write".... you have a syntax error, lol.
@DemPilafian
@DemPilafian 6 ай бұрын
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.
@Misteribel
@Misteribel 4 ай бұрын
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!
@rujor
@rujor 26 күн бұрын
I don't think the closed envelope analogy is accurate. As far as I know, anyone can *read* the payload, no?
@fumanchu332
@fumanchu332 4 ай бұрын
JSON lightweight? That's rich... 🤣🤣🤣
@EricScheid
@EricScheid 4 ай бұрын
"jots" ?? Surely, they should be pronounced as "juuts"
@sumanmodak7859
@sumanmodak7859 4 ай бұрын
Very poor explaination
@DhavalAhir10
@DhavalAhir10 20 күн бұрын
Why?
@jay_wright_thats_right
@jay_wright_thats_right Ай бұрын
This info is too basic. I think you draw in people because they get excited over animations. LOL! Well done. 🤣🤣🤣🤣
@user-fed-yum
@user-fed-yum 6 ай бұрын
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
@M3t4lstorm 5 ай бұрын
Tell me you don't know what a JWT is without telling me you don't know what a JWT is 😉
@vivekpaliwal1876
@vivekpaliwal1876 2 ай бұрын
Nobody is explaining how to manage session across login, logout and others requests. Across all apps.
Difference between cookies, session and tokens
11:53
Valentin Despa
Рет қаралды 577 М.
Top 12 Tips For API Security
9:47
ByteByteGo
Рет қаралды 68 М.
UFC 302 : Махачев VS Порье
02:54
Setanta Sports UFC
Рет қаралды 1,3 МЛН
ХОТЯ БЫ КИНОДА 2 - официальный фильм
1:35:34
ХОТЯ БЫ В КИНО
Рет қаралды 2,9 МЛН
What Is JWT and Why Should You Use JWT
14:53
Web Dev Simplified
Рет қаралды 1,1 МЛН
JWT авторизация. Основы JWT - механизма.
6:45
Хочу вАйти
Рет қаралды 2,3 М.
Top 6 Tools to Turn Code into Beautiful Diagrams
3:24
ByteByteGo
Рет қаралды 553 М.
Top 8 Most Popular Network Protocols Explained
6:25
ByteByteGo
Рет қаралды 244 М.
How Does Linux Boot Process Work?
4:44
ByteByteGo
Рет қаралды 524 М.
20 System Design Concepts Explained in 10 Minutes
11:41
NeetCode
Рет қаралды 870 М.
What is JWT? JSON Web Tokens Explained (Java Brains)
14:53
Java Brains
Рет қаралды 1 МЛН
Your App Is NOT Secure If You Don’t Use CSRF Tokens
9:57
Web Dev Simplified
Рет қаралды 121 М.
Top 7 Ways to 10x Your API Performance
6:05
ByteByteGo
Рет қаралды 306 М.
UFC 302 : Махачев VS Порье
02:54
Setanta Sports UFC
Рет қаралды 1,3 МЛН