My take on RESTful authentication(facundoolano.wordpress.com)
facundoolano.wordpress.com
My take on RESTful authentication
http://facundoolano.wordpress.com/2013/12/23/my-take-on-restful-authentication/
10 comments
Nice summary (even if I have some trouble accepting stateful auth as being RESTful...:)
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:
https://bugzilla.mozilla.org/show_bug.cgi?id=405155
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:
https://bugzilla.mozilla.org/show_bug.cgi?id=405155
I'm glad to see someone addressing this. I've been thinking about howto do this with devise in a more proper manner.
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).
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'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.
So basically OAuth2 Resource Password Owner is a formalization of Sessions...
I don't understand the problem mentioned with HTTP Basic, username/password injection
into the uri https://username:[email protected] works just fine if for some reason you can't set the header explicitly. http://tools.ietf.org/html/rfc3986#section-3.2
Urls aren't encrypted.
If you're on an entirely secure network, and you don't mind users seeing user name + password in the url then it might not be a problem.
If you're on an entirely secure network, and you don't mind users seeing user name + password in the url then it might not be a problem.
I think the (right) assumption is that http basic auth should always be used with TLS. Its why you can't generally install multiple certs on the same ip without sni support, no http headers, uri, url's etc. make it over the wire before the transport layer handshake. I've never seen these credentials appear in logs, and many browsers strip the auth preamble from the address bar. Anyway just food for thought, http basic isn't as bad as made out.
Urls are encrypted over TLS
Nice writeup indeed.
As far as I understood, the [MEAN.io](http://mean.io) 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.
I hoped that there was an easier way to deal with the whole scenario, but obviously that is a good one.
As far as I understood, the [MEAN.io](http://mean.io) 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.
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.
What are the main reasons why a home brewed authentication solution is considered a bad idea?
Authentication is a difficult problem to solve if you're doing it for more than one app. In addition, many auth solutions aren't secure front to back (usually only on the front side). Developers tend to be poor at writing proper security solutions on the whole - so having independent security practicioners have input is worthwhile (eg: open source, or enterprise) IMHO.
You're not going to homebrew a more secure solution than the paid professors. It's a hard problem even to them.
Nice, simple writeup and exploration of options :)
[1] http://openid.net/connect/