I played around with porting oauth to chttpd and what could I say... After reading couch_httpd_oauth sources I understand why everyone wanted to get it out (:
OAuth 1.0 as like as OAuth 2.0 can act as auth provider: with special series of requests provider ensures that user credentials are valid and then moves it to the callback url. At the same time it can auth users without third party services. We have last part implemented good: oauth_authentication_handler works right and I as a user happy with it. The part that turns CouchDB into auth provider is implemented by a half: we have the API, but it uses stubs. So technically we have incomplete implementation of OAuth 1.0 And that's a good reason to drop it completely. Especially since OAuth 1.0 is deprecated and contains security issues. However, our users still may use what we have in production. Our OAuth support is not just yet another. It's also special fields in user documents where personal token/secrets are defied. It's also special group of config options. It's also special auth.oauth object for replication task. In other words, there are quite much things we can break even with current state of things. So I propose to limit our OAuth support to reasonable minimum that 100% works (auth provider, user docs, replication tasks). Deprecate all of this with 2.0 and eventually remove this in-between 2.0-3.0 period when we'll have a time to provide better alternative solution and spread the work enough about to cause smooth migration. Sounds good? -- ,,,^..^,,, On Fri, Sep 11, 2015 at 11:55 PM, Robert Newson <[email protected]> wrote: > +1 to remove oauth. > > Keen to see new authn and authz options for couchdb but that's a separate > topic. > > > >> On 11 Sep 2015, at 17:38, Jan Lehnardt <[email protected]> wrote: >> >> Let’s keep things separate. >> >> I propose moving broken oAuth support from 2.0. I’m prepared to do the >> legwork, it shouldn’t take long. >> >> If someone steps in and fixes oAuth for 2.0 VERY SOON, I’d be okay with >> keeping it. >> >> At this point, we are not discussing additional features for 2.0. >> >> If we get JWT, it goes into 2.1. >> >> Best >> Jan >> -- >> >> >> >>> On 11 Sep 2015, at 16:50, Klaus Trainer <[email protected]> wrote: >>> >>> Hi everybody! >>> >>>> On 09/10/2015 08:20 PM, Alexander Shorin wrote: >>>> Seems like there are no much options. >>>> >>>> I disagree that it's very poor. The only flaws it has is the lack of >>>> RSA support (our implementation) and open security issues (as auth >>>> protocol). But is there any good alternative? >>> >>> A good alternative would be to support JSON Web Token (JWT) [1]. >>> Somebody has already done some work for CouchDB 1.6. in this regard [2]. >>> They managed to outsource authentication to Auth0, while validating JWTs >>> issued by Auth0, and creating respective CouchDB sessions with username >>> and roles assigned from the JWT [3, 4]. >>> >>> In addition to what's been done in [2], I'd like CouchDB to be able to >>> issue JWTs as well, which then could also be used by other applications >>> for authentication and authorization. >>> >>> In contrast to OAuth 1.0a (which is implemented in CouchDB), JWT is >>> conceptionally much simpler. It is easy to set up on servers, and easy >>> to use for clients (e.g. in the browsers). >>> >>> Regarding implementing JWT in CouchDB: I'd like to volunteer and can >>> allocate time for that. >>> >>> What do you think about supporting JWT? >>> >>> >>> [1] https://tools.ietf.org/html/rfc7519 >>> [2] https://github.com/softapalvelin/couch_jwt_auth >>> [3] https://github.com/softapalvelin/getting-started-todo >>> [4] https://auth0.com/ >> >> -- >> Professional Support for Apache CouchDB: >> http://www.neighbourhood.ie/couchdb-support/ >>
