title: OAuth 1.0 - how to implement both 2-legged and 3-legged authentication?
body: <p>I have implemented an OAuth 1.0a provider and have OAuth clients that can successfully authenticate against it, using the standard 3-legged authentication.</p>
  
  <p>OAuth protects a REST API on my server and I have a mobile app consuming it.</p>
  
  <p>In my mobile app, I have some functionalities (endpoints) that can be accessible even before the end-user logins to their private account.<br>
  Some user may even just want to use the public functionalities without creating an account.</p>
  
  <p>I would like to protect with OAuth both "public" and "private-to-the-user" endpoints.</p>
  
  <p>Therefore I think the way to go is to use OAuth the following way (but I may be wrong...very wrong).</p>
  
  <p>The mobile app will first do 2-legged authentication as soon as the app is launched the first time. That way the mobile app will get a "2-legged" token.  The mobile app will use this token to access public endpoints.</p>
  
  <p>When (and if) the user requests to login to the application, the mobile app will do a 3-legged authentication and will get a "3-legged token". From now on, the app will forget about the previous 2-legged token and use the 3-legged token 
  to access both public and private endpoints.</p>
  
  <p>1) First question. Does that make sense? Is there another good way to do that?</p>
  
  <p>Now my problem is: how can I (the server provider) know whether the mobile app wants to authenticate using 2-legged? I guess, as the provider, I need to know that in order to decide whether I will redirect the client to the login 
  form for the user to fill (in the case of 3-legged) or I will just issue an already-authorised request token (in the case of 2-legged) so that that can be exchanged for an access token (as for the 3-legged).  </p>
  
  <p>My idea for doing that was to provide the client with 2 consumer keys: one to use when they want 2-legged and one to use when they want 3-legged. Me, as a provider, I will know which flow to provide based on the consumer key I receive.</p>
  
  <p>2) Second (and last question). Is this sensible? Is there a better way to implement it?</p>
  
  <p>I have seen people implementing 2-legged by just allowing the client (consumer) to send an empty access token. Is that the way, instead?</p>
  
  <p>Thanks.</p>