4 ms·

My take on RESTful authentication

45 points by facundo_olano 13y ago

czbond 13y ago
I'm glad to see someone addressing this. I've been thinking about howto do this with devise in a more proper manner.
sekm 13y ago
So basically OAuth2 Resource Password Owner is a formalization of Sessions...
abengoam 13y ago
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.
basicallydan 13y ago
Nice, simple writeup and exploration of options :)
dirkk0 13y ago
Nice writeup indeed. As far as I understood, the [MEAN.io](http://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.
nly 13y ago
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.
ak39 13y ago
What are the main reasons why a home brewed authentication solution is considered a bad idea?
- Rygu 13y ago
  You're not going to homebrew a more secure solution than the paid professors. It's a hard problem even to them.
- czbond 13y ago
  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.
e12e 13y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=405155
SanderMak 13y ago
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? [1] http://openid.net/connect/ http://openid.net/connect/
feralmoan 13y ago
I don't understand the problem mentioned with HTTP Basic, username/password injection into the uri https://username:password@such-n-such.net https://username:password@such-n-such.net works just fine if for some reason you can't set the header explicitly. http://tools.ietf.org/html/rfc3986#section-3.2 http://tools.ietf.org/html/rfc3986#section-3.2
- steverb 13y ago
  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.
  - feralmoan 13y ago
    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.
  - voxic11 13y ago
    Urls are encrypted over TLS

45 points by facundo_olano 13y ago

czbond 13y ago

I'm glad to see someone addressing this. I've been thinking about howto do this with devise in a more proper manner.

sekm 13y ago

So basically OAuth2 Resource Password Owner is a formalization of Sessions...

abengoam 13y ago

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.

basicallydan 13y ago

Nice, simple writeup and exploration of options :)

dirkk0 13y ago

Nice writeup indeed. As far as I understood, the [MEAN.io](http://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.

nly 13y ago

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.

ak39 13y ago

What are the main reasons why a home brewed authentication solution is considered a bad idea?

Rygu 13y ago
You're not going to homebrew a more secure solution than the paid professors. It's a hard problem even to them.
czbond 13y ago
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.

e12e 13y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=405155

SanderMak 13y ago

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? [1] http://openid.net/connect/ http://openid.net/connect/

feralmoan 13y ago

I don't understand the problem mentioned with HTTP Basic, username/password injection into the uri https://username:password@such-n-such.net https://username:password@such-n-such.net works just fine if for some reason you can't set the header explicitly. http://tools.ietf.org/html/rfc3986#section-3.2 http://tools.ietf.org/html/rfc3986#section-3.2

steverb 13y ago
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.
- feralmoan 13y ago
  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.
- voxic11 13y ago
  Urls are encrypted over TLS