9 ms·

OAuth.io - OAuth that just works.

149 points by thyb 13y ago

spicyj 13y ago
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.
- enjo 13y ago
  Hah.. I actually read this comment first and I was STILL just staring at my screen completely dumfounded. I'd see the little animation on the right update, and then something else would change. It was mystifying.
  - jsmeaton 13y ago
    Made it really hard for me to focus on the content. I know exactly what was changing, and it wasn't that much, but it took a really long time (in comparison) to read the examples.
    - thyb 13y ago
      Alright, listening to your feedback it seems the animation was too much of a distraction, so we removed it. Thank you for your feedback!
spion 13y ago
I wish this existed before. For node.js stacks that support connect/express based middleware, we wrote oauth-flow instead https://github.com/doxout/node-oauth-flow 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.
- tlrobinson 13y ago
  There's also http://everyauth.com/ http://everyauth.com/ and http://passportjs.org/ http://passportjs.org/ for node.js How does yours compare to those?
  - spion 13y ago
    In short - it doesn't assume that you want to use oauth for user authentication and authorization. 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.
- jlogsdon 13y ago
  Ruby has OmniAuth[1] which is Rack-based middleware. [1] https://github.com/intridea/omniauth https://github.com/intridea/omniauth
eric_bullington 13y ago
The little comic programmer guy is hilarious. And actually, as someone who's fooling around with oauth right now, this looks very appealing. But yeah, the changing provider names might not be a good idea. Or at least decrease the interval.
- thyb 13y ago
  I decreased the interval to 10s.
yuliyp 13y ago
I wish there was more there than a mailing list signup and a teaser. What is it you're actually showing HN? Some animations?
- thyb 13y ago
  yes it's maybe more a kind of ASK HN if this API could interest people as we are finalizing it
  - yuliyp 13y ago
    Ah, cool. I'm kind of interested in how you work on the security aspects of it (will you give guidance on how to configure your client info for the various APIs (what do I fill in for all of the different URIs in my Facebook app config?), as well as more complicated scenarios (storing tokens in DB, associating tokens to accounts, etc.)
  - ctide 13y ago
    What's the difference between what you want to provide and Singly (singly.com)?
tusharc 13y ago
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!
tehwebguy 13y ago
This is cool. Is this for login alone or do you return API keys (and are the keys for the provider service or for OAuth.io)?
_frog 13y ago
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.
- IanChiles 13y ago
  Or even if there was a simple, detailed guide on what your own OAuth needs to do to be secure - and a basic overview of how to implement it (not language specific, just concept-wise).
  - EGreg 13y ago
    The TLDR version is: use https and OAuth 2.0, and this guide: https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.m...
    - 15charusername 13y ago
      Why Oauth2? I've read about it being less secure http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell... but would like to hear the case for it.
      - EGreg 13y ago
        Well if you implement OAuth 2 properly, you'll prevent session fixation and hijacking attacks, and with https you will also prevent man-in-the-middle attacks. The hueniverse guy was one of the people drafting the standard and as far as I can tell he laments that the providers can return a "bearer token" instead of a "mac token". That means the token is sent on every request to the provider, and without https it can be intercepted. But with https everything is fine! OAuth 1.0 didn't rely on https to prevent MITM attacks an instead used the "mac token" to sign each request to the provider, along with an increasing timestamp/nonce to prevent replay attacks. http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html http://www.codinghorror.com/blog/2012/02/should-all-web-traf...
mihok 13y ago
+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.
davefp 13y ago
Does this service require me to give up my private key for a given API? Seems like a huge security risk to me.
- misuba 13y ago
  It beats putting your private keys in client-side code (JS-only apps being those which this solution seems to be built for).
deleted 13y ago
[deleted]
maresca 13y ago
This REALLY could have helped me a week ago. Two oauth consumers later, it's not as easy as it seems.
- salahxanadu 13y ago
  Yes, it really is not. OAuth on mobile is frustrating experience of matching up responses and posts and figuring out which of the 5-10 variables and secrets or keys or tokens to give.
