title: Best practices for authentication and authorization in Angular without breaking RESTful principles?
body: <p>I've read quite a few SO threads about authentication and authorization with REST and Angular, but I'm still not feeling like I have a great solution for what I'm hoping to do. For some background, I'm planning to building an app in AngularJS where I want to support:</p>
  
  <ol>
  <li>Limited guest access</li>
  <li>Role-based access to the application once authenticated</li>
  <li>Authentication via APIs</li>
  </ol>
  
  <p>All of the calls to the REST API will be required to occur over SSL. I'd like to do build the app without breaking RESTful principles, namely not keeping session state stored on the server. Of course, whatever is done vis-a-vis authorization on the client-side has to be reinforced on the server side. Since we need to pass the entire state with each request, I know I need to pass some sort of token so that the backend server receiving the REST request can both authenticate and authorize the call. </p>
  
  <p>With that said, my main question is around authentication - what are the best practices here? It seems there are lots of different approaches discussed, here's just a few that I've found:</p>
  
  <ul>
  <li><a href="http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html" rel="nofollow noreferrer">http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html</a></li>
  <li><a href="http://frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/" rel="nofollow noreferrer">http://frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/</a></li>
  <li><a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html" rel="nofollow noreferrer">http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html</a></li>
  </ul>
  
  <p>There was a similar question asked (<a href="https://stackoverflow.com/questions/22263644/angularjs-best-practice-application-authentication">AngularJS best practice application authentication</a>), but unless I'm misunderstanding the answer, it seems to imply that a server session should be used, which is breaking RESTful principles. </p>
  
  <p>My main concern with the Amazon AWS and the George Reese article is it seems to assume that the consumer is a program, rather than an end user. A shared secret can be issued to a programmer in advance, who can then use it to encode calls here. This isn't the case here - I need to call the REST API from the app on behalf of the user.</p>
  
  <p>Would this approach be enough? Let's say I have a session resource:</p>
  
  <p><strong>POST /api/session</strong></p>
  
  <p>Create a new session for a user</p>
  
  <p>To create a session, you need to POST a JSON object containing the "username" and "password".</p>
  
  <pre><code>{
      "email" : "austen@example.com",
      "password" : "password"
  }
  </code></pre>
  
  <p><strong>Curl Example</strong></p>
  
  <pre><code>curl -v -X POST --data '{"username":"austen@example.com","password":"password"}' "https://app.example.com/api/session" --header "Content-Type:application/json"
  </code></pre>
  
  <p><strong>Response</strong></p>
  
  <pre><code>HTTP/1.1 201 Created {
      "session": {
          "id":"520138ccfa4634be08000000",
          "expires":"2014-03-20T17:56:28+0000"
      }
  }
  </code></pre>
  
  <p><strong>Status Codes</strong></p>
  
  <ul>
  <li>201 - Created, new session established</li>
  <li>400 - Bad Request, the JSON object is not valid or required information is missing</li>
  <li>401 - Unauthorized, Check email/password combo</li>
  <li>403 - Access Denied, disabled account or license invalid</li>
  </ul>
  
  <p>I'm leaving out the HATEOAS details for clarity. On the backend, there would be a new, limited duration session key created and associated with the user. On subsequent requests, I could pass this as part of the HTTP headers:</p>
  
  <pre><code>Authorization: MyScheme 520138ccfa4634be08000000 
  </code></pre>
  
  <p>Then the backend servers would be responsible for digesting this out of the request, finding the associated user and enforcing authorization rules for the request. It should probably update the expiration for the session as well. </p>
  
  <p>If all this is happening over SSL, am I leaving the door open to any kind of attacks that I should be protecting against? You could try to guess session keys and place them in the header, so I suppose I could additionally append a user GUID to the session key to further prevent brute force attacks. </p>
  
  <p>It's been a few years since I've actively programmed and I'm just getting back into the swing here. Apologies if I'm being obtuse or unnecessarily reinventing the wheel, just hoping to run my ideas by the community here based on my reading thus far and see if they pass the litmus test.</p>