[GitHub] [couchdb] atrauzzi commented on issue #2648: Feature - Add JWT support

[GitBox <gi...@apache.org>]

atrauzzi commented on issue #2648: Feature - Add JWT support
URL: https://github.com/apache/couchdb/pull/2648#issuecomment-597104260
 
 
   Hey @wohali - thanks for the review! Lots of obvious cleanup in there, I wasn't sure whether to leave it as part of the review process, but yes, definitely will get on the specific code changes later today 🙂
   
   I'll speak to the concern over JWTs for the rest of this comment as I think it's important conceptually to address separately. I apologize if this is too long, or if some of my explanations dip into _the basics_, it's necessary to keep oriented while giving these articles a considered look.
   
   ---
   
   ### On JWT
   
   > Finally, I've had a long-standing knee-jerk reaction against JWT because of these two articles. Can you comment on this?
   
   I'm going to give them their due, but overall, I'm not sure why these posts exist. I found them poorly reasoned and by their title alone, not applicable.
   If we ignore the title and take it as generalized advice on JWT (a-la _knee-jerk reaction_), I could foresee untangling it taking up a lot of space in this thread.
   
   > Does your proposed approach address any of the (rather serious) accusations raised by Sven?
   
   Honestly, I don't think the posts generate any actionables. If I could say one thing, it's that the purpose of this PR is not to introduce JWTs for sessions, only for identity. That might be the _tldr;_... 😆
   
   I'll start out picking on a few notable points, but if there's anything specific that you feel applies, let me know.
   
   <details>
     <summary>click to read...</summary>
     
     #### General
   
   I don't see a legitimate complaint proven in the articles so much as a comparison and then a preference being expressed. The author is making it clear that they are only interested in single node monoliths and that they don't understand that JWTs are not intended to store server-side state! 😅
   Nearly all the points in the posts are simply presenting a preference on the basis of _what's good for the goose_.
   
   To discuss the topic implying that JWTs are equivalent to sessions is a false premise. And even despite the _"A note upfront"_ section, the posts fail to act on any fundamental understanding of JWTs. This is indicated by the list preceded by _"I'll define a few terms first"_ which exposes the authors mistaken assumption that JWTs are used for session data.
   
   Another example of suspicious rationale: _"While signed cookies are more secure than unsigned cookies, this is in no way unique to JWT, and good session implementations use signed cookies as well."_
   ...Not exactly a well-reasoned indictment of the security or utility of JWTs.
   
   Let's clarify:
   
    - JWTs are a(n) (optionally expirable, self-signable & encryptable) bearer token capable of storing small bits of information, typically identifiers
    - Cookies are a set of conventions to round-trip state, but are most often used to transport a bearer token that corresponds to yet more state server-side
   - At the transport level, cookies and JWTs are both susceptible to the same security risks. TLS is the common ground that most popular bearer-based systems use
   - Fun fact: Some people even use JWTs as the content of their identity cookie!
   
   While cookies encode data, that data doesn't necessarily have to represent identity. Indeed many sites you visit will create a cookie without you even having taken an action!  In fairness, it is _very_ easy to conflate the concepts involved given the combination of abstractions that many web frameworks offer. 
   
   I think we're seeing a bit of this in the posts, with the point being that before authoring any criticism of JWT, the author should have spent some time getting an idea of their intended use.
   
   It wouldn't be too out-of-hand to stop at this point and dismiss these posts as fear mongering, but I will be fair and give it it a little more analysis.
   
   #### Easier to (horizontally) scale
   
   This is not a primary motivator for adopting JWT. The benefit offered by JWT is a single common and stateless format to provide and validate claims in a heterogenous system.
   
   This argument really doesn't fit with an analysis of why one shouldn't use JWTs.
   
   #### CSRF
   
   Yes, JWTs in authorization headers do prevent CSRF.
   
   It's an oddly seldom known trick that you can cleverly mitigate against CSRF by explicitly requiring a header as part of a request. This header can be as simple as `content-type: application/json`, and `authorization: Bearer *` has the same effect: `<form>`s can't set headers! 🏆
   
   JWTs in headers - as I propose them here - are _more_ secure than cookies. Though I'd also like to remind that this is not the primary reason why I'm looking to introduce them.
   
   #### Expiration, Easier to Use, More Flexible
   
   >This is nonsense, and not a useful feature. Expiration can be implemented server-side just as well, and many implementations do.
   
   This is the kind of assertion that really brings these posts down. Focusing on expiration as a flaw takes the architectural experience or preferences of the author and pushes them as absolutes.
   
   The whole point of JWT is that the token will not be visiting a single, centralized monolith. It will be shopped around to various cooperating services. Also worth noting that people often configure their cookies to live for far too long, vs say... Implementing a remember-me token, which is basically an ad-hoc refresh token built on top of cookies. Something already standardized by [OpenID Connect](https://openid.net/connect/).
   
   The fact that JWTs can be set to self-destruct means that rotations can be forced with zero overhead to servers that will be receiving the token.  Case in point, my PR doesn't require any logic to direct the client on how to obtain new tokens.
   When taken as part of a complete [OpenID Connect implementation](https://github.com/openiddict/openiddict-core), you can get some very cool SDKs like [this JavaScript one ](https://github.com/IdentityModel/oidc-client-js) which will auto-rotate your tokens for you 🌟 and more 🌟!
   
   #### Single Use
   
   This is a strange rule imposed by the author which I reject.  I could use this same argument to say that a bearer token in a cookie should be single use as well. 
   
   This point is easily disregarded as trying to kitchen-sink against JWTs.
   
   ---
   
   The flowchart offered in the follow-up post I feel doesn't really require much attention. Some of the statements within are cynical and are too far into prior misunderstandings to really warrant concern.
   
   Really, it just comes down to the fact that cookies and JWT can be used for overlapping and sometimes different purposes in equally as nuanced situations. I use cookies for browser based authentication in the same application that also uses JWT to validate API requests.  There's nothing unusual about this, it's how many applications perform their oauth2 authentication and consent flows.
   
   Finally, these posts came out in June 2016, coming up to their 4 year anniversary. If the security concerns they detail were in any way legitimate, I'm very confident the greater communities we all participate in would have discarded JWT by now. Instead, I think we can see quite the opposite and that client & server libraries as well as many large scale services have come to embrace JWT.
   
   Again, I'd love to explore any specific concern, so do let me know if there's one in particular I didn't happen to choose to drag out here. 🙂
   </details>

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services