Ask HN: Authentication solution for REST? | Hacker News Reader

Ask HN: Authentication solution for REST?

9 pointsmojuba8 comments

I'm building a web-based application and I want it to be mostly AJAX talking to a remote REST service. There will be a user registration/login facility and many responses from the server will, naturally, depend on the login status.

What is the simplest solution for this? Ideally, I want the REST service to be easily debuggable from a browser without any additional tools. Is it cookies? Some session tokens? If so, what is the exact algorithm?

I don't think HTTP authentication is very practical, or I'd need to somehow prevent the browser from displaying its generic user/password dialog to the user in my final product.

Any real-world examples, maybe, of how some of the popular web sites do authentication with REST?

View on HN

S3 uses a request signing mechanism. Each request is signed by the client and the signature is sent in the headers.

Rackspace Cloud Files uses a token based authorization. Authentication provides a token that is then sent in the header of each request. When the token expires, re-authenticate to get a new token.

The Cloud Files method is a little simpler for the user (IMO), but it also requires an SSL connection to protect the credentials.

Neither of these products allow non-public objects to be viewed in a browser (the browser doesn't send the correct headers).

Something like the HTTP digest authentication but non-standard, right?

I think it's still possible to have the server accept the token as a URL parameter if it's in some special debug mode. Obviously the debug mode should be implemented with great caution.

Or challenges/digests can be sent back and forth as part of data rather than in the headers. This way I can debug the REST server using HTML forms.

In my opinion, browsers aren't a good way to test a REST interface. Browsers are good at GET, and maybe POST, but they are very limited for other HTTP verbs and can't really do much in the way of header manipulation.

A much better solution is to use a tool like curl. With curl, you can set headers, HTTP verbs (even custom ones), and, importantly, test each transaction in isolation.

I think http auth is pretty standard for REST stuff; users don't see it, so nobody cares that it is 'ugly'

(personally, I still don't understand why http auth isn't in use in other areas; it brings user authentication outside of your app and into the http server, which makes it quite a bit easier to make other apps written by different people in different languages/frameworks use the same auth.)

As long as you're talking to your service over SSL, basic auth is the way to go for non-human APIs.

As for hiding it from regular users, just make sure you never send a 401 response. If the user has accessed a protected resource without providing an authentication cookie, send a 302 to your login page like you (probably) normally would.

Ideally API users would get a 401 to prompt them to supply authentication, but if you can count on API users supplying their credentials with every request, you avoid that issue. And if that really bugs you you can probably figure out from the headers whether you're talking to a browser or a web service and send the appropriate response.

Huh. I thought you could just adjust your 401 error page HTML, just like you can adjust your 404 error page HTML... instead of putting something cute on it, you could put your login page on it.

You can adjust the HTML, but the browser will pop up a login dialog any time it gets a 401 HTTP status code from the server (unless it has saved credentials).

Safari btw will try to request every page without sending the credentials first, and then retry when it gets a 401.

keep in mind you can send username/passwords like so for browser-based debugging:

http://username:password@example.com/myresource/

Reply on news.ycombinator.com