title: Securing REST API without reinventing the wheel
body: <p>When designing REST API is it common to authenticate a user first?</p>
  
  <p>The typical use case I am looking for is:</p>
  
  <ul>
  <li>User wants to get data.  Sure cool we like to share! Get a public API key and read away!</li>
  <li>User wants to store/update data... woah wait up! who are you, can you do this?</li>
  </ul>
  
  <p>I would like to build it once and allow say a web-app, an android application or an iPhone application to use it.</p>
  
  <p>A REST API appears to be a logical choice with requirements like this</p>
  
  <p>To illustrate my question I'll use a simple example.</p>
  
  <p>I have an item in a database, which has a <strong>rating</strong> attribute (integer 1 to 5).</p>
  
  <p>If I understand REST correctly I would implement a GET request using the language of my choice that returns csv, xml or json like this:</p>
  
  <pre><code>http://example.com/product/getrating/{id}/
  </code></pre>
  
  <p>Say we pick JSON we return:</p>
  
  <pre><code>{
    "id": "1",
    "name": "widget1",
    "attributes": { "rating": {"type":"int", "value":4} }
  }
  </code></pre>
  
  <p>This is fine for public facing APIs. I get that part.</p>
  
  <p>Where I have tons of question is how do I combine this with a security model? I'm used to web-app security where I have a session state identifying my user at all time so I can control what they can do no matter what they decide to send me.  As I understand it this isn't RESTful so would be a bad solution in this case.</p>
  
  <p>I'll try to use another example using the same item/rating.</p>
  
  <p>If user "JOE" wants to add a <strong>rating</strong> to an <strong>item</strong></p>
  
  <p>This could be done using:</p>
  
  <pre><code>http://example.com/product/addrating/{id}/{givenRating}/
  </code></pre>
  
  <p>At this point I want to store the data saying that "JOE" gave product {id} a rating of {givenRating}.</p>
  
  <p>Question: How do I know the request came from "JOE" and not "BOB".</p>
  
  <p>Furthermore, what if it was for more sensible data like a user's phone number?</p>
  
  <p>What I've got so far is:</p>
  
  <p>1) Use the built-in feature of HTTP to authenticate at every request, either plain HTTP or HTTPS.</p>
  
  <p>This means that every request now take the form of:</p>
  
  <pre><code>https://joe:joepassword@example.com/product/addrating/{id}/{givenRating}/
  </code></pre>
  
  <p>2) Use an approach like Amazon's S3 with private and public key: <a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/">http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/</a></p>
  
  <p>3) Use a cookie anyway and break the stateless part of REST.</p>
  
  <p>The second approach appears better to me, but I am left wondering do I really have to re-invent this whole thing? Hashing, storing, generating the keys, etc all by myself? </p>
  
  <p>This sounds a lot like using session in a typical web application and rewriting the entire stack yourself, which usually to me mean "You're doing it wrong" especially when dealing with security.</p>
  
  <p>EDIT: I guess I should have mentioned OAuth as well.</p>