How do you pass authorization data with an HTTP GET request in a RESTful system?

Question

This is probably the MOST basic question and for some reason but I'm a bit dumbfounded. I am designing a restful service which has multiple pages. Clicking on a link by default fires an HTTP GET

Now how do I send authorization data with the get request? Should it be part of url? I'll be forced to create an ugly url with encrypted query parameters. Is there any way to avoid this?

Is there something in javascript/jquery that could just send this data 'under the hood', so to speak?

in JQuery the $.ajax method takes username, password as arguments so that authorization data can be sent along with the ajax call. Anything equivalent for non-ajax calls or am I left with the URL only?

Reason for this approach:

• I want the user to be able to click the 'back button' and go back to the previous page. If I did a $.get with the authorization, and followed it with $('html').replaceWith(result) it would disable the back button, correct? (i.e., not show anything)

This should probably be a REST 101 but for some reason it's had me cornered

(FYI: Technologies: Jquery/javascript/Restlet/Freemarker)

(PS: Cookies as last resort. Or are they the best way? :)

Answer 1

With GET requests, you are limited to the Request headers and the query string/url of your request. You can use an HMAC approach or OAUTH, where each request is 'signed'. If you are doing this purely client side, there is the problem of the shared-secret no longer being, well, secret.

Of course, it sounds like you are already making POST requests using the username and password (which I highly discourage, BTW)

If you're wanting examples of HMAC in action, I believe Amazon does (or did) use HMAC for interacting with S3, so there are a lot of sample code around.

Ultimately, it is very difficult to have the web-client do stateless authentication without disclosing some 'secret' information, such as passwords or private keys/tokens. You could issue temporary tokens to the user that are then backed up by validating that the request headers (IP address, etc) are consistent through the life of the token. If you're disclosing temporary tokens to the client, you'll probably want your authentication mechanism to include a unique nonce per request, as well.

Purely stateless RESTful authentication is non-trivial if you want the web-client to be doing the requests, so I wouldn't call it REST 101 :)