OAuth 2.0 implementation

Discussion in 'Python' started by Demian Brecht, Mar 27, 2012.

  1. 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)
    -------------------------------------------------------------------------------
    Language files blank comment code
    -------------------------------------------------------------------------------
    Python 14 239 196 474
    -------------------------------------------------------------------------------
    SUM: 14 239 196 474
    -------------------------------------------------------------------------------
     
    Demian Brecht, Mar 27, 2012
    #1
    1. Advertising

  2. Demian Brecht

    Roy Smith Guest

    In article <>,
    Ben Finney <> wrote:

    > Demian Brecht <> writes:
    >
    > > I'm getting close to an alpha release of an OAuth 2.0 implementation
    > > (https://github.com/demianbrecht/py-sanction).

    >
    > 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, Mar 27, 2012
    #2
    1. Advertising

  3. Demian Brecht

    Roy Smith Guest

    In article <>,
    Ben Finney <> wrote:

    > Roy Smith <> writes:
    >
    > > In article <>,
    > > Ben Finney <> wrote:
    > > > 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.

    >
    > 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.
     
    Roy Smith, Mar 27, 2012
    #3
  4. On Tue, Mar 27, 2012 at 12:24 AM, Ben Finney <> wrote:
    > Roy Smith <> writes:
    >
    >> In article <>,
    >>  Ben Finney <> wrote:
    >> > 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.

    >
    > 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
     
    Jack Diederich, Mar 27, 2012
    #4
  5. On Monday, 26 March 2012 21:24:35 UTC-7, Ben Finney wrote:
    > Roy Smith <> writes:
    >
    > > In article <>,
    > > Ben Finney <> wrote:
    > > > 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.

    >
    > 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
     
    Demian Brecht, Mar 27, 2012
    #5
  6. On Tue, Mar 27, 2012 at 10:11 AM, Ben Finney <> wrote:
    > Demian Brecht <> writes:
    >
    >> I'm getting close to an alpha release of an OAuth 2.0 implementation
    >> (https://github.com/demianbrecht/py-sanction).

    >
    > 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').

    --
    Stuart Bishop <>
    http://www.stuartbishop.net/
     
    Stuart Bishop, Mar 27, 2012
    #6
  7. 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:

    > On Tue, Mar 27, 2012 at 10:11 AM, Ben Finney <> wrote:
    >> Demian Brecht <> writes:
    >>
    >>> I'm getting close to an alpha release of an OAuth 2.0 implementation
    >>> (https://github.com/demianbrecht/py-sanction).

    >>
    >> 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').
    >
    > --
    > Stuart Bishop <>
    > http://www.stuartbishop.net/
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    Roland

    -----------------------------------------------------------
    With anchovies there is no common ground
    -- Nero Wolfe
     
    Roland Hedberg, Mar 27, 2012
    #7
  8. Demian Brecht

    Roy Smith Guest

    In article
    <7909491.0.1332826232743.JavaMail.geo-discussion-forums@pbim5>,
    Demian Brecht <> wrote:

    > 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).
     
    Roy Smith, Mar 27, 2012
    #8
  9. On Tuesday, 27 March 2012 07:18:26 UTC-7, Roy Smith wrote:
    > In article
    > <7909491.0.1332826232743.JavaMail.geo-discussion-forums@pbim5>,
    > Demian Brecht <> wrote:
    >
    > > 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).


    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.
     
    Demian Brecht, Mar 27, 2012
    #9
  10. Demian Brecht

    Mark Hammond Guest

    On 28/03/2012 1:18 AM, Roy Smith wrote:
    > In article
    > <7909491.0.1332826232743.JavaMail.geo-discussion-forums@pbim5>,
    > Demian Brecht <> wrote:
    >
    >> 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).


    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
     
    Mark Hammond, Mar 28, 2012
    #10
  11. Demian Brecht, Jul 5, 2012
    #11
  12. Demian Brecht

    Alec Taylor Guest

    Alec Taylor, Jul 5, 2012
    #12
  13. On Thursday, 5 July 2012 08:19:41 UTC-7, Alec Taylor wrote:
    > On Fri, Jul 6, 2012 at 12:06 AM, Demian Brecht <> wrote:
    > > 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


    No worries, thanks for the interest :)
     
    Demian Brecht, Jul 5, 2012
    #13
  14. On Thursday, 5 July 2012 08:19:41 UTC-7, Alec Taylor wrote:
    > On Fri, Jul 6, 2012 at 12:06 AM, Demian Brecht <> wrote:
    > > 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


    No worries, thanks for the interest :)
     
    Demian Brecht, Jul 5, 2012
    #14
  15. 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, Jul 6, 2012
    #15
  16. 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, Jul 6, 2012
    #16
  17. Demian Brecht

    Alec Taylor Guest

    On Sat, Jul 7, 2012 at 1:38 AM, Demian Brecht <> wrote:
    > 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" :p

    Thanks for merging my last pull-request,

    Alec Taylor
     
    Alec Taylor, Jul 6, 2012
    #17
  18. 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:]
    Sent: Friday, July 06, 2012 11:42 AM
    To: Demian Brecht
    Cc: ;
    Subject: Re: OAuth 2.0 implementation

    On Sat, Jul 7, 2012 at 1:38 AM, Demian Brecht <>
    wrote:
    > 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" :p

    Thanks for merging my last pull-request,

    Alec Taylor
     
    Demian Brecht, Jul 6, 2012
    #18
  19. Demian Brecht

    Alec Taylor Guest

    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

    On Sat, Jul 7, 2012 at 4:49 AM, Demian Brecht <> wrote:
    > 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:]
    > Sent: Friday, July 06, 2012 11:42 AM
    > To: Demian Brecht
    > Cc: ;
    > Subject: Re: OAuth 2.0 implementation
    >
    > On Sat, Jul 7, 2012 at 1:38 AM, Demian Brecht <>
    > wrote:
    >> 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" :p
    >
    > Thanks for merging my last pull-request,
    >
    > Alec Taylor
    >
     
    Alec Taylor, Jul 6, 2012
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Tsang
    Replies:
    32
    Views:
    1,143
    Richard Bos
    Mar 1, 2010
  2. Samuel Sternhagen
    Replies:
    3
    Views:
    207
    Jonas B.
    Jan 18, 2011
  3. Jeff Greelish

    Twitter script since oAuth

    Jeff Greelish, Sep 17, 2010, in forum: Ruby
    Replies:
    1
    Views:
    317
  4. Iain Barnett

    Oauth

    Iain Barnett, Jan 20, 2011, in forum: Ruby
    Replies:
    1
    Views:
    127
    Iain Barnett
    Jan 20, 2011
  5. Torsten Mueller

    OAuth

    Torsten Mueller, Aug 28, 2012, in forum: C++
    Replies:
    8
    Views:
    520
Loading...

Share This Page