Show HN: Serverless OAuth on a Github page(oauth-io.github.io)
oauth-io.github.io
Show HN: Serverless OAuth on a Github page
http://oauth-io.github.io/oauth-js/index.html
8 comments
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.
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 ;)
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 ;)
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.
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
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
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.
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.
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!
It should handle the case where the authorisation is denied, as currently the oauth.io server spits out an unfriendly
Invalid formatDefinitely using this - super helpful for quick prototypes, thanks.