Demystifying cookies and tokens | Hacker News Reader

Demystifying cookies and tokens

tommihovi.com

103 pointsfagnerbrack16 comments

I'm hugely grateful for this article: it's the first I've seen that explains JWTs end-to-end with the technical details of how to implement and inspect them on the browser side, including storage.

I haven't needed to understand JWTs in depth, so have never spent the time to do a deep technical dive, but I'd still like to understand how they work. Every time I see a JWT article pass by, I'll jump in and find the general concepts explained but with enough technical gaps that I couldn't understand them in practical terms, especially when compared to my years of previous web-dev experience with cookies.

Also thanks to @unscaled for pointing out PASETO, which aims to fix some of the many problems with JWTs: https://paseto.io/

Third party cookies are not just used for tracking - they are also any cookies set in an iframe. There are legitimate use cases for third party cookies. Chrome recently rolled out partitioned cookies which addresses part of the problem. If you are trying to authenticate via sso to then show content in an iframe, this just doesn't work, though. There is some behind the scenes trickery you might be able to use with reverse proxies but it's painful. I setup some systems using keycloak and nginx to force the iframe and idp on the same domain. You're out of luck if you're using Azure AD or any third party idp, though.

Fortunately for all those who rely on the state of ambient authority on the web remaining _roughly_ as it has been for the past ~30 years Google _just_ backed down from shipping partitioned cookies.

https://privacysandbox.com/news/privacy-sandbox-update/

> OAuth uses access tokens, which are typically, but not limited to, JSON Web Tokens

This claim is misguided, but I hear it quite often. JWT is a very popular (and downright terrible[1]) format, but I there is no evidence that most of the tokens use JWT. It could be worse - I've heard some people claiming with confidence that OAuth mandates JWT.

The reality is that OAuth 2.0 predates JWT, and the implicit assumption was that all tokens are stateful. The access tokens in the examples are all short, and the spec strongly recommends revoking access tokens in case of access code reuse.

This makes JWT access tokens a non-canonical implementation of OAuth 2.0. You could add a "jti" claim (or "uti" claim in case of Microsoft) and then check for revocations in Redis, but then your only achievement was bloating up your access tokens by a factor of 20. Congratulations!

That's the reason why the other Big Tech companies are not using JWT for Access Tokens. It just doesn't make sense when you are at the scale where you need access tokens to be small and moderately long-lived. Users of JWT are more heavily concentrated on the smaller scale: more recent startups and enterprise customers.

---

[1] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

There’s a lot to say about the problems of JWTs, but they absolutely are extremely widely used for access tokens, and by many big players (Microsoft, Okta, etc). The JWT RFC is a product of the OAuth working group.

> Users of JWT are more heavily concentrated on the smaller scale

JWT isn't particularly useful for the smaller scale either: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

After reading that article a while back it wasn't really clear to me why JWTs are necessarily a bad choice for authentication, aside from the issue of invalidating stateless tokens.

The main argument seems to be vulnerability to attacker supplied JS (when kept in local storage). But if you're targeted by a supply chain attack, I assume you have a lot more to worry about than token exfiltration.

The complaint about lack of battle-tested JWT implementations seems outdated as well.

The first thing that pops up is

> We use cookies to ensure that we give you the best experience on our website.

> Accept | Decline

Do "non-essential" cookies actually make my experience any better? I always decline and haven't noticed a difference from the pre-GDPR days.

I have only seen it as harassment mainly on news sites. "We cannot play this video" or the all too common Twitter or Instagram embeddings. On one hand I know I waste my time but I am such a weirdo I make "my stand" by always declining. Are the consent forms too broken or conveluted I usually leave the site. But we are in the minority and all of us are probably HN users. And my gut feeling is that on HN we are still a small minority. I think the more common approach here is auto accept extensions.

That’s funny - I similarly “make my stand” — but it’s against GDPR silliness by always accepting all. I literally do not think my life would be better if I saw a bunch of crappy untreated ads for “one weird trick,” diet snake oils, etc. so I have zero problem with targeted ads and the cookies that enable them. Though I’ve seen firsthand all the ridiculous overhead cost this crackpot law has imposed on all companies, who literally do not care who I am, they just want me to buy a laptop or something.

All this to avoid users just setting their browsers to discard cookies according to their wishes, an ability they’ve had for a decade or more.

I find these cookie banners twice as annoying as ads ever were.

Speaking from my own experience, and implementations, it rarely has any direct influence.

It is a roundabout way of saying that “if you accept we will get some additional data that will influence our decision-making”. Which in turn could help prioritise bugs and features related to what you did when visiting the site.

On rare occasions, it can have direct influence, such as if you are searching for an ambiguous term we could forward the product categories you browsed recently to a third party search engine for different weights on the results. This actually has a positive effect with higher click-through on results, fewer searches, and click position nearer the top.

Do not take this article for granted. There are so many incorrect explanations in it. This is a really bad writeup for a security blog. I really don't know where to start ...

Please point them out here.

* "Session ID" is not a cookie attribute akin to path or expires.

* There's no "Session" attribute -- (when no expires is set, it's a session cookie)

* session cookies deletion is misstated

* JWTs are just a possible format for OAuth, not a requirement

* incorrectly states that jwts are signed but not encrypted

The description of SameSite isn't correct. I have some notes on that here: https://simonwillison.net/2021/Aug/3/samesite/#samesite-cook...

> As an application developer, you should set all cookies with SameSite=Lax

This is really good advice and has bitten me in the past, I think as someone who is new to this it is tempting to avoid the term "Lax" but you might end up with some surprising behavior if you go with "Strict" as your default.

I also attempted to make sense of it all and created https://samesite.diduthink.com

Reply on news.ycombinator.com