OAuth and API Providers: Come on guys.(gist.io)
gist.io
OAuth and API Providers: Come on guys.
http://gist.io/3170829
28 comments
Thank you for this; I believe it fills a big hole in the ecosystem. I found myself wanting to implement an API endpoint about six months before your first commit to this project, so I hit Github expecting to find a couple of OAuth-provider Ruby libraries in competition; I'd pick one and do a day or two of work to get it integrated.
Instead, I couldn't find much of anything.
So I delegated the task to someone else who I believe ended up implementing… Basic auth over TLS. ;)
Instead, I couldn't find much of anything.
So I delegated the task to someone else who I believe ended up implementing… Basic auth over TLS. ;)
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/
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/
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.
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.
I have found that doorkeeper[0] is pretty good and the setup is a breeze.
[0]: https://github.com/applicake/doorkeeper/
[0]: https://github.com/applicake/doorkeeper/
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/.
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/.
<3 doorkeeper. Using it to make one of our open source apps - http://github.com/isotope11/xrono - an oauth provider to support an oauth sso flow inside of apps we've built for internal use regularly. It took an hour one night to build the provider, and maybe an hour to build the omniauth provider gem and integrate it into an app.
P.S. - it also took like six hours of banging my head against a wall for unrelated oauth-related problems, but not DK's fault.
P.S. - it also took like six hours of banging my head against a wall for unrelated oauth-related problems, but not DK's fault.
I've also open sourced a set of (incomplete) social buttons as well. Do as you would with them, they're MIT-licensed, and while the set is incomplete, the PSD is included.
Enjoy.
https://github.com/bmelton/Social-Login-Buttons
Enjoy.
https://github.com/bmelton/Social-Login-Buttons
Agreed. It'd be great for interoperability to get a set of quality, conformant open source provider implementations in various languages. I've implemented OAuth 1.0 and OAuth 2.0 as middleware in Node.js, available here:
https://github.com/jaredhanson/oauthorize https://github.com/jaredhanson/oauth2orize
https://github.com/jaredhanson/oauthorize https://github.com/jaredhanson/oauth2orize
Yea, I am currently implementing OAuth (https://github.com/ocharles/snaplet-oauth2) and the specification is not entirely straight forward. There's a lot of edge-case type stuff that's important to get right.
Which version? There were 30 mutually incompatible draft versions of OAuth2 last time I checked
Unless I misunderstand, this is talking about OAuth, not OAuth 2. While the latter does have a lot of versions, I believe the former is "finalized."
http://opro-demo.herokuapp.com/oauth_docs/oauth
version 22 of oauth2 spec
version 22 of oauth2 spec
Awesome dude. I've been using oauth-plugin which just makes me shake with violent rage. Definitely gonna check this out.
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.
My hope is that now that the basecamp2 API supports it, their implementation will become the reference standard.
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.
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.
Which version of OAuth 2? It's not standardized, new drafts are issued regularly, many of them backwards-incompatible.
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.
"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.
"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).
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).
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
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
Also: get an SSL certificate.
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?
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
https://github.com/idan/oauthlib
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.
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.
We at filepicker.io (https://www.filepicker.io) are trying to solve this pain point for developers working with user content
I think Tim Bray just got into working on OAuth so that's exciting :)
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.