What makes JSON Web Tokens (JWT) secure?

There’s a lot you have to think about when building frontend applications - routing, performance, animations, etc. Security often takes the back seat (not cool!)
Between cookies, tokens, keeping users authenticated, and handling resource access, security can become quite tricky. This talk looks at the implementation detail and usage of the popular methods of authorization: JWT(JSON web tokens) and see what makes it secure in the first place?
The talk covers:
1. What is JWT?
2. When should you use JSON Web Tokens?
3. Structure + Implementation
4. Usage
5. What makes them secure?
6. Can JWT be hacked?
Siddharth works on Design systems at Auth0. He runs frontend.army and stackstickers.shop on the side. Past: Frontend architect at Practo
Slides and summary on: hasgeek.com/jsfoo/2018/schedu...

[@SomjitNag]

This video is brilliant. The speaker's expertise shines through! relevant even after so many years, which is saying something for a tech video!

[@NT-qv1ix]

One thing that is worth to be pointed out is at 8:22, the lecturer said the createHmac() is doing encryption, it should be a slip of tongue. As HMAC stands for Hash-based Message Authentication Code, and the Node API doc also express the same meaning. Do remember: *Hash !== Encryption*

[@ninadsubba5365]

0:21 JavaScript web tokens?

[@tathagatmani]

Java is everywhere

[@insaneviruss]

Wow. Loved it. Thanks for deep explaination and the vulnerabilities section!

[@ozzyfromspace]

I liked the section on jwt vulnerabilities. These are good things to ponder 🤓🙏🏽

[@mikeyinger4204]

That was a half hour well spent. Thanks.

[@karthibalaji3817]

Great content !. splendid.

[@nikhilpatil9654]

Thank you very much, sir !

[@hackersguild8445]

Very indepth. Nice content

[@philippec4448]

Great video ! I learned a lot, thanks!

[@NikhilBhalwankar]

Indeed a very good explaination. Thanks.

[@amitbaijal421]

Nice video - very informative

[@velakuruday]

Nice speaker. Clearly explained!

[@gavingonzalez7174]

Man I learn so much, thank you

[@lkprasanna]

If a client had access to two apis, can i use the same access token for both apis? Since the client app has access to both apis and the claims are not different between the two apis, what is the security impact of reusing the same access token

[@m4ynor]

16:05 JWT is vulnerable both to CSRF and XSS. The first when storing token in a cookie, the second when storing in the local storage

[@mathijsv6221]

So if you'd store the jwt in a HttpOnly cookie and secure your api with CSRF tokens, you should be alright, right?

[@anotherrohit]

HI siddharth - "The attacker can see the contents of the token, but cannot change it" Isn't the contents of the token enough for them to reuse the token as is against the API, why should they care about changing it if they already have the access token and can use to access the APIs at least till the validity of the token does not expire. Can you let me know how we can call this secure if they get the token and are enabled to use the API with the help of the token..

[@TZCoder]

This is correct JWT does not encrypt the data in the token it only signs the data so if a token arrives at the server the server can be sure that it(the server) was the one that originally generated the token. So https/SSL has to be used to prevent someone from reading the token. Another issue is tokens don't have any mechanism to revoke them, so even if you know it has been compromised it will remain valid until expiry date.

[@dummypg6129]

Is it suppose to be encrypted it with a secret key? Which both front and backend knows it.

[@TZCoder]

@@dummypg6129 Its not encrypted, it relies on the fact that the connection should be encrypted i.e TLS/SSL Https

[@tmarsha4]

​@@dummypg6129 Only the backend knows it. It decrypts it with the secret key and if it ends up with the same hashed result it knows the data is exactly the same AND the hash they sent also is correct. If a user gets the secret key then yes, all JWT's are compromised. The solution? Change the secret key. Done.

[@iambhanu7]

@@TZCoder I really wonder why nobody (training videos/articles) explicitly mentions that these tokens MUST be used along with https/SSL for it to be really secure. Or is it not the case ?

[@smitch_yt]

Thank you :D

[@mohammadashrafulalam8205]

How to generate json web token from Zip password protected file; please help me.

[@barwalgayatri4655]

Great Info Than kyou very much .Explained very well in details\

[@shivangitomar5557]

Amazing!

[@metalbroga]

How the “silent background authentication “ works? What do I send to the api to generate a new token?

[@abhishekhamal3126]

look up something called Refresh Tokens

[@vicbarbu]

"How does it compare to SAML?" "I have no idea". This says a lot lol.

