This talk would have offended less people if he talked about where JWTs are useful and where they are not. I would say JWTs are useful for back-end internal APIs where the JWTs belong to the nodes in your network and signed only between the nodes that communicate with each other, and not a single uniform signature across the network. In this design, if there is a security breach it makes perfect sense to replace the keys on the nodes that were comprised and the ones that talk to those nodes (no need for revocation list just replace it)....JWTs don't make any sense in storing user submitted information. As he said, this complicates how you will ban trolls, delete users, allow users to delete themselves, etc etc. If in your architecture you can solve this with a single revocation list sitting in memory on a single node, and not a DB, then you dont have the scalability issues that would have justified reducing database round trips in the 1st place.
@@randalldegges-legacy I'm new to web design, dev ops and web security (little over 1 year experience) and when I started learning about authentication and authorization, JWT tokens in the form of access, refresh and id tokens were everywhere but from my intuition, it seemed as if there still were underlying issues with the technology and not much benefits holistically than cookies, sessions and even SAML. This presentation opened my mind to the world of authentication and authorization and proved some of my doubts right. Thank you for that.
I interesting talk. I think the point about adding an expire time to sessions wasn’t fair, since someone can just change the expire time in the session, you can’t do that with jwt. Also, the jwt will scale better, since I’m not making a database request to verify a jwt, ever, I can use the database only for retrieving what I need and not have to ping the database on every api/page request, which I would have to do with sessions. That would add up to a huge amount of wasted database requests. Also, I don’t store a users name or email in a token, I would see that as a security risk, and you can just get that from the database if your getting the profile data etc...
well if you store your session in Redis you'll have to look it up with or without a JWT so unless if you have a super simple app that doesn't have real session data in Redis or a DB then this is a moot point.
Thanks, this was so refreshing, I too stumbled upon dozens of online tutorials preaching the superiority of JWT and saying it's used by large companies, but not _how_ . One question though, you said when talking about password reset link that the JWT is sent in the URL? I thought the JWT was information stored in the local storage - how is stored there if it's in the URL?
The token is send through email directly. The link for reset reach an endpoint in the backend. And that generate the token and send it to the person email. Only that person get it. And a token is thr passport that grant access. It's like me sending you. Your passport or access card with a trusted mailer person or something. Tokens have nothing to do with storage. And then it's about how the backend retrieve them. Expect them arriving. And validating. Validation is just the verification of the signature. Depending on the cryptographic algorithms for signature that was chosen. It's mainly some mathematical computation operation. and it go from hashing algorithm. To asymmetric crypto algo. Or symetric in case of symetric signature. (In most cases asymmetric is to be used).
this is bullshit, the biggest advantage of JWT is that I don't need to hit the DB for every request to fetch session data. The only disadvantage is it is hard to revoke the tokens on demand, however the combination of access tokens and refresh tokens is a pretty good solution.
If a user's account is compromised, it is a good thing that the cryptography keys are also reset in case the cryptography keys are also compromised. All the things this guys has said can be resolved and really aren't issues. I do agree that JWT are more complicated than session IDs but for session IDs to be as secure as JWT, they need to be just as complicated. It all depends on how both are implemented.
"the biggest advantage of JWT is that I don't need to hit the DB for every request to fetch session data", so I changed your role from 'admin' to 'user' and you still can perform admin actions for some time until you refresh the token. What's the security benefit here? It doesn't sound like an advantage at all
Lol, because hitting centralized state one additional time for each request is better... hahaha. Seriously, this talk is 99% FUD, like about every anti-JWT-article on the Internet. Use very short expiration, use refresh tokens, enforce signing with either RS256 or HS256 with ephemereal secrets and you're set. Stateful session handling is plainly stupid and amounts to self harming behaviour in the day and age of microservices and cluster based backends. And don't get me started on the oversimplification / red herring of "bawt you need to do CRUD anyway for each request". Are you kidding me? Any developer with an IQ of > 80 knows how to use pub/sub (Redis mq, for example) to move into ultra scalable, async territory. DB access takes 100 ms? Just throw a message into Redis and let your background worker services take it from there. Come one, you can do better. And if you wonder about my credentials: I'm 20+ years of professional experience in software engineering, I'm the lead software engineer where I work and I insist on yearly security audits by an external party.
"use pub/sub (Redis mq, for example)", then what's your reason to use JWT which was created to actually skip DB calls? Hitting DB is not better for performance reasons, it's better for security reasons. Your app can be fast OR secure. Using refresh tokens is okay but if your token is valid even for 30s, it's enough time to do bad things as an 'admin' even if 20 seconds ago your role has been changed to 'user`. It's not an immediate action which is high security risk. These 20s with a simple script can look like leaving an access to a human for 2 weeks. I don't want you in my system IMMEDIATELY, not in 20s-30s when your token expires (which is hard to do without a DB and if you used DB, your JWT doesn't make any sense in this case, not bringing any advantage). Imagine telling your boss "oh yeah, we revoked hacker's access, he will be removed from the system in 30s (2 weeks)". If that's your experience after 20+ years - I'm worried that you wasted these 20 years on flexing with titles
6 лет назад+3
I don't understand. What do you mean by JS can't access a cookie? `document.cookie` will return all the cookies for that subdomain, and you can also set them. Also, you can set a cookie for any subdomain from your application, you don't need to forward with a 10 second JSON token. This talk has great claims, but fails to deliver on great evidence.
I thought this must be common knowledge but if you set httpOnly : True; you cannot access that cookie through JS Code and the cookie will only accept http requests
I am curious as to why you feel this is the worst talk you’ve seen in awhile? You have not offered any information to indicate why you feel this way or what information that was presented is inaccurate...
I think he has quite a legit argument for giving such a talk. I have gone through two paid tutorials and none of them mentioned anything about why they were using JWTs for auth. Both of them used different type, one of them used local storage(XSS) and the other one would be made more efficient with sessions (checking token with DB EVERYTIME). Users should be familiar with best use cases, which are a couple more than he stated, but not many (i.e. using two tokens: refresh and auth)
I enjoyed this presentation. Thanks.
Informative enough to remind that all change and industry focus is not necessarily beneficial by default.
27:59 authenticate for multiple sub domains
45:30 use jwr for file download auth and forgot password email link.
I love this guy's attitude...good talk
This talk would have offended less people if he talked about where JWTs are useful and where they are not. I would say JWTs are useful for back-end internal APIs where the JWTs belong to the nodes in your network and signed only between the nodes that communicate with each other, and not a single uniform signature across the network. In this design, if there is a security breach it makes perfect sense to replace the keys on the nodes that were comprised and the ones that talk to those nodes (no need for revocation list just replace it)....JWTs don't make any sense in storing user submitted information. As he said, this complicates how you will ban trolls, delete users, allow users to delete themselves, etc etc. If in your architecture you can solve this with a single revocation list sitting in memory on a single node, and not a DB, then you dont have the scalability issues that would have justified reducing database round trips in the 1st place.
I do touch on that towards the end of the talk. I discuss where they can be used safely and how =)
@@randalldegges-legacy I'm new to web design, dev ops and web security (little over 1 year experience) and when I started learning about authentication and authorization, JWT tokens in the form of access, refresh and id tokens were everywhere but from my intuition, it seemed as if there still were underlying issues with the technology and not much benefits holistically than cookies, sessions and even SAML. This presentation opened my mind to the world of authentication and authorization and proved some of my doubts right. Thank you for that.
loved the talk. loud and clear.
A little rushed so some subtle points were missed but certainly captures a number of issues with the use of JWT for security.
enjoyed the talk. cleared up some things :)
Quite interesting. Thanks for the talk. 👍
I interesting talk. I think the point about adding an expire time to sessions wasn’t fair, since someone can just change the expire time in the session, you can’t do that with jwt. Also, the jwt will scale better, since I’m not making a database request to verify a jwt, ever, I can use the database only for retrieving what I need and not have to ping the database on every api/page request, which I would have to do with sessions. That would add up to a huge amount of wasted database requests. Also, I don’t store a users name or email in a token, I would see that as a security risk, and you can just get that from the database if your getting the profile data etc...
well if you store your session in Redis you'll have to look it up with or without a JWT so unless if you have a super simple app that doesn't have real session data in Redis or a DB then this is a moot point.
Great talk! Learned a lot!
I opened my eyes 😲
That guy single-handedly made me not trust Okta.
I get you have to sell your product but holy hell, do you have to be this disingenious?!?
Thanks, this was so refreshing, I too stumbled upon dozens of online tutorials preaching the superiority of JWT and saying it's used by large companies, but not _how_ . One question though, you said when talking about password reset link that the JWT is sent in the URL? I thought the JWT was information stored in the local storage - how is stored there if it's in the URL?
The token is send through email directly.
The link for reset reach an endpoint in the backend. And that generate the token and send it to the person email.
Only that person get it.
And a token is thr passport that grant access.
It's like me sending you. Your passport or access card with a trusted mailer person or something.
Tokens have nothing to do with storage. And then it's about how the backend retrieve them. Expect them arriving. And validating. Validation is just the verification of the signature. Depending on the cryptographic algorithms for signature that was chosen. It's mainly some mathematical computation operation. and it go from hashing algorithm. To asymmetric crypto algo. Or symetric in case of symetric signature. (In most cases asymmetric is to be used).
Listing pros and cons is a really really bad way to prove something because basically you control what you want to list
Can you really trust a man that has a bag full of beef jerky that he calls candy?
becaus they're not
Don't use JWTs for your hello world project.
"Let the hate flow..."
😆
this is bullshit, the biggest advantage of JWT is that I don't need to hit the DB for every request to fetch session data. The only disadvantage is it is hard to revoke the tokens on demand, however the combination of access tokens and refresh tokens is a pretty good solution.
If a user's account is compromised, it is a good thing that the cryptography keys are also reset in case the cryptography keys are also compromised. All the things this guys has said can be resolved and really aren't issues. I do agree that JWT are more complicated than session IDs but for session IDs to be as secure as JWT, they need to be just as complicated. It all depends on how both are implemented.
"the biggest advantage of JWT is that I don't need to hit the DB for every request to fetch session data", so I changed your role from 'admin' to 'user' and you still can perform admin actions for some time until you refresh the token. What's the security benefit here? It doesn't sound like an advantage at all
It is enough to say that JWT is an AUTHORIZATION instrument not AUTHENTICATION. Use right thing in right place! Stupid talk
Isn't he just arguing that sessions are a better authorization instrument?
Lol, because hitting centralized state one additional time for each request is better... hahaha.
Seriously, this talk is 99% FUD, like about every anti-JWT-article on the Internet.
Use very short expiration, use refresh tokens, enforce signing with either RS256 or HS256 with ephemereal secrets and you're set.
Stateful session handling is plainly stupid and amounts to self harming behaviour in the day and age of microservices and cluster based backends.
And don't get me started on the oversimplification / red herring of "bawt you need to do CRUD anyway for each request".
Are you kidding me?
Any developer with an IQ of > 80 knows how to use pub/sub (Redis mq, for example) to move into ultra scalable, async territory. DB access takes 100 ms? Just throw a message into Redis and let your background worker services take it from there.
Come one, you can do better.
And if you wonder about my credentials: I'm 20+ years of professional experience in software engineering, I'm the lead software engineer where I work and I insist on yearly security audits by an external party.
"use pub/sub (Redis mq, for example)", then what's your reason to use JWT which was created to actually skip DB calls? Hitting DB is not better for performance reasons, it's better for security reasons. Your app can be fast OR secure.
Using refresh tokens is okay but if your token is valid even for 30s, it's enough time to do bad things as an 'admin' even if 20 seconds ago your role has been changed to 'user`. It's not an immediate action which is high security risk. These 20s with a simple script can look like leaving an access to a human for 2 weeks.
I don't want you in my system IMMEDIATELY, not in 20s-30s when your token expires (which is hard to do without a DB and if you used DB, your JWT doesn't make any sense in this case, not bringing any advantage). Imagine telling your boss "oh yeah, we revoked hacker's access, he will be removed from the system in 30s (2 weeks)". If that's your experience after 20+ years - I'm worried that you wasted these 20 years on flexing with titles
I don't understand. What do you mean by JS can't access a cookie?
`document.cookie` will return all the cookies for that subdomain, and you can also set them.
Also, you can set a cookie for any subdomain from your application, you don't need to forward with a 10 second JSON token.
This talk has great claims, but fails to deliver on great evidence.
You can't access http only cookies:
www.owasp.org/index.php/HttpOnly
I thought this must be common knowledge but if you set httpOnly : True; you cannot access that cookie through JS Code and the cookie will only accept http requests
One of the worst talk i've seen in a while.
Capitaine Haddock I couldn't agree more.
I am curious as to why you feel this is the worst talk you’ve seen in awhile? You have not offered any information to indicate why you feel this way or what information that was presented is inaccurate...
I think he has quite a legit argument for giving such a talk. I have gone through two paid tutorials and none of them mentioned anything about why they were using JWTs for auth. Both of them used different type, one of them used local storage(XSS) and the other one would be made more efficient with sessions (checking token with DB EVERYTIME). Users should be familiar with best use cases, which are a couple more than he stated, but not many (i.e. using two tokens: refresh and auth)