title: How to develop user-authenticated REST service with Azure ACS
body: <p>I'm developing a REST service that uses MS Azure Access Control Service for authentication. If the examples are any indication, the typical way to secure a REST service this way would be to provide a global username and pw, private key, or X.509 cert for the protected service. However, I want to use the passive <em>user</em> login mechanism on a mobile device with a flow more like the following:</p>
  
  <ol>
  <li>Unauthenticated user attempts to access protected service from app</li>
  <li>Mobile app redirects to browser app (or embedded browser)</li>
  <li>User selects identity provider to use for login (facebook, google, etc.) from ACS login page</li>
  <li>User enters credentials for identity provider</li>
  <li>Browser redirects back to app</li>
  <li>App somehow gets the SWT token to use with subsequent REST requests.</li>
  </ol>
  
  <p>I'm stuck at about step 5--getting the SWT token, and the existing examples I've found don't seem to address this scenario. In addition, I'm actually trying to build a proof of concept with a desktop client in WPF, which may complicate things. Can anyone suggest a specific tutorial or a path to pursue that uses the per-user authentication vs. per-service? Thanks.</p>
  
  <p><strong>EDIT:</strong>
  As I'm digging into this deeper, I've realized that the examples posted below (and most others) are based on OAuth WRAP, which has been deprecated in favor of OAuth 2.0. Can anyone suggest a more up to date reference? Googling has turned up <a href="http://blogs.msdn.com/b/adventurousidentity/archive/2011/09/18/acs-v2-oauth-2-0-delegation-support-explained.aspx" rel="nofollow">http://blogs.msdn.com/b/adventurousidentity/archive/2011/09/18/acs-v2-oauth-2-0-delegation-support-explained.aspx</a> and <a href="http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=32719" rel="nofollow">http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=32719</a> but they're not the most intuitive.</p>