With respect, this is yet another library that should be a small piece of open source software rather than a hosted service which I'll probably eventually have to pay for and which is likely to eventually go defunct, requiring me to rewrite my code to use another library. It's useful, but not big and important enough to be its own service. <i>Grump.</i>
Interesting. It took me a minute to figure out what you're actually doing here, but once I found the important bit on the page ("Setup your API Keys in OAuth.io"), I can at least be confident this isn't a glaring security concern. :) And yes, that was a legitimate concern when I first looked at it, given how little information is currently available.<p>While building <a href="https://foauth.org/" rel="nofollow">https://foauth.org/</a>, 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.<p>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, <a href="https://github.com/gulopine/foauth.org/tree/master/services" rel="nofollow">https://github.com/gulopine/foauth.org/tree/master/services</a> is something of a living tribute to the differences between the various service providers.<p>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 <a href="https://foauth.org/" rel="nofollow">https://foauth.org/</a>.
There's no shortage of simple OAuth consumer libraries out there, what I really want to see is a simple way to set up my app as an OAuth _provider_. As far as I know there's nothing out there to make that simple yet.
The most confusing thing to me about this page was the changing provider names. I was looking at the page and could tell that something was changing but it took me about 15 seconds to figure out what it was.
Shameless plug: We wrote a backend app, Checkpoint, that works similarly to this. It's open source [1] and in use with a number of production apps. Admittedly it does not have the JavaScript stuff, but that's easy enough to add.<p>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.<p>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.<p>[1] <a href="https://github.com/bengler/checkpoint" rel="nofollow">https://github.com/bengler/checkpoint</a>
If you'd like something similar to this that's available today, check out our startup: <a href="https://www.dailycred.com/" rel="nofollow">https://www.dailycred.com/</a><p>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).<p>Best of luck to oauth.io however -- the simple js approach is interesting.
+1 for the animated image or gif or whatever, instantly caught my attention. I would maybe speed it up however, I was curiously awaiting to see the full animation.
I wish this existed before. For node.js stacks that support connect/express based middleware, we wrote oauth-flow instead<p><a href="https://github.com/doxout/node-oauth-flow" rel="nofollow">https://github.com/doxout/node-oauth-flow</a><p>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.
I was getting so impatient waiting for the stubborn programmer animation to finish. Inspect -> sources -> stubborn.js -> ohhhhhh... well done.<p>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"?
Comments on the animated UI aside, as someone who recently pulled their hair out trying to get StackOverflow oauth working, a simple solution would be extremely welcome.
My scalp shall thank you!
The little comic programmer guy is hilarious. And actually, as someone who's fooling around with oauth right now, this looks very appealing.<p>But yeah, the changing provider names might not be a good idea. Or at least decrease the interval.
There is a little too much changing text going on in my opinion. It was difficult to read the sample code because my eyes kept jumping to the changing text all over the screen.<p>Edit: It looks like you changed the intervals. Much better now.