

Ask HN: Authentication solution for REST? - mojuba

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.<p>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?<p>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.<p>Any real-world examples, maybe, of how some of the popular web sites do authentication with REST?
======
notmyname
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).

~~~
mojuba
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.

~~~
notmyname
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.

------
lsc
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.)

~~~
frankus
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.

~~~
lsc
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.

~~~
frankus
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.

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

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

