Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: OAuth.io released with 70+ providers

oauth.io

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Show HN: OAuth.io released with 70+ providers

#11

Post by btilly »

tehwebguy wrote: post #10
btilly wrote: post #7

Earlier quoted context omitted.

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 b…

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.

Thanks for the correction.

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

Re: Show HN: OAuth.io released with 70+ providers

#12

Post by nadiac »

btilly wrote: post #11
tehwebguy wrote: post #10

Earlier quoted context omitted.

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.

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

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.

Re: Show HN: OAuth.io released with 70+ providers

#13

Post by sondh »

I think this is a step backward. The OAuth specs were designed to make it easier to work with different services and now we have to utilize yet another service to communicate with those services?! Via a priority protocol even!

As a developer, I understand the pain when you have to deal with more than a handful of providers but this approach is a no-go IMHO. Would be a better idea to use something like HybridAuth and handle everything from your servers.

Relevant xkcd: http://xkcd.com/927/

Apology to OP if this comment appears to be offensive.

Re: Show HN: OAuth.io released with 70+ providers

#14

Post by sondh »

nadiac wrote: post #12
btilly wrote: post #11

Earlier quoted context omitted.

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

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.

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

Re: Show HN: OAuth.io released with 70+ providers

#15

Post by nadiac »

sondh wrote: post #13

I think this is a step backward. The OAuth specs were designed to make it easier to work with different services and now we have to utilize yet another service to communicate with those services?! Via a priority protocol even! As a developer, I understand the pain when you have to deal with more than a handful of providers but this approach is a no-go IMHO. Would be a better idea to use something like HybridAuth and…

Oauth has been made to avoid to store passwords, but it is not a simple protocol to implement. I just think you are talking here about the main debate between protocol versus applications/platforms.

- Protocols provide standardization, and independance, often as recipe/instructions to follow. Protocols keeps things open, into nodes not hubs.

- Applications/platforms provide easy comsumption, with a user design but also dependancies. It is like a menu to order, as you choose what you want to eat but you don't have to care about how to do it (the recipe). They mutualize things as code librairies, CPU etc... but are hubs, not node and close the network in counterparty of user experience.

To see in depth the difference of design between a recipe and and a menu, more explanations in the Donald Norman book " The Design of Everyday Things"

Edit: To see the difference between a protocol and an application, why people are using Gmail instead of STMP? User experience vs implementation

Re: Show HN: OAuth.io released with 70+ providers

#16

Post by DiabloD3 »

This is not what I want in an OAuth provider.

Instead, someone should write a simple daemon I can execute http+json REST functions on to create and verify login cookies and transfer them back and forth to the user's browser using my webapp normally.

The daemon can be written in any language as long as it is not a JVM language.

I would write such a thing, but OAuth is somewhat confusing, and OAuth.io brings up a good point, a lot of the existing OAuth implementations are a bit flaky and if I just copy what they do/use them directly I risk inheriting that problem.

Re: Show HN: OAuth.io released with 70+ providers

#19

Post by Aaronneyer »

Anybody watch the little gif in the corner? Just kind of stared at it for a while, it never seems to end.

edit: Oh, the whole thing isn't a GIF. It just has a looping programmer gif and then puts some text around it. Maybe it will go on forever then :p

edit2: https://oauth.io/js/stubborn.js So definitely does go on forever :p

Post reply on HN