For OAuth <http://en.wikipedia.org/wiki/OAuth>, you need to implement token based auth in API, as well as a provider service because there is no open OAuth provider service for third party API out there :-(
The provider service has to implement application registration, user auth, token validation and distribution (for oauth 1a, access token need to be pushed to or shared with API). In my view, OAuth really belongs to an enterprise system, rather than a specific api or one application. It requires a existing robust web-based auth system on the provider's site. This will also make the API less "independent" because it is depending on the provider service and provider's auth system. With that said, the API could have a plugin that support "token-based" authorization, with an out-of-band token distribution/validation and management service, whatever it would be. Only if there is a strong 3-legged auth use case, should one push to this controversy route. Xu Wang On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull <step...@xemacs.org>wrote: > Abhilash Raj writes: > > > Hi all, > > I wrote a brief summary[1] of this thread. > > You've misinterpreted or mistyped a couple things I wrote: > > I'm not against OAuth in general, just against Mailman being an OAuth > *provider*, or bundling one, because we can't support it properly. > Users should get auth stuff from somebody whose primary interest is > security stuff. > > When I write authentication and authorization should be avoided, I > don't mean Mailman doesn't authenticate and authorize users. I mean > the implementation should be delegated to robust, well-tested modules > or external applications (eg, Apache) whereever possible. > > The last quote needs to be fleshed out. "This practice" refers to not > exposing keys and other secrets to the whole application, including > cooperating processes. If authentication can be done in one place and > an internal session or one-time authorization be granted, that's what > should be done, rather than exposing user credentials to other parts > of the application to do their own authentication and authorization. > > In making such a summary, I think it would be better to organize by > topic. Eg, a partial outline: > > REST API for extended user profiles > Authorization > Trusting local connections > HTTP Basic > OAuth > - Recommended for "outside world" [Florian] > - Advocates including an OAuth provider as a non-default, > experts-only option [Florian] > - Opposes bundling an OAuth provider [Stephen] > - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for > now? [Stephen] > - Don't need an OAuth provider to share authorizations (in fact, > at least in OAuth 2.0, providers don't provide sharing at all) > [Stephen] > - Implementing OAuth provider doesn't provide the benefits of > OAuth (ie, add an OAuth provider means users have yet another > set of credentials to manage) [Stephen] > - OAuth architecture = provider + client + consumer [Richard] > - Agrees to Mailman as OAuth consumer, not provider [Richard] > - OAuth may be overengineering, at first [Barry] > Database schemas > Database implementations > Wire Protocol > etc... > > Also, in that format it's easy to reorganize: > > REST API for extended user profiles > Authorization > Trusting local connections > HTTP Basic > OAuth > - OAuth architecture = provider + client + consumer [Richard] > - Use client in Mailman? > - Recommended for "outside world" [Florian] > - Agrees to Mailman as OAuth consumer, not provider [Richard] > - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for > now? [Stephen] > - OAuth may be overengineering, at first [Barry] > - Use provider in Mailman? > - Advocates including an OAuth provider as a non-default, > experts-only option [Florian] > - Opposes bundling an OAuth provider [Stephen, Richard] > - Implementing OAuth provider doesn't provide the benefits of > OAuth (ie, add an OAuth provider means users have yet another > set of credentials to manage) [Stephen] > - Don't need an OAuth provider to share authorizations (in fact, > at least in OAuth 2.0, providers don't provide sharing at all) > [Stephen] > Database schemas > Database implementations > Wire Protocol > etc... > > By the way, don't go out of your way to reorganize what you've already > done, except as it's useful to you. Gradually improve it as it helps > you to recall discussion. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/xuwang%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9