couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [PROPOSAL] Remove oAuth for 2.0
Date Thu, 17 Sep 2015 22:03:12 GMT
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" <kxepal@gmail.com>
> To: dev@couchdb.apache.org
> 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 <rnewson@apache.org>
> 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 <jan@apache.org> 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 <klaus_trainer@posteo.de>
> >>> 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/
> >>
> 

Mime
View raw message