
OAuth for Python made easy - llambda
https://github.com/litl/rauth#rauth
======
idan
I wish the author had contributed to existing efforts
(<https://github.com/idan/oauthlib>) instead of rolling yet another OAuth
implementation. We set out to build a robust, comprehensive, spec-complete
OAuth signing logic library a year ago, and today it delivers what it says on
the tin, thanks to a lot of work and a raft of dedicated contributors. We have
support for all of the OAuth1 spec, and we're working towards OAuth2. The idea
is to have one de-facto reference OAuth implementation for python instead of a
few confusingly different choices, because the differences are really hard to
spot for anybody who hasn't spent some time cuddling up with the RFC.

Doing OAuth signing logic correctly is pretty finicky. Requests is great, and
we provide a shim layer for it, but it's silly to reimplement the underlying
request signing logic for requests, urllib3 or what-have-you. And what happens
when you need a server-side implementation for verifying signatures? It makes
more sense to do the tricky logic in a separate, testable library than tying
it to one representation of an HTTP request.

Having said all this, anybody willing to wade into this mess and write
something is my kind of crazy. Respect.

~~~
llambda
First, I believe rauth existed prior to your library: rauth is over a year old
now. (Or maybe existed at around the same time; regardless as you'll see
below, contributing to your project wouldn't have made sense for us.)

Second, you're trying to solve a different problem than rauth solves: we
needed a library that provided for the practical, de facto implementation of
OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs.
This is exactly what rauth does. It loosely wraps Requests, which means you
get to basically use Requests that also happens to handle real-world OAuth
providers as a consumer. I don't think it's really fair to call this "silly":
it's clearly filled a hole in the ecosystem for some people.

If you want to consume an OAuth provider, rauth tries to give you a simple
interface to do so with. It's almost as easy as using Requests. You might even
say, it's OAuth for Humans. (Sorry, Kenneth. :)

Edit: to be clear, rauth is about pragmatic simplicity, about a clean API
that's pleasant to work with. It's a client for OAuth modeled around the fact
and philosophy of Requests. Vis-à-vis everything else I've seen, this is in
pretty stark contrast to existing libraries.

~~~
idan
Whoops, didn't notice the chronology.

All the same: OAuthLib and its libraries cover the exact use-case you've laid
out, just in a fashion that has some architectural benefits on top of the
usability goals. The simple "OAuth for Humans" thing you're reaching for
exists—it's <https://github.com/requests/requests-oauthlib>. Kenneth and I
hashed this interface out before we started out on OAuthLib, and thus far it's
the only shim library for OAuthLib I know of (though it's pretty simple to
write something equivalent which bridges OAuthLib's domain knowledge and any
given HTTP request implementation). I even rewrote Requests' underlying auth
implementation to make this sort of thing possible. And now you have:

oauth = OAuth1(client_key=key, client_secret=secret) r =
requests.post(url=request_token_url, auth=oauth)

I don't see OAuth1 getting simpler than that, and the underlying signing logic
is there for anybody to use in any context—as a provider, consumer, in a
stubbing library—whatever!

~~~
llambda
> All the same: OAuthLib and its libraries cover the exact use-case you've
> laid out

Nope. They very much do not: your expectation is that your users will roll
their own clients or use Requests' shim, which seems a little rough around the
edges and doesn't provide for the necessary use cases, e.g. OAuth 2.0 and
Ofly. I'm sorry, but this is not providing for the use cases I've laid out by
any stretch of the imagination.

Rauth is batteries included, ready to get you up and running in minutes, not
hours or days. You won't need to write your own client or patch an existing
client to make it work with an unsupported protocol like OAuth 2.0.

> I don't see OAuth1 getting simpler than that

Then you haven't used rauth. The whole auth dance is taken into consideration
and various helpers make it a breeze, literally a two or three step process.
Further, once you have tokens, it becomes as simple as:

    
    
        session.get('me')
    

Now, that's what I call simple.

I think in your attempts to compare your lib to rauth you're missing the
broader thrust of rauth: rauth is a client library. It makes using OAuth
(1.0/a, 2.0, even the OAuth-ish Ofly) as easy as we can make it. This is far
removed from the goal of some generalized, spec-centric, even idealized,
implementation of OAuth as a spec. Rauth isn't trying to do that, it's trying
to make it easier for you to connect to Facebook or Twitter or whatever
provider you happen to need. I wouldn't really know, but I've been told, it
seems to shine in this regard. :)

~~~
idan
Fair enough. I indeed _haven't_ used rauth, just read the docs. And indeed,
OAuthLib's requests shim is a bit rough in terms of tests and docs, but the
OAuth1 use-case is quite solid—it doesn't do the dance for you, but every
subsequent request is the bulk of the work (in my experience). For that
application, the API's seem pretty similar to me—you can instantiate a
requests session with a set OAuth auth object and make requests like
"session.get(some_uri)" without the magical per-service mapping.

I guess I just feel like tying to one specific service is too specialized.
Libraries like requests should be providing you with enough primitives to be
flexible and enough abstraction to be "simple," though we clearly disagree on
what constitutes the appropriate balance.

------
peter_l_downs
Just in case anyone is confused, this is a library for _client-side_ OAuth.
That said, it's great for quick test scripts — it made my life a lot easier
when I was working on a provider implementation.

EDIT: Although their README only shows an OAuth1 example, check out
[https://github.com/litl/rauth/blob/master/examples/github-
cl...](https://github.com/litl/rauth/blob/master/examples/github-cli.py) for
an example of using it with an OAuth2 provider.

~~~
IheartApplesDix
So I guess that's the open part.

------
jrussbowman
If you're looking for a more full stack framework in python, tornado has had
support for oauth since it's release. It's implementation does rely on the
tornado ioloop though, so it's not something you can easily just pull and use
elsewhere.

~~~
dtwwtd
It's really easy to use too. I recently extended the base implementation for a
service that it didn't support and it took me very little time.

~~~
jrussbowman
I put some time into it a couple years ago before my 2nd kid was born. I've
always wanted to go back and work on making it a bit easier to use. One of the
things I'd love to do is get rid of it being so tied to request handlers so
you can use it more seamlessly in apps.

~~~
dtwwtd
Yeah it would be great to be able to make API requests using the helper
methods from outside of a request handler. As it is, it isn't that difficult
to do it otherwise but it's just more code duplication.

------
zalew
to be honest I am currently lost on the state of oauth in python, has sth
changed since this post [http://pydanny.com/the-sorry-state-of-python-oauth-
providers...](http://pydanny.com/the-sorry-state-of-python-oauth-
providers.html)? as OP is a client lib, could somebody with practical
experience tell me what's the current best library for setting up an oauth
provider? bonus question: should I bother with 2.0 or stick to 1.0 (3rd party
apps and mobile) [http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-
hell...](http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/) ?

~~~
peter_l_downs
Not much has changed. I'm currently working to open source an implementation I
worked on that's compliant with the finalized version of the spec. The most
up-to-date implementation I've seen in the open is
<https://github.com/hiidef/oauth2app>, which implements draft 16.

~~~
zalew
thanks, looks sane.

------
denzil_correa
Thank You, Thank you! After the state of python-oauth2 this comes as the best
oauth library to be used in Python. I however I have one query - how would you
handle Oauth three-legged requests? [0] This is important for people who do
not necessarily build web apps but collect data from Twitter using Oauth (for
a higher API limit).

[0] <https://dev.twitter.com/docs/auth/3-legged-authorization>

------
NelsonMinar
Does it work? I tried to do some OAuth in Python a couple of years back and it
was a total disaster; four competing libraries, none of which worked. But that
was a long time ago and I don't think this Rauth library even existed when I
last looked.

~~~
trtg
Yes it definitely works and does so more easily than any alternative I've
tried. I've used it to interface quickly to something like 20 different APIs
at this point.

------
manojlds
Recently I tried doing cas integration for my django website. A colleague
pointed to a Rails gem - install a gem, point to the cas url and, poof, done.

For django, I struggled, and struggled. Found a couple of libraries and a
number of forks of these spread across github and bitbucket. Got one, but it
didn't work. Debugged the code, fixed some stuff in my own fork, and got it
working 5 hours later.

The world of python seems to have lots of half-baked libraries that are dead
or dying. Makes you miss Ruby / Rails.

~~~
dbgrandi
I couldn't agree with this more. In Rails, I'm used to using omniauth, and
plugging in any number of provider gems that deal with the subtle differences
between how Dropbox and LinkedIn and whatever implement OAuth...and having
them all hook into whatever Rack based framework I use (Rails, Sinatra, etc)

Rauth is a good start, but without a library that couples it to a full web
stack, I'm spending a lot of time hooking it into my flask app and trying to
make sure I don't make mistakes managing my session variables, etc.

Perhaps I'll start up a rauth-providers repo to catalog this stuff.

------
nostromo
If you'll allow me a shameless plug...

My company (dailycred) wraps ten OAuth 1 & 2 providers, as well as email &
password and Mozilla Persona in a single OAuth 2 call.

(We started this project because even just within OAuth 2, providers break
spec left and right and OAuth can be a huge headache, so we manage all of
those headaches for our customers.)

~~~
johns
If you're wondering what some of the discrepancies are, I wrote up a bunch
here: [http://john-sheehan.com/post/41653656681/the-good-and-the-
ba...](http://john-sheehan.com/post/41653656681/the-good-and-the-bad-of-
oauth-2-0-authorization)

------
toyg
Does rauth work with Python 3?

~~~
llambda
Not yet.

~~~
cadillac
Basically the main reason for python-social-auth
(<https://github.com/omab/python-social-auth>) to use oauthlib/requests-
oauthlib instead of rauth.

~~~
llambda
We have plans to implement Python 3 support. It's not the highest priority but
we want it to happen. I'll probably slate it for v0.6.0. By the way, community
participation is more than welcome...there was a pull request that provided
support for 3 but unfortunately it wasn't updated to bring it inline with the
breaking changes 0.5.0 had to introduce. So, if you have any inclination to
hack on a patch that provided Python 3 support I'd be very grateful and could
probably even work alongside its development.

