How would a user stay logged in to a REST-based website?

A year or so ago I asked this question: Can you help me understand this? “Common REST Mistakes: Sessions are irrelevant”. My question was essentially this:

Okay, I get that HTTP authentication is done automatically on every message - but how? Is the username/password sent with every request? Doesn't that just increase attack surface area? I feel like I'm missing part of the puzzle.

The answers I received made perfect sense in the context of a mobile (iPhone, Android, WP7) app - when talking to a REST service, the app would j开发者_运维技巧ust send user credentials along with each request. That worked great for me.

But now, I would like to better understand how one would secure a REST-like website, like StackOverflow itself or something like Reddit. How would things work if it was a user logged in via a web browser instead of logged in via an iPhone app?

• What happens when a user logs in? Are the credentials saved in the browser somehow?
• How would the browser know what credentials to send with subsequent REST requests?
• What if it's a JavaScript call to a webservice? How would the JavaScript call include user credentials?

I'll be quite frank: my understanding of security when it comes to websites is pretty limited, I'm not a web developer (Damnit Jim, I'm a desktop developer!). I enjoyed working with REST services from an app perspective, but now I want to try and build a website that is based on REST principles, and I'm finding myself to be pretty lost.

If there is anything in the above question that is unclear that you'd like me to clarify, please leave a comment and I'll address it.

If you use a proxy like Fiddler, you can see exactly what stackoverflow does.

It connects to a resource on /users/authenticate/?s=.... which responds with two "Set-Cookie" commands in the header (gauth and usr).

Those cookies are passed in the headers of subsequent requests to stackoverflow.

I'm assuming that stackoverflow looks the keys up from those cookies to make sure you're previously authorized. When the cookie expires, you're considered logged out.

The real problem is that web browsers suck. Ok, so maybe I'm just bitter ;-).

If you create a website that uses one of the standard HTTP authentication mechanisms like Basic or Digest then the browser will pop open a login screen and then use those credentials on every future request.

However, most people want control over the way their login page looks, but to my knowledge if you capture login information in this way there is no way to tell the browser, hey, use these credentials in the Authentication header in future requests.

It would also be nice if there was a way to tell the browser, hey, those credentials you are using, please forget them. That would allow you to effectively logout.

The workaround as has already been suggested is to use cookies as a replacement for the Authorization header. It is not ideal, but as long as the cookie is only used to provide authentication information and not as a server side session identifier then all is good.

After having authenticated, the user usually gets a "cookie" (that contains a unique session identifier), which is sent back from the client to the server on every subsequent request.

http://en.wikipedia.org/wiki/HTTP_cookie