lucidrains 13y ago
the little programmer cartoon made me lol! good job!
outworlder 13y ago
I thought the comic programmer would be successful by step 100 or so, so I kept watching. I am now at step 125. Still watching...
- starefossen 13y ago
  You can check out how they did the comic programmer here: http://oauth.io/js/stubborn.js http://oauth.io/js/stubborn.js
6thSigma 13y ago
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. Edit: It looks like you changed the intervals. Much better now.
danielfone 13y ago
I was getting so impatient waiting for the stubborn programmer animation to finish. Inspect -> sources -> stubborn.js -> ohhhhhh... well done. 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"?
ams6110 13y ago
1. Setup your Facebook API Keys in OAuth.io lost me.
- jlogsdon 13y ago
  That's 1 out of 50+ examples. Facebook is easily the most commonly implemented, so why would they not make that the default example?
gulopine 13y ago
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. While building https://foauth.org/ 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 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/ https://foauth.org/.
- elviejo 13y ago
  OMG I needed something like foauth.org a couple of weeks ago. Oh well for next time, now I know.
lobster_johnson 13y ago
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. 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. [1] https://github.com/bengler/checkpoint https://github.com/bengler/checkpoint
nostromo 13y ago
If you'd like something similar to this that's available today, check out our startup: https://www.dailycred.com/ https://www.dailycred.com/ 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.
comex 13y ago
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. Grump.
- buro9 13y ago
  Occasionally I wonder whether the mantra to "solve your own problems" when looking for startup ideas is making things harder for ourselves. 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.
- josteink 13y ago
  Not only that, but the only thing which it seems to have to sell itself is a hipster domain-name.
deleted 13y ago
[deleted]
lhnz 13y ago
It might be nicer to follow the convention in EventEmitter on Node.JS rather than your own. Put (err, accessToken) instead of (accessToken, err).
Mailjet 13y ago
Cool!!
deleted 13y ago
[deleted]

149 points by thyb 13y ago

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.

enjo 13y ago
Hah.. I actually read this comment first and I was STILL just staring at my screen completely dumfounded. I'd see the little animation on the right update, and then something else would change. It was mystifying.
- jsmeaton 13y ago
  Made it really hard for me to focus on the content. I know exactly what was changing, and it wasn't that much, but it took a really long time (in comparison) to read the examples.
  - thyb 13y ago
    Alright, listening to your feedback it seems the animation was too much of a distraction, so we removed it. Thank you for your feedback!

spion 13y ago

I wish this existed before. For node.js stacks that support connect/express based middleware, we wrote oauth-flow instead https://github.com/doxout/node-oauth-flow 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.

tlrobinson 13y ago
There's also http://everyauth.com/ http://everyauth.com/ and http://passportjs.org/ http://passportjs.org/ for node.js How does yours compare to those?
- spion 13y ago
  In short - it doesn't assume that you want to use oauth for user authentication and authorization. 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.
jlogsdon 13y ago
Ruby has OmniAuth[1] which is Rack-based middleware. [1] https://github.com/intridea/omniauth https://github.com/intridea/omniauth

eric_bullington 13y ago

The little comic programmer guy is hilarious. And actually, as someone who's fooling around with oauth right now, this looks very appealing. But yeah, the changing provider names might not be a good idea. Or at least decrease the interval.

thyb 13y ago
I decreased the interval to 10s.

yuliyp 13y ago

I wish there was more there than a mailing list signup and a teaser. What is it you're actually showing HN? Some animations?

thyb 13y ago
yes it's maybe more a kind of ASK HN if this API could interest people as we are finalizing it
- yuliyp 13y ago
  Ah, cool. I'm kind of interested in how you work on the security aspects of it (will you give guidance on how to configure your client info for the various APIs (what do I fill in for all of the different URIs in my Facebook app config?), as well as more complicated scenarios (storing tokens in DB, associating tokens to accounts, etc.)
