Also, a few that aren't listed: Rails: https://github.com/pelle/oauth-plugin Django: http://code.larlet.fr/django-oauth-plus/wiki/Home NodeJS: https://github.com/nightworld/node-oauth2-server (me) CakePHP: https://github.com/thomseddon/cakephp-oauth-server (me again)
Vanilla is a Sinatra app, exposes a simple API and user database, and the UI is rendered entirely through webhooks. In other words, it's designed to be a headless system that works in concert with a real app, so that the app itself does not need to implement OAuth or indeed the core account handling.
(Some parts, like the ability to sign up by verifying your phone through an SMS code, are very specific to our workflow, but it's intended to be completely generic, so those things can be changed.)
That said, OAuth 2.0 is very simple to implement. It's pretty much entirely encapsulated in oauth.rb, token.rb and authorization.rb, if you want some inspiration.
However I should say that our framework takes a different philosophy. We believe that web apps shouldn't have to ask for OAuth access at all just to personalize the experience for you. They can ask the provider to display to you your name and everything else, in iframes that they can't get visibility into. Although I dislike patents, the whole system was non obvious enough to file one for the investors: http://www.faqs.org/patents/app/20120110469#b
We use oauth mainly for single sign-on, and the access permissions are actually a special case of an app requesting access to various streams you publish. In our framework, the app simply has a user id just like any other user, and can request access to your stream just like any other user. You can put users into friends, family, admins or any other roles, and then give them permissions on various streams.
currently the only good way to use google's v3 api's, which are oauth 2.0, is to use their new experimental identity library. you can however not deploy that in the play store afair. that said, i'd be surprised if this thing just worked in chrome extensions. but if it does it's useful i guess
https://github.com/doxout/node-oauth-flow
The idea is to point the user to your oauth-flow route and they will complete the oauth flow. your middleware will then be called with req.oauth containing all received oauth credentials and the url containing all the original parameters.
How does yours compare to those?
Maybe you just want users to add their dropbox or box account to an existing account. Maybe you need to make a one-time call to a service in their name.
Passport and everyauth simply assume too much: that you will need an authentication strategy, that the strategy will have a getter function for the user, that you actually have users...
oauth-flow just implements the authorization flow: redirects the user to the oauth provider (facebook, twitter, etc), then when the user returns, they return at the same URL and the next middleware is called with req.oauth containing all oauth data such as tokens.
Then you can do whatever you want with those - make an API call, authorize the user using their external ID, register a new user...
Its a smaller, more focused module, better aligned with the principle of doing one thing only and doing it well. And it doesn't require adding any global middleware inside the app.configure block such as in passport.
We stand on the shoulders of giants, the least we can do is help lift others to that level.
If you were to build a business by implementing other people's cloud based product, be it an OAuth provider, MapBox, Embedly, Mailgun, AWS, etc... the barrier to profitability has been raised significantly. The raw costs remain low, but the costs for even a low number of users is quite high.
Maybe this is just the natural order though. It's never really been possible for the author of a lib to be able to charge, let alone charge on a recurring basis, before.
While building https://foauth.org/, I had wondered if it'd be possible to do something like this, but it wasn't really my use case so I didn't really pursue it. I was more interested in people just trying to get access to their own data, so I built a solution for that side of things.
Still, I can speak from experience that wrangling 50+ OAuth providers into a single system is hard enough, and trying to provide a unified API to all of them is even harder. I'm not sure how many sites need to support that many sites, but for people like us trying to simplify the API for others, it becomes a pretty big necessity. As it is, https://github.com/gulopine/foauth.org/tree/master/services is something of a living tribute to the differences between the various service providers.
So yeah, I'll be very interested to see where OAuth.io goes, and for anybody else here who just wants to get their own data (but not run your own service), you might also want to checkout https://foauth.org/.
lost me.
I am now at step 125. Still watching...
But yeah, the changing provider names might not be a good idea. Or at least decrease the interval.
Basically, Checkpoint is a facade that abstracts authentication into a simple API. You set up Checkpoint with your OAuth keys (for, say, Facebook), then just redirect your app to /login/facebook. Checkpoint will do the OAuth interaction and return to your app with a key that can be used to access the login session.
Checkpoint abstracts the notion of logins into identities and accounts. An identity corresponds to a user, and can have more than one account associated with it. Identities are logically partitioned by "realm", so it's ready for federated installations.
We also support email & password (using the same OAuth API) and Mozilla Persona, as well as take care of headaches like password reset, email validation, and account de-duplication (for example, if a user signs in using Facebook on day one and then email on day two).
Best of luck to oauth.io however -- the simple js approach is interesting.
On the other hand, I first thought this was a Facebook thing since it started with "Setup your Facebook API Keys in OAuth.io". Perhaps something like "Setup API keys for the provider of your choice in OAuth.io"?
Edit: It looks like you changed the intervals. Much better now.
Is this for login alone or do you return API keys (and are the keys for the provider service or for OAuth.io)?
