title: How would an efficient OAuth2.0 server / provider work?
body: <p>I may need to implement an OAuth2.0 server for an API I'm creating. This API would allow 3rd parties to perform actions on the user's behalf.</p>
  
  <p>OAuth2.0 has 3 mains calls. First, there is a call to prompt the user for consent. This returns a <code>code</code>. The second is where the <code>code</code> is exchanged for a <code>access token</code>. Finally, the <code>access token</code> is used to call the API on the user's behalf.</p>
  
  <p>For implementation, I was thinking the first call generates a random string which acts as a <code>code</code>. The <code>code</code> is then stored in a database with a pointer to the current User and a random <code>HMAC Key</code>, then the random data is returned to the 3rd party as the <code>code</code>.</p>
  
  <p>When the 3rd party requests an <code>access token</code>, another piece of random data is generated and concatenated with the <code>code</code>. This string is signed using the <code>HMAC key</code> from Step 1, then this signed string and signature is returned with the signature to form the <code>access token</code>.</p>
  
  <p>When the API call occurs, the <code>hmac key</code> corresponding to the provided <code>access_token</code> is retrieved from the database. The signature of the <code>access_token</code> is verified using the hmac key. </p>
  
  <p>The user can revoke 3rd party access by simply removing an HMAC key from their list of authorized HMAC keys. Furthermore, but just signing random data, I can avoid storing every single access_token every created, and instead maintain a short list of hmac keys.</p>
  
  <p>Anyway, this is my first attempt as thinking through this. Surprisingly, there is little information about implementing the server side of OAuth2.0 efficiently. I would prefer to keep as little information as possible in the database. The advantage of signing random data then later revoking the HMAC key is that I don't have to store every single <code>access token</code> generated by every single authorization call.</p>
  
  <p>Thoughts needed! There has got to be a better way!</p>
  
  <p>EDIT:</p>
  
  <p>I'm NOT looking for an implementation. Thank you though! Also, I assume this whole system will run over HTTPs. Also, I'm talking about the pure OAuth2.0 flow, I'm <em>not</em> talking about OAuth1.0 with signatures and client keys. I'm asking how to design the cryptography behind an OAuth2.0 server that would work in a similar fashion to (for example) Google's OAuth2.0 flow works.</p>