我正在实现用于 API 身份验证的两条腿 OAuth 协议(protocol)的提供者端。我们将为消费者提供消费者 key 和 secret ，他们将使用它们来签署请求。 2-legged OAuth 由互操作性标准规定，因此是一项要求。
这个 secret 有点类似于密码，我通常不会将密码存储为纯文本(bCrypt 或类似的将是我的正常选择)。但是因为我的提供者需要访问纯文本 secret 来验证签名，所以它必须是某种纯文本或可逆形式。
我考虑了以下选项:
将 secret 存储为纯文本
这是最明显的解决方案，但如果数据库以某种方式受到损害，那么所有的 secret 都必须更改。对我来说，这个解决方案并不理想，因为它存在以纯文本形式存储密码的所有问题。
使用存储在其他地方的加密 key 应用可逆加密(例如 AES)
这将提供一些安全性，因为如果数据库被破坏，那么 secret 仍然是安全的。但是可逆加密需要一个加密 key ，并且 key 必须存储在服务器上。这意味着如果攻击者破坏了机器，则可以绕过加密。
有什么我没有想到的吗？
澄清 实际上，它使用 2-legged Oauth 作为单点登录系统。 “消费者”创建一个请求，其中包括消费者 key 、随机数和其他几个参数。然后通过使用消费者 secret 计算 HMAC-SHA1 对整个请求进行签名。当请求到达我们的提供商系统时，该过程会重复，如果签名匹配，则请求处理将继续。因此，我们也需要纯文本 key 来计算我们这边的 HMAC-SHA1 签名。不幸的是，这种机制是由我们需要遵守的行业标准协议(protocol)规定的。
最佳答案
看看this previous question .我不是该主题的专家，但我认为您缺少等式的一部分。除了使用者 key 和 secret 之外，您还将验证发送请求的应用程序(如果您使用的是 RSA-SHA1，则使用 x509 证书)。
关于security - 如何为两条腿的 OAuth 提供者存储消费者 secret ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5702672/