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.
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 🤔
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.
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.
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.
This is by far the best description of the pros cons and implications of JWT use and the different flavours that i have seen. Balanced simple and factual
- 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)
Nice short and informative video. Nice to hear an explanation of under-the-hook work of JWT's and comparison with Session-based auth. Thanks for the video!
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.
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.
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.
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.
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.
@@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.
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?
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
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)
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.
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. ☝🤔
@@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.
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.
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
standardlization is not good in jwt, jwt is lightweight but not light enough, especially it put in header request. we can still reduce header request : remove header jwt - service know how to verify itself using encode better than base64 or just encrypt it to store sensitive data, WHY NOT?
5 місяців тому
bad start of the video: 0:56 the json example is doubly malformed: 1) it uses smart quotes; 2) the keys 'exp' and 'sub' have an extra closing double quote
@@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
@@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.
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!
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.
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...
@@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.
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
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
@@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.
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.
Sure if you don't implement it properly, but that goes for everything, so...
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 🤔
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.
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.
@@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
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.
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.
This is by far the best description of the pros cons and implications of JWT use and the different flavours that i have seen. Balanced simple and factual
It amazed me when I heard it is pronounced as "jot"
that is disgusting 😡
For me:
json => JAY-SONG(silent G)
jwt => J.W.T
It’s actually pronounced JOT in programming world
- 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)
Nice short and informative video. Nice to hear an explanation of under-the-hook work of JWT's and comparison with Session-based auth. Thanks for the video!
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.
Your voice is so calming. Thank you for another great lesson!
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
cookies are difficult in case of microservice authentication
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.
Cookies have nothing to do with JWT, even with sessions.
please read what a cookie is.
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.
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.
Good short form video summary. Its more conceptual rather than technical, so i think the delivery method fulfilled the overall purpose.
I am a newbie on this. Can you explain why it's conceptual than technical?
@@princezuko7073 It didn't go into how you build a solution in code or using different libraries, frameworks, etc.
@@jacobwwarner got it. Any good resources you’d recommend to practice in coding, using frameworks or libraries?
NB: I am learning Django.
Good explanation
👍👍👍
Amazing animation.
Excellent video. What is the ideal way to authenticate and authorize these days?
This is an absolutely amazing channel.
Really clear, concise explanantion.
Really good, understandable explanation (plus your superior graphics)! Thanks! 😎✌️
Thank you!
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.
Authorization services such as Keycloak can control that. Most likely through a number of issued refresh tokens.
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?
@@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.
@@Kriishna47 using session is better then in that situation
Would like more details and nuance for a topic like this
Thank you for this explanation
Great video, everything was well explained, thanks!
Love This
excellent work and presentation. May i ask which TOOL HAS BEEN USED FOR ANIMATION?
Thank you so much for this video🙏🏻
great presentation
Nicely Explained
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?
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
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)
They're no more or less likely to be stolen than any alternative access token. The video itself is confusing
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.
@@alastairzotos you also need additional mechanisms (state and nonce etc.) to avoid CSRF and replay attacks.
Hi, what are various ways we can encrypt and decrypt the payload using jwt?
how did you made this animation?? waw>>>
What program do you use to make your presentation ? They look so cool, I want to use them in my school project so much!
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. ☝🤔
You can disable an access token if it's leaked
I just realized after sending the message that jwts can be disabled also
@@patenlikoyun Yes because they aren't different except for what I noted
@@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.
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.
Nice video
Thanks
wow so much information /s
Does anybody know how to make does incredible diagrams with animations whatever? Please
informative
V good
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
I thought this first, but it's used for signing not encryption.
You sign with the private key so that anyone with the public key can verify the signature
I missed an example showing how to not use JWT in sessions
What do you use for these animations?
Nobody knows, I asked and got no replies 😔
If I was to guess After Effects
I also have same question
It is in the description, illustrator and after effects.
Probably After Effects. But it can also be done using Manim
thanks for explanation
i always pronounced them jay double u tees. first time i am hearing joughts lol
standardlization is not good in jwt, jwt is lightweight but not light enough, especially it put in header request.
we can still reduce header request :
remove header jwt - service know how to verify itself
using encode better than base64 or just encrypt it to store sensitive data, WHY NOT?
bad start of the video: 0:56 the json example is doubly malformed: 1) it uses smart quotes; 2) the keys 'exp' and 'sub' have an extra closing double quote
I thought it was a video about the james webb telescope..
I don't like to enconde user data in JWT...specially if you have to send roles and permissions
You should never send roles and permissions, that would be a huge security breach. You check roles and permissions based on the ID.
@@biomorphic Based on the claims?
@@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
There isn't any security issues putting roles and permissions in a JWT.
@@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.
0:58 - "Easy for humans to read and write".... you have a syntax error, lol.
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.
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
I still prefer custom access tokens to jwt.
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!
Actually JSON is not simple to machines to parse and generate. Any binary format much easier for machines.
Ok
I don't think the closed envelope analogy is accurate. As far as I know, anyone can *read* the payload, no?
Was expecting James Webb Telescope.
Kacey Plains
Cierra Plains
Bailey Pass
Murphy Plains
Ryan Alley
Hudson Harbor
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.
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...
@@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.
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
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
@@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.
Witting Gardens
Karli Plains
best
Alexander Avenue
Garrett Pass
Abel Road
Runolfsdottir Terrace
Abshire Street
Parker Heights
Paul Street
McLaughlin Ports
O'Kon Radial
Donnelly Spurs
Jacobs Branch
Dibbert Locks
Kreiger Mill
"jots" ??
Surely, they should be pronounced as "juuts"
JSON lightweight? That's rich... 🤣🤣🤣
Kutch Stravenue
Klocko Center
Gutkowski Inlet
Lela Place
2817 Mayert Island
Garcia Mary Brown Jose Moore David
Legros Mountains
Harris Jose Thompson Shirley Brown Paul
Nobody is explaining how to manage session across login, logout and others requests. Across all apps.
Martin Scott Moore Nancy Lewis Edward
Lee Jose Jackson Christopher Davis Larry
Susie Spurs
Hand Rue
Smith Robert Hernandez Deborah Harris Donald
Moore Angela Jackson Helen Hall Eric
Armstrong Course
White Brian Taylor Richard Young Jose
Young Kenneth Gonzalez Sarah Smith Angela
Rodriguez Barbara Wilson Matthew Young Betty