title: Best practices around generating OAuth tokens?
body: <p>I realize that the <a href="http://oauth.net/core/1.0a#rfc.section.6" rel="noreferrer">OAuth spec</a> doesn't specify anything about the origin of the ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret, or Verifier code, but I'm curious if there are any best practices for creating significantly secure tokens (especially Token/Secret combinations).</p>
  
  <p>As I see it, there are a few approaches to creating the tokens:</p>
  
  <ol>
  <li>Just use random bytes, store in DB associated with consumer/user</li>
  <li>Hash some user/consumer-specific data, store in DB associated with consumer/user</li>
  <li>Encrypt user/consumer-specific data</li>
  </ol>
  
  <p>Advantages to (1) are the database is the only source of the information which seems the most secure. It would be harder to run an attack against than (2) or (3).</p>
  
  <p>Hashing real data (2) would allow re-generating the token from presumably already known data. Might not really provide any advantages to (1) since would need to store/lookup anyway. More CPU intensive than (1).</p>
  
  <p>Encrypting real data (3) would allow decrypting to know information. This would require less storage &amp; potentially fewer lookups than (1) &amp; (2), but potentially less secure as well.</p>
  
  <p>Are there any other approaches/advantages/disadvantages that should be considered?</p>
  
  <p><strong>EDIT:</strong> another consideration is that there MUST be some sort of random value in the Tokens as there must exist the ability to expire and reissue new tokens so it must not be only comprised of real data.</p>
  
  <p><strong>Follow On Questions</strong>:</p>
  
  <p>Is there a minimum Token length to make significantly cryptographically secure? As I understand it, longer Token Secrets would create more secure signatures. Is this understanding correct?</p>
  
  <p>Are there advantages to using a particular encoding over another from a hashing perspective? For instance, I see a lot of APIs using hex encodings (e.g. GUID strings). In the OAuth signing algorithm, the Token is used as a string. With a hex string, the available character set would be much smaller (more predictable) than say with a Base64 encoding. It seems to me that for two strings of equal length, the one with the larger character set would have a better/wider hash distribution. This seems to me that it would improve the security. Is this assumption correct?</p>
  
  <p>The OAuth spec raises this very issue in <a href="http://oauth.net/core/1.0a#rfc.section.11.10" rel="noreferrer">11.10 Entropy of Secrets</a>.</p>