OAuth 2.0 implementation

[Demian Brecht]

Hi all,

I'm getting close to an alpha release of an OAuth 2.0 implementation (https://github.com/demianbrecht/py-sanction). High level features include:

* Support for multiple providers (protocol deviations). This didn't seem to be supported by any library.
* Actually an OAuth 2.0 implementation (python-oauth2 is a 2nd version of python-oauth, not an OAuth 2.0 implementation)
* Support for the entire OAuth 2.0 spec. Most provide support for the authorization code grant flow (employed by all web server providers), but lacked support or extensibility for any other flows, credentials or other provider extensions)
* 100% unit test coverage. Some employ TDD, others didn't.

Current implementation includes support for Authorization Code Grant flow but can be extended to support others (including extensions) quite trivially.

Current adapter implementations include:

* Google
* Facebook
* Stack Exchange
* Deviant Art
* Foursquare

It has yet to be heavily used or functionally tested (basic tests have been done in example/server.py) and documentation is being worked on.

Just wanted to share some of my work and hopefully someone other than me can find some use for it


P.S. For those interested, cloc stats are:

http://cloc.sourceforge.net v 1.53 T=0.5 s (28.0 files/s, 1818.0 lines/s)

 

[Roy Smith]

Thank you for doing this work.

As someone who uses OpenID, what can I read about why OAuth is better?

OpenID is for people who worry about things like how OpenID is different
from OAuth. Oauth is for people who have no idea what OAuth is and just
want to be able to log into web sites using their Facebook account.

 

[Roy Smith]

So, if I want to be free to choose an identity provider I trust, and
it's not Facebook or Google or Twitter or other privacy-hostile
services, how does OAuth help me do that?

It doesn't. Well, in theory, it could, but in practice everybody's
OAuth implementation is different enough that they don't interoperate.

 

[Jack Diederich]

Thanks. So OAuth is a pseudo-standard that is implemented incompatibly
to the extent that it doesn't actually give users the freedom to migrate
their existing data and identity at will to any other OAuth implementor?

Pretty much. It is nice that it is published as a standard at all but
the standard is just whatever people are actually doing. It seems
less hostile when you think of it as vigorous documentation instead of
protocols set in stone.

-Jack

 

[Demian Brecht]

Thanks. So OAuth is a pseudo-standard that is implemented incompatibly
to the extent that it doesn't actually give users the freedom to migrate
their existing data and identity at will to any other OAuth implementor?

