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'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.
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.
8 comments
[ 3.2 ms ] story [ 25.7 ms ] threadBecause 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 ;)
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.
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