有关生成OAuth令牌的最佳做法？
我意识到OAuth规范没有规定ConsumerKey，ConsumerSecret，AccessToken，RequestToken，TokenSecret或Verifier代码的来源，但我很好奇是否有任何最佳做法来创build安全的令牌（特别是令牌/秘密组合）。
正如我所看到的，有几种创build令牌的方法：
- 只需使用随机字节，存储在关联到消费者/用户的数据库中
- 散列一些用户/消费者特定的数据，存储在与消费者/用户相关的数据库中
- encryption用户/消费者特定的数据
（1）的优点是数据库是似乎最安全的信息的唯一来源。 比（2）或（3）更难攻击。
散列真实数据（2）将允许从可能已知的数据重新生成令牌。 （1）可能不会提供任何好处，因为无论如何都需要存储/查找。 比（1）更多的CPU密集度。
encryption真实数据（3）将允许解密以获知信息。 这会比（1）和（2）需要更less的存储和潜在的更less的查找，但是可能不太安全。
还有其他方法/优点/缺点应该考虑吗？
编辑：另一个考虑是在令牌必须有某种随机值，因为必须有能力过期和重新发布新的令牌，所以它不能只包含真实的数据。
关注问题 ：
是否有一个最小令牌长度，以显着encryption安全？ 据我所知，更长的令牌秘密会创build更安全的签名。 这种理解是否正确？
从哈希的angular度来看，使用特定的编码是否有优势？ 例如，我看到很多使用hex编码的API（例如GUIDstring）。 在OAuth签名algorithm中，令牌用作string。 使用hexstring，可用字符集将比使用Base64编码时小得多（更可预测）。 在我看来，对于两个长度相等的string，具有较大字符集的string将具有更好/更宽的散列分布。 在我看来，这会提高安全性。 这个假设是否正确？
OAuth规范在11.10的秘密熵中提出了这个问题。
OAuth没有提供任何关于令牌的信息，只是它有一个相关的秘密。 所以你提到的所有scheme都会起作用。 我们的代币随着网站变大而演变。 这里是我们以前使用的版本，
-
我们的第一个标记是一个带有用户名，密码和过期时间的encryption的BLOB。问题是我们不能在主机上没有任何logging的情况下撤消标记。
-
所以我们改变了它把所有的东西存储在数据库中，令牌只是一个随机数，用来作为数据库的关键。 它有一个用户名索引，所以很容易列出用户的所有令牌并撤消它。
-
我们得到很less的黑客活动。 随机数字，我们必须去数据库，以确定令牌是否有效。 所以我们又回到了encryption的BLOB。 这次令牌只包含密钥的encryption值和有效期。 所以我们可以检测无效或过期的令牌，而不必去数据库。
一些实施细节可以帮助你，
- 在令牌中添加一个版本，以便您可以更改令牌格式而不破坏现有的令牌格式。 我们所有的令牌都有第一个字节的版本。
- 使用URL安全版本的Base64来编码BLOB，因此您不必处理URL编码问题，这使得使用OAuth签名进行debugging变得更加困难，因为您可能会看到三重编码的basestring。
把ip地址放在令牌里怎么样？
然后，你可以在每个请求解密令牌，并检查请求IP地址与令牌IP地址。
也许这个问题对于随机生成的攻击会更安全。
最好！
编辑：好吧，我想也许我不清楚enaugh。 我的post不是问题的答案。 我不会试图find在互联网上的文章，我用IP地址阅读实现，我同意，如果你把IP地址的令牌，dynamicIP地址和移动连接的客户端将有令牌问题。
