

OAuth and API Providers: Come on guys. - excid3
http://gist.io/3170829

======
thinkbohemian
Ever actually tried implementing an Oauth provider? It's surprisingly
difficult to get 100% right.

I had a similar problem, so I started my own open OAuth provider
implementation complete with built in documentation
<https://github.com/schneems/opro>. If you're using Rails, you can have a
working OAuth provider in production in under 5 minutes. Of course adding the
API endpoints and writing application specific docs is still up to the user,
but the authentication flow and logic are at least standardized.

~~~
purephase
I find with Devise and Omniauth it works like magic. rbates has some excellent
Railscasts on the process as well.

I agree with the main thrust of the argument though. OAuth providers do not
make it as easy as they should. The point about the buttons is spot on. I've
had some good success with the buttons provided here:

<http://nicolasgallagher.com/lab/css3-social-signin-buttons/>

~~~
thinkbohemian
Omniauth is for implementing an OAuth client, and it's great... but, that's
the other side of this coin.

There are very few good provider libraries out there, making it harder to
stick to standards. People who want to provide an API shouldn't have to re-
invent the wheel every time.

~~~
Judson
I have found that doorkeeper[0] is pretty good and the setup is a breeze.

[0]: <https://github.com/applicake/doorkeeper/>

~~~
thinkbohemian
I like doorkeeper as well. Opro doesn't currently support any other backends
other than ActiveRecord, so if you're using mongo you would need to use
doorkeeper.

I started writing opro before DK was out in the wild. There were some things I
had in opro that weren't in DK so I decided to keep developing it.

Last time I checked here are some differences:

\- Deals with CSRF protected resources automatically

\- Works with your login system (like devise), not around it. No special
casing or configuration is needed

\- Comes with built in docs.

\- Comes with built in test controller

You can play around with it here: <http://opro-demo.herokuapp.com/>.

------
carsongross
Oauth, even oauth2, seems like a classic open, design-by-loose-committee
failure. Too many options and open ended decisions.

My hope is that now that the basecamp2 API supports it, their implementation
will become the reference standard.

~~~
johns
I hope there's some standardization too. You'd think there would be some
coalescing around the most popular OAuth2 implementation: Facebook's. But even
they weren't big enough to get people to settle on one.

------
daredevildave
I'd add, that if you are implementing OAuth 1, you are making life painful for
developers. If you are creating an API now, please use OAuth 2. It's much more
straightforward for both server and client.

~~~
steveh73
Which version of OAuth 2? It's not standardized, new drafts are issued
regularly, many of them backwards-incompatible.

------
simonw
I don't understand what the author means by this paragraph:

"Now when a user signs up websites try to make it as easiest as possible to
increase user sign up and adoption. Then you provide an API that exposes this
information and has data gaps because you wanted to avoid having the user type
in one more field during sign up. The API should drive those requirements not
the other way around."

Is the author saying that sites should focus on making life easy for API
consumers at the expense of their users? If so, I couldn't disagree more.

------
Timothee
_"It is absolutely essential for each user to have UID that doesn't change and
is consistent for the life of the account."_

I agree and that's actually been a problem with Twitter. They _do_ have a
unique ID for each user. The problem resides in the fact that users can change
their Twitter handles. So you can track a user with their UID, but you also
have to check that their handle doesn't change over time and figure out if
their user page on your site is at website.com/223453245/ (not the prettiest
and people can't link the Twitter handle to the user page on your site), or
website.com/handle/ (which is more desirable but creates problems when the
handle changes).

------
nchuhoai
Making Oauth Providers seriously sucks. I kno people will out me for not being
rigorous enough or not low-level enough, but I would really love if we could
all band together and provide some reference, open source provider to build on
top on.

In the Rails world, Doorkeeper is a great example:
<https://github.com/applicake/doorkeeper/>. However, I wish Doorkeeper were
ORM agnostic as i can not use ActiveRecord nor Mongo. I would appreciate any
hidden gems that others might have

------
killerswan
Also: get an SSL certificate.

------
AriX
This article is very vague and confusing. I'm sure there are real problems
here, but the grammar makes this hard to read. What are you complaining about,
specifically, in the "Logos" section? What would you like a company like
Twitter to be providing in terms of graphics?

------
idan
We're working on a generic, spec-compliant, thorough implementation of the
OAuth spec(s) for python. Quite a bit is working, and it has a very reasonable
API. Help wanted!

<https://github.com/idan/oauthlib>

------
sunir
My advice, somewhat harsh, but I believe true. If you build an OAuth endpoint,
build an OAuth 1.0A endpoint. It's stable, powerful, and effective. There is
no effective OAuth 2 "standard" yet.

------
homakov
Hey there. If you have any good thoughts on improving oauth2 you should ping
me:) I am posting a new spec in a week and since you know a lot of providers
now we could work together.

------
tagx
We at filepicker.io (<https://www.filepicker.io>) are trying to solve this
pain point for developers working with user content

------
knewter
I think Tim Bray just got into working on OAuth so that's exciting :)

