[btilly]

Worse than that. You are at the mercy of what service providers think of both them AND all of their clients.

Suppose that they have a customer who uses their service to install malware in people's accounts, and Google catches them. Google isn't going to just shut off one customer. They are going to revoke the client_id associated with OAuth.io, causing every customer to lose access. (A malware author could try this because they would hope that malicious requests are more easily lost inside the torrent of other stuff coming from OAuth.io.)

And it isn't just a customer who is intentionally bad. If a customer gets compromised by a malware author who uses that as a vector, well, same story.

You do not want your access to business-critical APIs to depend on a third party reseller who cannot guarantee their own continued access. Really.

[tehwebguy]

I received an invite to this service today and just checked it out - this is not correct.

You have to generate your own keys for each service, then store them with OAuth.io. This doesn't mean they can't access your users' data, just that there isn't one "master key" that could shut everyone down.

[btilly]

Thanks for the correction.

In that case, I fail to see the value add that they claim to provide.

[nadiac]

I feel it is made for fast Oauth integration. We use 4 oauth providers into one of our app, and it took us really 4 full days to implement them without bug. We are not Oauth experts but it was really boring and IMO useless implementation time.

Also I'm personaly making a client-side app on a Github page and it seems that with oauth.io I could make a serverless Facebook/Twitter authenticated app.

[sondh]

Facebook and Twitter OAuth implementations both support response_type=token for serverless authorization.