Show HN: Serverless OAuth on a Github page

http://oauth-io.github.io/oauth-js/index.html

by bumpmann • 13 years ago

37 8 13 years ago

oauth-io.github.io

shivaas• 13 years ago

this looks amazing, if only it would support gmail and yahoo as those are the two big use cases for me :) Couldn't find the "provider wishlist page" that you mention on the FAQ page. Overall, great job making this dead simple. Will definitely be using it in side projects!

joshfraser• 13 years ago

It's not exactly serverless. You're just using their server instead of your own. To make this work you have to give oauth.io your private keys. That said, I love the simplicity of this implementation. OAuth is still way too hard to implement by hand.

nadiac• 13 years ago

I think they mean serverless here more about the user experience because the user doesn't have to install a server to make it possible.

Because there is here as you mentionned Oauth.io server, but also Github server and lots of other servers for fonts/librairies etc...

Nothing is technically "serverless" on the web ;)

splitbrain• 13 years ago

If I understand it correctly the serverless part means that the whole OAuth process is handled in JavaScript on the client (the user's browser). There is no server-to-server communication.

voltagex_• 13 years ago

Can I use this to fix my python-gist script which needs a GitHub OAuth token but is not really supported because it's a console app?

https://github.com/voltagex/python-gist

Edit: Yes, I can. Until I get 100 users of the script, then I'd have to shut it down.

regecks• 13 years ago

It should handle the case where the authorisation is denied, as currently the oauth.io server spits out an unfriendly

  Invalid format

basicallydan• 13 years ago

Definitely using this - super helpful for quick prototypes, thanks.

davidjgraph• 13 years ago

This is misleading. There is 2 types of OAuth2 "flow", sometimes called server-flow and client-flow. Server-flow is the mechanism where a callback is registered with the auth server, but all comms and the initial auth have to go through some other server, which is just being setup for you in this case.

Client-flow is the far more interesting flow, for me, anyway. There the browser client gets the token directly from the auth server, that really is serverless. The key advantages of client-flow are you don't need the immediate server (less cost for you) and you don't have to see the data if you're using a third-party storage (better security and privacy).

You do need to be careful with security issues around the auth token itself, in server-flow you store the token on the server and have the session bind you to that token. Stealing a session is harder than stealing a token.

I know of two implementations to date:

Google's Official JavaScript Client library [0]

Dropbox's Unofficial JavaScript library [1]

[0] https://code.google.com/p/google-api-javascript-client/

[1]https://github.com/dropbox/dropbox-js

Show HN: Serverless OAuth on a Github page

Related Stories