I was one of the last people to leverage the CouchDB OAuth provider in a commercial setting. That project ended nearly 4 years ago now.
What we have today is "2-legged" OAuth 1.0 compatibility that grew out of functionality Ubuntu was looking for with the now-dead UbuntuOne desktop functionality. It was a hack, a quick hack, and ill-informed at that. What most people wanted, back then, was "3-legged OAuth 1.0." And we never coded that. What people want today is full OAuth 2.0 or OpenID style functionality, both as a consumer (log into Couch with your Twitter credentials) and as a provider (log into a website using your Couch credentials). This code serves neither purpose, and it's a long way from being there. Drop the code from the repo. -joan ----- Original Message ----- > From: "Alexander Shorin" <[email protected]> > To: [email protected] > Sent: Thursday, September 17, 2015 5:03:14 PM > Subject: Re: [PROPOSAL] Remove oAuth for 2.0 > > 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/ > >> >
