4 ms·

Demystifying cookies and tokens

103 points by fagnerbrack 2y ago

eiururueuyeyd7 2y ago
[flagged]
4RealFreedom 2y ago
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.
- svieira 2y ago
  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/ https://privacysandbox.com/news/privacy-sandbox-update/
programjames 2y ago
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.
- clan 2y ago
  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.
  - xp84 2y ago
    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.
- Y-bar 2y ago
  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.
unscaled 2y ago
> 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-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
- notpushkin 2y ago
  > 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-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
  - sampullman 2y ago
    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.
- nmadden 2y ago
deleted 2y ago
[deleted]
st3fan 2y ago
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 ...
- PedroBatista 2y ago
  Please point them out here.
  - simonw 2y ago
    The description of SameSite isn't correct. I have some notes on that here: https://simonwillison.net/2021/Aug/3/samesite/#samesite-cookie-attribute https://simonwillison.net/2021/Aug/3/samesite/#samesite-cook...
    - zoidb 2y ago
      > 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 https://samesite.diduthink.com
  - thatha7777 2y ago
    * "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
yoz 2y ago
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/ https://paseto.io/
hgkghjnnvnvbdk 2y ago
[flagged]

103 points by fagnerbrack 2y ago

[flagged]

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.

svieira 2y ago
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/ https://privacysandbox.com/news/privacy-sandbox-update/

programjames 2y ago

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.

clan 2y ago
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.
- xp84 2y ago
  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.
Y-bar 2y ago
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.

unscaled 2y ago

> 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-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

notpushkin 2y ago
> 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-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
- sampullman 2y ago
  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.
nmadden 2y ago

deleted 2y ago

[deleted]

st3fan 2y ago

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

PedroBatista 2y ago
Please point them out here.
- simonw 2y ago
  The description of SameSite isn't correct. I have some notes on that here: https://simonwillison.net/2021/Aug/3/samesite/#samesite-cookie-attribute https://simonwillison.net/2021/Aug/3/samesite/#samesite-cook...
  - zoidb 2y ago
    > 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 https://samesite.diduthink.com
- thatha7777 2y ago
  * "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

yoz 2y ago

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/ https://paseto.io/

hgkghjnnvnvbdk 2y ago

[flagged]