- ctide 13y ago
  What's the difference between what you want to provide and Singly (singly.com)?

tusharc 13y ago

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!

tehwebguy 13y ago

This is cool. Is this for login alone or do you return API keys (and are the keys for the provider service or for OAuth.io)?

_frog 13y ago

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.

IanChiles 13y ago
Or even if there was a simple, detailed guide on what your own OAuth needs to do to be secure - and a basic overview of how to implement it (not language specific, just concept-wise).
- EGreg 13y ago
  The TLDR version is: use https and OAuth 2.0, and this guide: https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.m...
  - 15charusername 13y ago
    Why Oauth2? I've read about it being less secure http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell... but would like to hear the case for it.
    - EGreg 13y ago
      Well if you implement OAuth 2 properly, you'll prevent session fixation and hijacking attacks, and with https you will also prevent man-in-the-middle attacks. The hueniverse guy was one of the people drafting the standard and as far as I can tell he laments that the providers can return a "bearer token" instead of a "mac token". That means the token is sent on every request to the provider, and without https it can be intercepted. But with https everything is fine! OAuth 1.0 didn't rely on https to prevent MITM attacks an instead used the "mac token" to sign each request to the provider, along with an increasing timestamp/nonce to prevent replay attacks. http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html http://www.codinghorror.com/blog/2012/02/should-all-web-traf...

mihok 13y ago

+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.

davefp 13y ago

Does this service require me to give up my private key for a given API? Seems like a huge security risk to me.

misuba 13y ago
It beats putting your private keys in client-side code (JS-only apps being those which this solution seems to be built for).

deleted 13y ago

[deleted]

maresca 13y ago

This REALLY could have helped me a week ago. Two oauth consumers later, it's not as easy as it seems.

salahxanadu 13y ago
Yes, it really is not. OAuth on mobile is frustrating experience of matching up responses and posts and figuring out which of the 5-10 variables and secrets or keys or tokens to give.

lucidrains 13y ago

the little programmer cartoon made me lol! good job!

outworlder 13y ago

I thought the comic programmer would be successful by step 100 or so, so I kept watching. I am now at step 125. Still watching...

starefossen 13y ago
You can check out how they did the comic programmer here: http://oauth.io/js/stubborn.js http://oauth.io/js/stubborn.js

6thSigma 13y ago

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. Edit: It looks like you changed the intervals. Much better now.

danielfone 13y ago

I was getting so impatient waiting for the stubborn programmer animation to finish. Inspect -> sources -> stubborn.js -> ohhhhhh... well done. 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"?

ams6110 13y ago

1. Setup your Facebook API Keys in OAuth.io lost me.

jlogsdon 13y ago
That's 1 out of 50+ examples. Facebook is easily the most commonly implemented, so why would they not make that the default example?

gulopine 13y ago

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. While building https://foauth.org/ 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 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/ https://foauth.org/.

elviejo 13y ago
OMG I needed something like foauth.org a couple of weeks ago. Oh well for next time, now I know.

lobster_johnson 13y ago

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. 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. [1] https://github.com/bengler/checkpoint https://github.com/bengler/checkpoint

nostromo 13y ago

If you'd like something similar to this that's available today, check out our startup: https://www.dailycred.com/ https://www.dailycred.com/ 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.

comex 13y ago

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. Grump.

buro9 13y ago
Occasionally I wonder whether the mantra to "solve your own problems" when looking for startup ideas is making things harder for ourselves. 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.
josteink 13y ago
Not only that, but the only thing which it seems to have to sell itself is a hipster domain-name.

deleted 13y ago

[deleted]

lhnz 13y ago

It might be nicer to follow the convention in EventEmitter on Node.JS rather than your own. Put (err, accessToken) instead of (accessToken, err).

Mailjet 13y ago

Cool!!

deleted 13y ago

[deleted]