[@ishi92]

amazing content! Thanks !!

[@LemuelUhuru]

At JWT.io it states to sign the token like hMAC(header + payload + secret) but with the npm library you used, it signs as hMAC(payload + secret). Why aren't we included the header here?

[@nicklesseos]

because the library does that for you...

[@dailyshorts1562]

may be because generally header contains algorithm and here already he mentioned not to pass algo with header and pass a white list otherwise anyone can make algo to none and jwt is just a joke than nothing else

[@santosh567890]

He totally missed the public key matching standard for JWT. Every token should have a kid or x5t claim in the header, this will act as an identifier to the key to be used for validating the signature. The x5t or kid is the base64(SHA1(public-key)).

[@m4ynor]

27:10 How the server will use the public RSA key? It should use the private one. Am I wrong?

[@manikantaraju9137]

He might have overlooked, it should be private to sign when it's RSA

[@brod515]

no he is basically saying that is a bug. he is showing how using rsa encryption with the public and private key pair can cause a problem. The JWT is signed using the private key and has to be verified using the public key. so even when it's the server verifying it needs to used the public key. he explained earlier @13:18 why this might be done (basically because you can share the public key with multiple servers but you wouldn't want to do that with a single private key). The problem with this is that some can take advantage of the fact they know the server is verifying with publicKey. they can just modify the payload and sign it again using the publicKey and claim that the algorithm is HS256; basically saying we are using a shared key, and guess what, we have the key it's the publicKey.

[@paypal7880]

Nice video. Make more

[@vasianurag9701]

Can't someone steal the token (by accessing your network requests, extract the header) and use that token to access the API's? How does it solve anything?

[@griffithe2438]

As far as I know, not, if you are using an security communication over TLS.

[@brod515]

no one should steal the JWT just like no one should steal your cookies.

[@ringoaikocascade]

15:05 I don't understand. Cookies are the way to transfer and store some data, and jwt is the format of the data to be sent in whatever format. They're not comparable.

[@softwarelivre2389]

He meant 'session' instead of 'cookie'. Weird mistake but yeah

[@Baha2490]

7:12 Looks like 32 alphanum chars, not random ASCII chars, so less than 2^192 possibilities instead of 2^256. "256-bit secret" is a bit misleading if that's the case (it's only the length, not the strength).

[@paypal7880]

1:58 hull , back to json web tokens. hehehe. What was that.

[@XbattlepopeX]

Its all about the salt

[@dhanitrianggara1772]

it would be better and safer, if the json web token and rest api were encrypted and decrypted sir

[@toddtroll2220]

Stopped listening after 2 minutes because the accent is to heavy for me as non native English speaker. But gave thumbs up because I appreciate talks like this.

[@imyounick]

Good, but nothing is secure in a web application. 1.For encrypting payload to send from Client to server, we need secret on both client side and server side. Attacker can easily get keys from dev tools. 2.Once the attacker gets the secret key and IV key also a stolen token you cannot go anything except deactivating your user. 3.No matter what your data can be masked/changed using above 2 points.

[@ringoaikocascade]

how do you access httpOnly cookie in dev tools?

[@imyounick]

@@ringoaikocascade In chrome dev tools ,filter XHR Request from Network tab if any of request sends cookie it will show up in Cookies tab.

[@ringoaikocascade]

@@imyounick so it's a manual work then. How do you get someone else's httponly cookie?

[@imyounick]

@@ringoaikocascade Same answer, manually is only way. Consider RDP hack

[@ringoaikocascade]

@@imyounick If I have access to someone else's credit card, or somehow let me use the card, and I use it to buy whatever I want, that doesn't mean credit card itself is not secure.

[@OskarCeso]

the sound is terrible omg how can people watch and like this. This is a video platform the sound is 50% of this ....

[@CarlosEduardo-cq1wv]

the accent very weird as well

[@niektuytel7861]

@@CarlosEduardo-cq1wv but what he say is usefull for hackers i thinks this is not to secure its possible i think kind regards niek tuytel

[@isynciswim7382]

The sound is fine to me, and his accent is not bad at all. I don't what the problem is. Are you guys just hating on him?

[@trophieboi1820]

@@isynciswim7382 Yes they are , there's a stigma to Indian accent...as an Indian I know it.

[@GreenyDe]

im not a native english speaker but i understand him perfectly fine, also the content was great!

[@mr.javascript1320]

lol he said javascript web token.......wat a NOOOB