我是否正确地认为OAuth 1.0a凭据需要以明文形式存储在服务器上（或以可以作为明文检索的方式），至少在进行两方身份验证时？ 假设您使用的是HTTPS或其他TLS，这不是比使用用户名和盐渍+哈希密码安全得多吗？ 有没有办法以这样的方式存储这些凭据，即安全漏洞不需要撤销每一个凭据？
更详细地说：我正在实现一个 API，并希望使用 OAuth 1.0a 保护它。 将来可能会有许多不同的 API 客户端，但到目前为止唯一一个不需要敏感用户数据，所以我计划使用"两腿"OAuth。
据我了解，这意味着我为每个 API 客户端生成一个使用者密钥和一个共享密钥。 在每个 API 请求中，客户端都会提供使用者密钥和使用共享密钥生成的签名。 密钥本身不是通过网络发送的，我绝对理解为什么这比直接发送用户名和密码更好。
但是，据我了解，使用者和提供者都必须显式存储使用者密钥和共享密钥（如果我错了，请纠正我），这似乎是一个重大的安全风险。 如果攻击者破坏了包含使用者密钥和共享机密的提供程序数据存储，则每个 API 客户端都将受到损害，重新保护系统的唯一方法是撤销每个密钥。 这与密码相反，密码（理想情况下）永远不会以可逆的方式存储在服务器上。 如果您正在对密码进行加盐和哈希处理，那么攻击者将无法仅通过破坏您的数据库来闯入任何帐户。
我所做的所有研究似乎都只是通过说"像保护任何敏感数据一样保护凭据"来掩盖这个问题，但这似乎很荒谬。 违规行为确实会发生，虽然它们可能会暴露敏感数据，但它们不应该允许攻击者冒充用户，对吧？
你是对的。 但是，oAuth 允许您代表用户登录，因此目标服务器（您从中访问数据的服务器）需要信任您提供的令牌。
当您是用户键入的机密的接收者时，密码哈希是很好的（顺便说一下，当 oAuth 向用户提供登录/接受窗口以在令牌之后生成时，实际上会发生什么）。这是"明文"部分发生的地方（用户以明文形式输入密码）。
你需要有一个等效的机制，以便服务器识别你;oAuth提供的是提供密码以外的其他东西的能力 - 一种用于代表他登录的有限授权形式。如果这泄漏，那么您需要使其无效。
你可以以或多或少详细的方式存储这些秘密，在一天结束时，你仍然需要向服务器提供"明文"版本（但是，该服务器可能会使用哈希来存储它以进行检查，因为它只需要验证你以纯文本形式呈现的内容，当散列时， 对应于他们存储的哈希值）