Hmm, I don't see any mention of security. I can't find the source, but I remember reading that if you wanted to restrict access to certain pages on your site to authenticated users in a single page app it was more secure to do it server side. Security experts feel free to chime in.
HelloJS is great. I've used it in my last project. It just works. It's well tested, and well documented. There's very little option twiddling required. It just worked seemlessly when I was trying to setup Twitter, Google, LinkedIn and Facebook OAuth logins.
This is great, perfect for little consumer web apps.
I am so happy about this, becuase we (my dev buddies) have just had an idea for a little social game that would be great if ported onto the web. I think I have just solved our simplistic user auth needs by reading this article.<p>Thanks for sharing.
How does this get away with not using the client secret? I thought OAuth 2.0 always required a three-way handshake (client is sent to provider, provider sends client back to service, service exchanges grant token with the provider).<p>Does this mean in Facebook, Google etc the grant token and the access token are identical?
Could you explain why I should favor client-side auth over server-side auth, especially if I want to do some action on behalf of the user, like generating word-clouds of their posts, etc. And what makes helloJS different from oauth.io, which has open-sourced their server?
Once you're authenticated in a client web page, lets say you want to perform data storage on your <i>own</i> server using this authenticated user as validation. How would your server validate the user's login is valid to accept user actions?
I really like adodson's web game. Check out <a href="http://adodson.com/#escape" rel="nofollow">http://adodson.com/#escape</a> for browser MineField & Flood It.