Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JWT is Awesome

thehftguy.com

Post reply on HN
Print view View original

111–120 of 170 posts

Re: JWT is Awesome

#111

Post by Supermancho »

enumjorge wrote: post #71
cryptica wrote: post #42

Earlier quoted context omitted.

That article doesn't contain a single logical argument. >> JSON Web Tokens are Often Misused So is everything else. Name one programming concept which isn't often misused. >> There were two ways to attack a standards-compliant JWS library to achieve trivial token forgery The keyword here is "were" - Just like how people in Europe "were" dying from the Bubonic plague - It doesn't mean that Europe is unsafe today. The…

Can you elaborate why session IDs inside cookies is dangerous?

I can manipulate my cookies. I can forge my servserside session id for session hijacking. This is what I understood.

Re: JWT is Awesome

#112

Post by Rapzid »

Ficirdly wrote: post #57
teyc wrote: post #32

https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally…

Just not Macaroons again :( Macaroons have many small edge cases that'll bite you when you try to use them in practice: - there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use. - the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not. - the implementation requires custom parser for custo…

Perhaps you're just not sophisticated enough to evaluate token formats based on their intrinsic design /s

Re: JWT is Awesome

#113

Post by user5994461 »

skrebbel wrote: post #66
anonsivalley652 wrote: post #18

Earlier quoted context omitted.

Popularity != value. Get over false signals.

Popularity definitely is value when designing APIs for public consumption. JWT has a concrete edge here. This is why I asked HN about their opinions on Paseto, if there's a chance it'll overtake JWT/JWE in popularity, then that makes it more suitable for APIs. In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.

Author here. As a matter of fact, the world has already settled on JWT. Paseto is dead in the water and will never gain any traction.

Every single company has no choice but to support JWT in some capacity. Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).

Re: JWT is Awesome

#114

Post by peeters »

nijave wrote: post #25
tmikaeld wrote: post #4

Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I have to say (2018): https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it…

That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session I…

Yeah I was hoping for a fair comparison but it seemed like a pretty big strawman. Like he just takes it for granted that "a session cookie is a cryptographically-signed identifier" but that's not remotely standard. At its most common (looking at you, JSESSIONID), simple form, the session cookie is a securely generated random number that is used as an index for state, and signing plays no part. The presenter then goes and talks about how cookies can be used to store other pieces of data in a stateless way, but it all branches from this premise that cookies are crypotgraphically signed, which isn't historically true.

Re: JWT is Awesome

#115

Post by user5994461 »

ascotan wrote: post #102
jayd16 wrote: post #88

Earlier quoted context omitted.

Sessions could be stolen too. The rest are essentially trade offs with the expiration mechanism. If your use case can't handle that, don't use JWT.

ergo: if it's ok to have an un-revocable insecure session - use JWT tokens.

Or use JWT + OpenID Connect in a centralized mode, as the article explains toward the end.

Re: JWT is Awesome

#116

Post by abhgh »

onionisafruit wrote: post #61
0x445442 wrote: post #45

The string 'JSON Web Token' doesn't appear anywhere on the web page. If you're going to use an acronym expand it out the first time you use it.

I expected this to be about Java Web Toolkit until I saw it was implemented in many languages.

Thats what I thought too.

Re: JWT is Awesome

#117

Post by com2kid »

ascotan wrote: post #108
com2kid wrote: post #104

Earlier quoted context omitted.

JWTs are nice because the same authentication scheme can be used for applications and websites. Basically a bunch of endpoints can be put up, and if they use JWTs, it is easy to hit those endpoints from any type of app. Cookies can of course be used, but that requires pulling cookie jars into native code. Perfectly do-able, but also super awkward and potentially error prone. e.g. I remember using apps on Windows that…

There is no need to write to a cookie in server-to-server auth, just pass an auth token back in a custom header. No JWT required. Cookies are for offline users.

> just pass an auth token back in a custom header.

At that point why not just use JWT?

If my auth service provider already uses JWT (which it does), and all the platforms I am writing on have a provided library that consumes JWT (which they do), then why would I go with a custom header?

Also having uniformity of code patterns is nice.

My web service uses the same authentication scheme as my native apps. Heck my backend DB knows how to look JWT tokens and apply permissions correctly.

Re: JWT is Awesome

#119

Post by user5994461 »

tpetry wrote: post #6

„9) Myth: JWT doesn’t support logout or invalidation. (It can with OpenID Connect)“ Iterating on how invalidation work with OpenID Connect when in a point before the author said an authentication service which can go down is a single point of failure you should avoid. So he added a spof by using openid connect...

It's all about trade offs. If you want full session management, not everything can be decentralized. People often say that JWT can't handle sessions at all so I am merely explaining that it actually can out-of-the-box and how to make it work.

Anyway, there is always a single point of failure somewhere. There's got to be something that authenticates users and creates tokens in the first place.

Re: JWT is Awesome

#120

Post by holtalanm »

miguelmota wrote: post #86

Reasons why JWTs are not awesome: - to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it's valid. - JWT are to prevent database calls but a regular request will still hit the database anyway. - JWT are very large payloads passed around in every request taking up more bandwidth. - If user is banned or becomes restricted then it still requires database calls to ch…

if you have gotten to the point where you need to hit the database to verify the JWT, something is wrong. Either need to turn down your JWT expiry time, or refresh your JWT more often, or both.
Post reply on HN