1

I've seen many questions about restful-authentication but I'm wondering what strategies are being used to keep browser user agents stateless while authenticating to a RESTful web-service.

Doing it with a custom REST Client is "easy": We can use Basic Auth, Digest, OAuth or roll your own (custom headers, tokens, signatures etc). Thus, for machine to machine we are pretty much covered but I'm only interested in authentication with everyday browser user agents (IE, Firefox etc). For example JSON is out since the browser can not render / use it ;)

Here are some of my thoughts in terms of browser limitations:

  • AFAICS there is no way for a browser to send custom headers such as those used by OAuth? (Right?)
  • I have a feeling that one should be able to have a login page (html+ssl for example) where the user does a login. (No Basic auth) The browser then captures a token(s) and passes it back the server with each request. The problem I have with Basic Auth is that I do not have a “nice custom login page”. Is the current authentication mechanism to extensible that we can keep it restful?
  • I'm careful in breaking / relaxing REST constraints because of the risk of loosing the benefits of scalability.

A similar answer here but I have a special case against cookies : (without going to much detail): The way browsers currently work in using cookies is out of the question since the server is in control of the cookies. ("Set-Cookie" header from server side state). The client does not understand or interpret the contents of cookies it's fed and just returns it. The problems is that the client is not in control of the cookie. Thus, yes we can use cookies in a restful way in "custom/machine to machine clients" but it's not the way browsers implements it.

What strategies and best practices are there that you have been using and what are your experiences? Any extra comments?

Community
  • 1
  • 1
Derick Schoonbee
  • 2,971
  • 1
  • 23
  • 39
  • Some extra info: I use a custom built http server (Qt). I'm interested in approaches that people used and what impact it had on relaxing or sticking to the REST constraints. Trade-offs they made and what the impact was down the road. – Derick Schoonbee Apr 13 '11 at 22:32

2 Answers2

1

I think the browser limitations you mention are essentially insurmountable for most use cases. Our personal solution is to have a lightweight non-RESTful layer presented to the user which contains a custom REST client; for example, for JavaScript apps we expose a server-side REST client via JSON-RPC.

cmbuckley
  • 40,217
  • 9
  • 77
  • 91
  • I like the idea about a client in the browser since it falls in the code-on-demand REST principle. I'll probably throw in some jQuery authentication helper script. Thanks. – Derick Schoonbee Apr 14 '11 at 09:37
1

If you are using an apache web server, you might want to take a look at this document.

stand
  • 3,054
  • 1
  • 24
  • 27
  • After some more research I've re-discovered the referenced link. Not bad.. +1 . I'm using my own C++ Web server and this approach looks interesting... – Derick Schoonbee Aug 27 '12 at 20:06