title: How to keep the client credentials confidential, while using OAuth2's Resource Owner Password Credentials grant type
body: <p>We are building a rest service and we want to use OAauth 2 for authorization. The <a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16" rel="nofollow noreferrer">current draft</a> (v2-16 from May 19th) describes <a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16#section-4" rel="nofollow noreferrer">four grant types</a>. They are mechanisms or flows for obtaining authorization (an access token).</p>
  <ol>
  <li>Authorization Code</li>
  <li>Implicit Grant</li>
  <li>Resource Owner Credentials</li>
  <li>Client Credentials</li>
  </ol>
  <p>It seems we need to support all four of them, since they serve different purposes. The first two (and possibly the last one) can be used from third-party apps that need access to the API. The authorization code is the standard way to authorize a web application that is lucky enough to reside on a secure server, while the implicit grant flow would be the choice for a client application that can’t quite keep its credentials confidential (e.g. mobile/desktop application, JavaScript client, etc.).<br />
  We want to use the third mechanism ourselves to provide a better user experience on mobile devices – instead of taking the user to a login dialog in a web browser and so on, the user will simply enter his or her username and password directly in the application and login.
  We also want to use the Client Credentials grant type to obtain an access token that can be used to view public data, not associated with any user. In this case this is not so much authorization, but rather something similar to an API key that we use to give access only to applications that have registered with us, giving us an option to revoke access if needed.</p>
  <p>So my questions are:</p>
  <ol>
  <li>Do you think I have understood the purpose of the different grant types correctly?</li>
  <li>How can you keep your client credentials confidential? In both the third and fourth case, we need to have the client id and client secret somewhere on the client, which doesn't sound like a good idea.</li>
  <li>Even if you use the implicit grant type and you don’t expose your client secret, what stops another application from impersonating your app using the same authorization mechanism and your client id?</li>
  </ol>
  <p>To summarize, we want to be able to use the client credentials and resource owner credentials flow from a client application. Both of these flows require you to store the client secret somehow, but the client is a mobile or JavaScript application, so these could easily be stolen.</p>