SFNode Meetup: Why JWTs Are Bad for Authentication - Randall Degges - 2018-01
[ Thank you to our video sponsor MongoDB: www.mongodb.co... ]
[ Slides: speakerdeck.co... ]
JSON Web Tokens (JWTs) are all the rage in the security world. They’re becoming more and more ubiquitous in web authentication libraries, and are commonly used to store a user’s identity information.
In this talk Randall Degges, Head of Developer Advocacy at Okta, will take you on an extensive tour of the web authentication landscape. You’ll learn how JWTs and Sessions work, and why JWTs are the worst possible solution for solving web authentication problems.
You’ll also learn the real reason behind JWTs rise to fame, and better ways to secure your websites that don’t involve misplaced hype.
About Randall Degges
Randall Degges leads Developer Advocacy at Okta, previously Stormpath, where he builds open source security libraries and helps make the internet a little safer. In a prior life, Randall was the CTO of OpenCNAM, the largest Caller ID API service.
In his free time, Randall geeks out on web best practices, explores new technologies, and spends an inordinate amount of time writing Python, Node, and Go projects. As a fun fact, Randall runs ipify.org, one of the largest IP lookup APIs which serves over 27 billion requests per month.
He writes at rdegges.com, and tweets as @rdegges.
Пікірлер: 51
I enjoyed this presentation. Thanks. Informative enough to remind that all change and industry focus is not necessarily beneficial by default.
loved the talk. loud and clear.
I love this guy's attitude...good talk
27:59 authenticate for multiple sub domains 45:30 use jwr for file download auth and forgot password email link.
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
5 жыл бұрын
I do touch on that towards the end of the talk. I discuss where they can be used safely and how =)
@seanharricharan7602
Жыл бұрын
@@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.
Listing pros and cons is a really really bad way to prove something because basically you control what you want to list
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 :)
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...
@Kingromstar
3 жыл бұрын
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?
@mohamedlamineallal5523
3 жыл бұрын
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).
Quite interesting. Thanks for the talk. 👍
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?!?
Can you really trust a man that has a bag full of beef jerky that he calls candy?
becaus they're not
"Let the hate flow..." 😆
Don't use JWTs for your hello world project.
Very funny, Okta is actually using JWT for authentication now and that talk is just bs.
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.
@AdamFJH
3 жыл бұрын
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.
It is enough to say that JWT is an AUTHORIZATION instrument not AUTHENTICATION. Use right thing in right place! Stupid talk
@alasdairmacintyre9383
2 жыл бұрын
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.
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.
@gabrielbarroso4118
6 жыл бұрын
You can't access http only cookies: www.owasp.org/index.php/HttpOnly
@vishalasthana8998
4 жыл бұрын
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.
@someguyO2W
6 жыл бұрын
Capitaine Haddock I couldn't agree more.
@tophergates
6 жыл бұрын
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...
@MultiWillow33
6 жыл бұрын
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)