00:00 Introduction 5:08 HTTP-Cookies 06:49 Session-IDs to add more trust to cookies 09:20 Problems with Session-IDs when having multiple servers in parallel - shared cache - distributed cache - sticky sessions 15:29 Json Web Tokens 15:53 "Cockies" vs "Session ID" vs "JWTs" 16:43 Two kind of tokens - "by Reference" - "by value" 17:45 Authentication and Authorization with a JWT as Cockie 19:20 Structure of JWTs 26:13 Benefits of JWTs - simple load balancing (no state) 28:29 Signatures - symetric - asymetric 29:49 OAuth2 and OpenID Connect 31:26 Drawbacks of JWTs - Revokation - Same as SessionId - XSS Attacks 41:32 Other JWT applications - multi-part user forms - confirmation emails
@PratozTube6 жыл бұрын
thank you very much for your effort!
@sunilsawant26215 жыл бұрын
Thanks
@micalevisk4 жыл бұрын
41:32 Other JWT applications - multi-part user forms - confirmation emails
@-andymel6 ай бұрын
@@micalevisk thanks, have added this
@mspiderv5 жыл бұрын
He said that the drawback of JWT stored in cookies flagged as HTTPOnly is that you cant read the payload from JS. There is a simple solution for this problem. You can split the JWT into 3 parts (header, playload and the signature). Then you can set two cookies. The first one flagged as HTTPOnly will contains header + signature and the second one will contains only the payload and will not be flagged as HTTPOnly so you can read it from JS. XSS attacker can read or modify the payload, but thats ok, because he cannot access the signature, so the modified token will be invalid.
@titocito Жыл бұрын
That's veery clever, thank you!
@darshandhabale14311 ай бұрын
@@titocito still doesn't solve the problem| the hacker can brute force all the common algos and hit a valid jwt he doesn't need to modify the jwt if he wants to impersonate the user
@titocito11 ай бұрын
@@darshandhabale143 how is that? I don't get the vulnerability you are pointing. how can a XSS attacker impersonate the user if it has no access to the signature (assuming that brute forcing the signature is a very expensive and slow operation)? Or are you are talking about that vulnerability when the server starts trusting algorithms defined by in the JWT payload? To fix it make the server never trust the "alg" defined in the JWT and use a hardcoded one check it against a list of trusted algs which exclude the "none" one.
@timm.68757 жыл бұрын
Finally someone does know how JTW's should be used and is not talking shit about it like dozens of others here... thx Hubert
@adamgm847 жыл бұрын
This is the best JWT explanation I've seen. I love your inclusion of CSRF as well.
@srghma4 жыл бұрын
- jwt cannot be compared to cookies, but can be to session id: session id - by reference, credit card, jwt - by value, banknote
@Mrhennayo7 жыл бұрын
Merci pour cette présentation : the best JWT explanation and security issues that one can have.
@rahulgaba5 жыл бұрын
Amazing explanation of JWT and session persistence. One question though: At 43:10, you suggested using sessionID at API gateway. Does this mean that the API gateway will have some storage mechanism? If yes, then won't it have the issues that you had mentioned at 10:05 ?
@omrip236 жыл бұрын
What prevents an attacker from reading my local storage, retrieving the sync token and then submitting a form with the cookie + that sync token and perform a CSRF attack?
@AtulR5 жыл бұрын
You cant do this from another site if you set your cookie to have httpOnly attribute, hence attacker site wont get the cookie itself
@thegrandmaster555 жыл бұрын
Atul R so if the attacker can’t use the cookie, what’s the need of the extra item in thr local storage?
@GioeleMoretti5 жыл бұрын
I'm not sure if I get this right, but here is my consideration (using the Twitter example): In a CSRF attack the attacker can use the twitter cookie. The attacker cannot read it but it will automatically be sent with the request to the twitter server (see 36:44). At the same time, since the attack is performed on another web app, the attacker has no access to the local storage of twitter, so he can't read the authenticity-id. If the attacker manages to run malicious code in the twitter application (via library or an XSS attack), the attacker get access to the local storage, therefore to the authenticity-id. However, the attacker won't be able to read the cookie because of the httpOnly flag. But in the second case, I don't see what prevents the attacker to post something on twitter on behalf of the victim.
@HeyDan19835 жыл бұрын
Good question I was hopping to someone ask it. Hopefully someone in te comments can answer.
@vncntjms3 жыл бұрын
Yes I support this. I don't understand as well.
@madhurgwa7 жыл бұрын
nice explaination, which tools you used to create all the diagrams?
@sgtnotorious7 жыл бұрын
I would like to know this as well!
@sunilk97605 жыл бұрын
author has no time to answer
@michaeljean-jacques74137 жыл бұрын
Great explanation on the advantage of using JWT token vs Session IDs.
@aprofromuk6 жыл бұрын
need to see it at 1.25x atleast, but good talk :)
@shef91924 жыл бұрын
1.75 is better :)
@darshandhabale14311 ай бұрын
2x is even better @@shef9192
@fredscholl52507 жыл бұрын
Really brilliant talk!
@vipzip88636 жыл бұрын
Awesome talk, is this presentation slides available somewhere online?
@jeromelanteri64694 жыл бұрын
Very nice, very clear, perfect. And as neighbour (i'm french), i like your french accent (but mine from south of french is also much more incredibly nicer, i promise). :)
@gilesthompson46057 жыл бұрын
There are two potential problems with this approach in my humble opinion..... Firstly using JWT means now I have a (JSON) data structure readily available on my client machines, in plain text (well base64 which is tantamount to plain text,) that perhaps contains sensitive application information that was previously only available to my web/application server. Secondly doesn't this violate SoC. Why should my clients even care about application state or contextual data? Shouldn't thin clients like web browsers be completely stateless and really only care about rendering and presenting TRANSIENT data returned over the scope of a GET/POST request. Perhaps I'm missing something, best practices seem to shift so fast in application architecture and thus it is entirely possible that the approach I've outlined is now considered to be a bit antiquated.
@kamikaze34077 жыл бұрын
Thanks for the simple explanation and entertaining presentation. It would be nice if you can clarify the following @ 29:30 you are talking about a "Security Provider" holding a private key in one of the servers and others holding the public key. Initially i thought that the info from all other servers will be served after an authentication check with the Security provider server BUT then i saw there are no connections between the servers themselves to the Security Provider. So 1. Is this some form of content segregation across servers where the authenticated users content and unauthenticated users content are kept and served separate to distribute the load ? If not can you kindly explain why there are no connection between the servers with the public key to the server with the private key ? 2. If all other servers rely on the Security provider server to let them know whether or not to server the content, then wont the Security Provider server will become the Single Point of Failure ? 3. Having a public key in cookie and storing the private key in the server to authenticate, How different is this from storing a session ID in the cookie and storing the session ID reference in the server to authenticate ? Pardon me if my questions are too basic (and for the long post), really appreciate if you can shed some light on these for my better understanding
@johnestess58957 жыл бұрын
That's funny. I also bought my first computer in 1994 - a Quantex P90. That was close to the state of the art for Wintel machines at the time. Not many weeks later Slackware was installed. :-)
@rohithreddyvadiyala23607 жыл бұрын
thanks for the amazing explanation on JWT. I have question here. suppose say the expiration of the JWT token is 15mins after its creation but the user logout/close browser just after 5 mins. Now, I need to destroy the created token. how can I do that. any kind of help is appreciated.
@dreuter7 жыл бұрын
My solution would be to delete the cookie instead. The token will still be valid, but the users browser won't send it anymore. Again, this wouldn't be a good solution for banking software, but for the "right" user experience it would suffice, if the token was not stolen in the mean time. If you want to prevent that beeing an issue you will need to implement a blacklist (at least as far as I know).
@pradeepsamuel67477 жыл бұрын
You need to play with the signing secret used to sign the JWT token, a naive implementation would be to generate a user specific secret and a server specific secret, so to sign the jwt you combine both the secrets and sign it, so now if you need to revoke the access for a particular user you change the user specific secret in the datastore or if you want to revoke all the JWTs used in the entire system from working you just change the server secret.
@microtech24486 жыл бұрын
There does not seem an universal way to solve the problem. Tokens by nature are persistent until their expiration. To revoke them you need to workout on server end as well, check the token at each request against database for instance.
@CarloL5253 жыл бұрын
Very clear. Thank you!
@shibinfr3 жыл бұрын
Great. Well explained.
@brandondiaz901 Жыл бұрын
Is this still valid in 2023 or should i consider any other vulnerability? Thanks and great lecture
@rahulsen55848 жыл бұрын
Wonderful explanation .
@varunshenoy5327 жыл бұрын
I didn't understand the use of asymmetric key. If the public key is leaked, I could still fake identities?
@adamgm847 жыл бұрын
Do a quick Google on how PKI (public key infrastructure) works and it will answer all your questions about the private and public key use.
@atif19967 жыл бұрын
Public keys are only used to check the signature, you could literally save them in a public url with no problem. Only have a problem if the private key is leaked.
@tintin-qu4gs6 жыл бұрын
Very nice lesson
@mazyvan8 жыл бұрын
really interesting. thanks for sharing
@jadsayegh62837 жыл бұрын
Awesome talk, debunked a lot of misconception I had about JWT and security
@daniellevanon5 жыл бұрын
Great explanation
@kharika55514 жыл бұрын
can anyone help me how to implement jwt in microservice architecture?
@berndeckenfels5 жыл бұрын
Wow, did not remember the level codes of Lemmings
@Sun0fABeach5 жыл бұрын
Active subtitles recommended
@evandrix8 жыл бұрын
link to downloadable copy of slides pls?
@shipup84547 жыл бұрын
awesome. thank you very much.
@nid2747 жыл бұрын
even though session can be saved from single point of failure using jwt, an application needs to save lots of internal data in databases. what if they fail? If you can make them fail proof then there is no problem for normal sessions and no need for jwt
@dkryptr7 жыл бұрын
That involves paying more money for extra servers to ensure sessions are highly available. JWTs do not require this.
@contactoliverwhite7 жыл бұрын
this is amazing
@elnatanvazana82804 жыл бұрын
18:42 "I'm a cookie, what do I do?"
@Luclecool1233 жыл бұрын
Not much 😅
@mishasawangwan66522 жыл бұрын
you send the cookies
@medi75736 жыл бұрын
@kzbin.info/www/bejne/bGjQlq2BaLOtprc ,cant the attacker access the local storage get the csrf and then send a request on behalf of the authenticated user ?
@user-tk7zn6pc5x6 жыл бұрын
Talk starts at 16th min.
@manee427 Жыл бұрын
amazing
@TomaszRychter7 жыл бұрын
94' PC and screenshot from Windows XP - not cool ;)
@tibordigana25515 жыл бұрын
It's amazing how the people reinvent the wheel with JWT claims and cookies. Setting the Path, Domain, Session ID already exist in RFC-7519 (iss, sub, aud, jwi).
@wildbakaar8 жыл бұрын
95% of the room played Lemmings, really ?
@hsablonniere8 жыл бұрын
Yeah, I would say more than 90% of the room voted yes ;-)
@mojavelinux8 жыл бұрын
I can confirm that. I only wish I had taken a picture.
@minaitconcepts72986 жыл бұрын
thats so cool i hardly know anyone who played it too. :(
@viky2936 жыл бұрын
Why do we never start first talking about load balancer getting failed?
@jumanjimusic40945 жыл бұрын
You have bigger issues then than the token or any other solution.
@fredpies5 жыл бұрын
nice
@spillow7625 жыл бұрын
This guy talks like Stan Wawrinka.
@carnelyve8666 жыл бұрын
SessionID is not an issue. Apple Music Store is a stateful application and it scales.