One thing I discovered last week is OpenID Connect [1]. It layers an authentication standard upon oAuth2, without any of the cruft of 'legacy' OpenID it seems. Does anybody here have practical experience with OpenID connect?<p>[1] <a href="http://openid.net/connect/" rel="nofollow">http://openid.net/connect/</a>
Nice summary (even if I have some trouble accepting stateful auth as being RESTful...:)<p>One thing (perhaps rightfully) missing is auth in the tls/ssl layer. Client certs do work, pre-shared keys sadly do not really work. And I don't know what happened with tls-srp:<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=405155" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=405155</a>
Meteor.js is both impressive and terrifying. (I've only watched the screencast but, seemingly raw, database access from the user side is... eyebrow raising).<p>I'm not confident implementing SRP in Javascript provides any real advantage. From a trust standpoint, if you're going to use authentication code pushed to you, you're already all-in. The reason I advocate SRP on the web (via a browser implementation) is because 1) people reuse passwords and 2) I think it's become clear we can't trust web services, even big names, to handle passwords securely. We also can't trust corporations, public access machines and schools etc. not to strip SSL wholesale. We also shouldn't give bad actors the opportunity to put subtle backdoors in to authentication code of compromised servers.
I don't understand the problem mentioned with HTTP Basic, username/password injection
into the uri <a href="https://username:password@such-n-such.net" rel="nofollow">https://username:password@such-n-such.net</a> works just fine if for some reason you can't set the header explicitly. <a href="http://tools.ietf.org/html/rfc3986#section-3.2" rel="nofollow">http://tools.ietf.org/html/rfc3986#section-3.2</a>
Nice writeup indeed.<p>As far as I understood, the [MEAN.io](<a href="http://mean.io" rel="nofollow">http://mean.io</a>) stack implements OAuth2 like this - at the 'cost' of having two MVCs: one on the server side to deal with the authentifiction, 404 and 500, and the AngularJS one on the client side.<p>I hoped that there was an easier way to deal with the whole scenario, but obviously that is a good one.
I am actually writing a REST authentication service right now. The idea is to do it well once, and then reuse it in my other projects. It uses HTTP basic auth; as it is going to be called from the backend of my other projects it will not have the issues described in the article regarding the browser dialog.