--
\ “Money is always to be found when men are to be sent to the |
`\ frontiers to be destroyed: when the object is to preserve them, |
_o__) it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ |
Ben Finney

OAuth 2.0 is the emerging standard (now passed on to IETF) to deal with providing access to protected resources. OpenID is a standard used to deal with authentication. While there is some overlap (OAuth can be used for authentication as well), the goals of the two protocols are different.

OAuth 2.0 is still in draft status (draft 25 is the current one I believe) and yes, unfortunately every single server available at this point have varying degrees of separation from the actual spec. It's not a pseudo-standard, it's just not observed to the letter. Google is the closest and Facebook seems to be the farthest away (Stack Exchange is in close second due to building theirs to work like Facebook's). That was pretty much how this work was born. I wanted to be able to implement authentication and resource access over multiple providers with a single code base.

So, in answer to your questions:

1) If you're only looking for a solution to authentication, OAuth is no better than OpenID. Having said that, with the apparent popularity of OAuth 2.0, more providers may support OAuth than will OpenID (however, that's just my assumption).

2) OAuth is all about centralized services in that it is how providers allow access to protected resources. Whether it's a social network or SaaS (such as Harvest: http://www.getharvest.com/), if there isn't exposure to protected resources, then OAuth becomes pointless.

3) If you're looking to implement OAuth authentication with a provider thatyou trust, grab the sanction source, implement said provider and send a pull request

4) Data migration doesn't happen with OAuth. As the intent is to allow access to protected resources, migrating Google to say, Facebook just wouldn't happen

Hope that makes sense and answers your questions.
- Demian

 

[Stuart Bishop]

Thank you for doing this work.

As someone who uses OpenID, what can I read about why OAuth is better?

They are different, and often you need to use both.

OpenID allows web sites to authenticate someone. It is not really
useful for anything not an interactive web site. The consuming site
never gets your keys, it just gets confirmation from the provider that
the user is who they claim they are and maybe some details that the
provider chooses to provide such as an email address.

OAuth is for generating authentication keys that allow a program to
authenticate as someone and perform operations on their behalf. You
use OAuth to generate a key so that Foursquare can send messages via
Twitter on your behalf, or so the Facebook client on your phone can
access your account without storing your password. You also get
authentication here, as you can't generate a key without being
authenticated, but the real reason it is used instead of OpenID is so
you can keep the key and keep using it to act as the user; you can
keep using that key until it expires or it is revoked.

Authentication providers that don't provide a webapi just implement
OpenID. Big sites like Google and Facebook implement both OpenID (for
'log in with your GMail account') and OAuth ('post this message to
your Facebook wall').

 

[Roland Hedberg]

And then to complicate the picture you have OpenID Connect which is an attempt at
bringing OpenID and OAuth2.0 together.

By the way I have an implementation of OpenID Connect here:

https://github.com/rohe/pyoidc

-- Roland

27 mar 2012 kl. 11:59 skrev Stuart Bishop:

They are different, and often you need to use both.

OpenID allows web sites to authenticate someone. It is not really
useful for anything not an interactive web site. The consuming site
never gets your keys, it just gets confirmation from the provider that
the user is who they claim they are and maybe some details that the
provider chooses to provide such as an email address.

OAuth is for generating authentication keys that allow a program to
authenticate as someone and perform operations on their behalf. You
use OAuth to generate a key so that Foursquare can send messages via
Twitter on your behalf, or so the Facebook client on your phone can
access your account without storing your password. You also get
authentication here, as you can't generate a key without being
authenticated, but the real reason it is used instead of OpenID is so
you can keep the key and keep using it to act as the user; you can
keep using that key until it expires or it is revoked.

Authentication providers that don't provide a webapi just implement
OpenID. Big sites like Google and Facebook implement both OpenID (for
'log in with your GMail account') and OAuth ('post this message to
your Facebook wall').

Roland

 

[Roy Smith]

OAuth 2.0 is still in draft status (draft 25 is the current one I believe)
and yes, unfortunately every single server available at this point have
varying degrees of separation from the actual spec. It's not a
pseudo-standard, it's just not observed to the letter. Google is the closest
and Facebook seems to be the farthest away (Stack Exchange is in close second
due to building theirs to work like Facebook's).

In practice, OAuth is all about getting your site to work with Facebook.
That is all most web sites care about today because that's where the
money is. The fact that other sites also use OAuth is of mostly
academic interest at this point.

The next player on the list is Twitter, and they're not even up to using
their own incompatible version of OAuth 2.0. They're still using OAuth
1.0 (although, I understand, they're marching towards 2.0).

 

[Demian Brecht]

In practice, OAuth is all about getting your site to work with Facebook.
That is all most web sites care about today because that's where the
money is. The fact that other sites also use OAuth is of mostly
academic interest at this point.

The next player on the list is Twitter, and they're not even up to using
their own incompatible version of OAuth 2.0. They're still using OAuth
1.0 (although, I understand, they're marching towards 2.0).

Sure, with the initial surge of the Facebook platform, I'm sure there are many more applications that only work with Facebook. However, after the initial gold rush, I'm sure there will be more developers who see the potentialpower of service aggregation (and not just for feeds ). I know I'm one of them.

Of course, a lot of these thoughts are around niche markets, but isn't thatwhere the money is? Untapped, niche markets? That's a completely differentdiscussion though and would obviously be quite the thread derailment.

 

[Mark Hammond]

In practice, OAuth is all about getting your site to work with Facebook.
That is all most web sites care about today because that's where the
money is. The fact that other sites also use OAuth is of mostly
academic interest at this point.

The next player on the list is Twitter, and they're not even up to using
their own incompatible version of OAuth 2.0. They're still using OAuth
1.0 (although, I understand, they're marching towards 2.0).

Almost all "social" or "sharing" sites implement OAuth - either 1.0 or
2.0. Facebook is clearly the big winner here but not the only player.
It's also used extensively by google (eg, even their SMTP server
supports using OAuth credentials to send email)

I'd go even further - most sites which expose an API use OAuth for
credentials with that API.

Mark

 

[Demian Brecht]

FWIW, this package has undergone a major overhaul (474 LOC down to much happier 66) and is available at https://github.com/demianbrecht/sanction. Also available from PyPI.

 

[Alec Taylor]

FWIW, this package has undergone a major overhaul (474 LOC down to much happier 66) and is available at https://github.com/demianbrecht/sanction. Also available from PyPI.

Thanks for this, I've now shared it on my favourite web-framework
(which unfortunately recommends Janrain) as an alternative:
https://groups.google.com/forum/#!topic/web2py/XjUEewfP5Xg

 

[Demian Brecht]

Thanks for this, I've now shared it on my favourite web-framework
(which unfortunately recommends Janrain) as an alternative:
https://groups.google.com/forum/#!topic/web2py/XjUEewfP5Xg

No worries, thanks for the interest

 

[Demian Brecht]

Thanks for this, I've now shared it on my favourite web-framework
(which unfortunately recommends Janrain) as an alternative:
https://groups.google.com/forum/#!topic/web2py/XjUEewfP5Xg

No worries, thanks for the interest

 

[Demian Brecht]

Supported provider list (with example code) is now:
* Facebook
* Google
* Foursquare
* bitly
* GitHub
* StackExchange
* Instagram

Other providers may also be supported out of the box, but have been untested thus far.

 

[Demian Brecht]

Supported provider list (with example code) is now:
* Facebook
* Google
* Foursquare
* bitly
* GitHub
* StackExchange
* Instagram

Other providers may also be supported out of the box, but have been untested thus far.

 

[Alec Taylor]

Supported provider list (with example code) is now:
* Facebook
* Google
* Foursquare
* bitly
* GitHub
* StackExchange
* Instagram

Other providers may also be supported out of the box, but have been untested thus far.

Looking good. Keep adding more to the list!

I'd especially be interesting in seeing the 3-phase Twitter and
LinkedIn auths added to the list.

Also I'll be extending it a little more at some point to make it "friendlier"

Thanks for merging my last pull-request,

Alec Taylor

 

[Demian Brecht]

No worries, thanks for the request.

Unfortunately AFAIK (according to the OAuth provider list on Wikipedia),
both Twitter and LinkedIn still use OAuth 1.0a, so until they hop on the
OAuth 2.0 bandwagon, they won't be added.

-----Original Message-----
From: Alec Taylor [mailto:[email protected]]
Sent: Friday, July 06, 2012 11:42 AM
To: Demian Brecht
Cc: (e-mail address removed); (e-mail address removed)
Subject: Re: OAuth 2.0 implementation

Supported provider list (with example code) is now:
* Facebook
* Google
* Foursquare
* bitly
* GitHub
* StackExchange
* Instagram

Other providers may also be supported out of the box, but have been

untested thus far.

Looking good. Keep adding more to the list!

I'd especially be interesting in seeing the 3-phase Twitter and LinkedIn
auths added to the list.

Also I'll be extending it a little more at some point to make it
"friendlier"

Thanks for merging my last pull-request,

Alec Taylor

 

[Alec Taylor]

Yeah, seems Twitter is still stuck on 1.0a...

But LinkedIn seems to support 1.0a for REST and 2 for JS:
https://developer.linkedin.com/apis

So that could be a definite contender for Sanction support

No worries, thanks for the request.

Unfortunately AFAIK (according to the OAuth provider list on Wikipedia),
both Twitter and LinkedIn still use OAuth 1.0a, so until they hop on the
OAuth 2.0 bandwagon, they won't be added.

-----Original Message-----
From: Alec Taylor [mailto:[email protected]]
Sent: Friday, July 06, 2012 11:42 AM
To: Demian Brecht
Cc: (e-mail address removed); (e-mail address removed)
Subject: Re: OAuth 2.0 implementation

Supported provider list (with example code) is now:
* Facebook
* Google
* Foursquare
* bitly
* GitHub
* StackExchange
* Instagram

Other providers may also be supported out of the box, but have been

untested thus far.

Looking good. Keep adding more to the list!

I'd especially be interesting in seeing the 3-phase Twitter and LinkedIn
auths added to the list.

Also I'll be extending it a little more at some point to make it
"friendlier"

Thanks for merging my last pull-request,

Alec Taylor