[HN Gopher] Demystifying cookies and tokens
       ___________________________________________________________________
        
       Demystifying cookies and tokens
        
       Author : fagnerbrack
       Score  : 79 points
       Date   : 2024-07-22 11:06 UTC (2 days ago)
        
 (HTM) web link (tommihovi.com)
 (TXT) w3m dump (tommihovi.com)
        
       | 4RealFreedom wrote:
       | 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 wrote:
         | 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/
        
       | programjames wrote:
       | 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 wrote:
         | 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.
        
         | Y-bar wrote:
         | 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 wrote:
       | > 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...
        
         | notpushkin wrote:
         | > 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...
        
           | sampullman wrote:
           | 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 wrote:
         | 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.
        
       | st3fan wrote:
       | 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 wrote:
         | Please point them out here.
        
           | simonw wrote:
           | The description of SameSite isn't correct. I have some notes
           | on that here:
           | https://simonwillison.net/2021/Aug/3/samesite/#samesite-
           | cook...
        
       | yoz wrote:
       | 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/
        
       ___________________________________________________________________
       (page generated 2024-07-24 23:13 UTC)