100% Stateless with JWT (JSON Web Token) by Hubert Sablonnière

Подписаться 156 тыс.

Просмотров 120 тыс.

50% 1

Please subscribe to our RU-vid channel @ bit.ly/devoxx-youtube
Like us on Facebook @ / devoxxcom
Follow us on Twitter @ / devoxx
In our modern REST architectures, the session cookies of old are getting stale and crusty. It’s time to unbox JSON Web Tokens : a new approach, simpler, 100% stateless and easily scalable.
No more server side session storage. No more session replication across the cluster. Best of all, navigating multiple layers of APIs with only a single connection is much easier.
In this talk, you will discover the inner workings of JWTs. You will see how to handle a client session properly between a browser and a server. We will explore other usages and wrap up with pros and cons.
Hubert Sablonnière
I'm a curious and passionnate Web developer. I'm specialized in HTML, CSS and JavaScript but I also use server side technologies like NodeJS, PHP, Java, Neo4j, Docker...
With OpenDevise I help clients to move their trainings and conference talks to the next level.
My motivation : "To push the technology far enough to find new ways to improve user's experiences."
[DUK-7522]

Наука

Опубликовано:

8 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 79

@-andymel 6 лет назад

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

@PratozTube 6 лет назад

thank you very much for your effort!

@sunilsawant2621 5 лет назад

Thanks

@micalevisk 4 года назад

41:32 Other JWT applications - multi-part user forms - confirmation emails

@-andymel 27 дней назад

@@micalevisk thanks, have added this

@mspiderv 4 года назад

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!

@darshandhabale143 6 месяцев назад

@@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

@titocito 6 месяцев назад

@@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.

@adamgm84 7 лет назад

This is the best JWT explanation I've seen. I love your inclusion of CSRF as well.

@timm.6875 6 лет назад

Finally someone does know how JTW's should be used and is not talking shit about it like dozens of others here... thx Hubert

@Mrhennayo 7 лет назад

Merci pour cette présentation : the best JWT explanation and security issues that one can have.

@michaeljean-jacques7413 7 лет назад

Great explanation on the advantage of using JWT token vs Session IDs.

@fredscholl5250 7 лет назад

Really brilliant talk!

@srghma 3 года назад

- jwt cannot be compared to cookies, but can be to session id: session id - by reference, credit card, jwt - by value, banknote

@CarloL525 3 года назад

Very clear. Thank you!

@rahulsen5584 7 лет назад

Wonderful explanation .

@shipup8454 7 лет назад

awesome. thank you very much.

@contactoliverwhite 7 лет назад

this is amazing

@mazyvan 7 лет назад

really interesting. thanks for sharing

@shibinfr 3 года назад

Great. Well explained.

@tintin-qu4gs 6 лет назад

Very nice lesson

@rahulgaba 5 лет назад

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 ?

@daniellevanon 5 лет назад

Great explanation

@johnestess5895 7 лет назад

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. :-)

@vipzip8863 6 лет назад

Awesome talk, is this presentation slides available somewhere online?

@jeromelanteri6469 3 года назад

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). :)

@manee427 11 месяцев назад

amazing

@madhurgwa 7 лет назад

nice explaination, which tools you used to create all the diagrams?

@sgtnotorious 7 лет назад

I would like to know this as well!

@sunilk9760 5 лет назад

author has no time to answer

@omrip23 5 лет назад

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?

@AtulR 5 лет назад

You cant do this from another site if you set your cookie to have httpOnly attribute, hence attacker site wont get the cookie itself

@thegrandmaster55 5 лет назад

Atul R so if the attacker can’t use the cookie, what’s the need of the extra item in thr local storage?

@GioeleMoretti 5 лет назад

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.

@HeyDan1983 4 года назад

Good question I was hopping to someone ask it. Hopefully someone in te comments can answer.

@vncntjms 3 года назад

Yes I support this. I don't understand as well.

@jadsayegh6283 7 лет назад

Awesome talk, debunked a lot of misconception I had about JWT and security

@kharika5551 4 года назад

can anyone help me how to implement jwt in microservice architecture?

@kamikaze3407 7 лет назад

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

@aprofromuk 5 лет назад

need to see it at 1.25x atleast, but good talk :)

@shef9192 4 года назад

1.75 is better :)

@darshandhabale143 6 месяцев назад

2x is even better @@shef9192

@rohithreddyvadiyala2360 7 лет назад

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.

@dreuter 7 лет назад

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).

@pradeepsamuel6747 7 лет назад

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.

@microtech2448 5 лет назад

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.

@evandrix 7 лет назад

link to downloadable copy of slides pls?

@fredpies 5 лет назад

nice

@Sun0fABeach 5 лет назад

Active subtitles recommended

@gilesthompson4605 6 лет назад

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.

@brandondiaz901 8 месяцев назад

Is this still valid in 2023 or should i consider any other vulnerability? Thanks and great lecture

@varunshenoy532 7 лет назад

I didn't understand the use of asymmetric key. If the public key is leaked, I could still fake identities?

@adamgm84 7 лет назад

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.

@atif1996 7 лет назад

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.

@elnatanvazana8280 3 года назад

18:42 "I'm a cookie, what do I do?"

@Luclecool123 3 года назад

Not much 😅

@mishasawangwan6652 2 года назад

you send the cookies

@berndeckenfels 4 года назад

Wow, did not remember the level codes of Lemmings

@medi7573 5 лет назад

@ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-67mezK3NzpU.html ,cant the attacker access the local storage get the csrf and then send a request on behalf of the authenticated user ?

@user-tk7zn6pc5x 6 лет назад

Talk starts at 16th min.

@nid274 7 лет назад

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

@dkryptr 7 лет назад

That involves paying more money for extra servers to ensure sessions are highly available. JWTs do not require this.

@tibordigana2551 4 года назад

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).