具有半私密性的 OAuth 授权码的安全性答案

【问题标题】：Security of OAuth Authorization Code with Semi-Private Secret具有半私密性的 OAuth 授权码的安全性
【发布时间】：2014-03-23 15:33:39
【问题描述】：

我正在开发一个无法完全保护 OAuth 机密的应用程序；有一组用户将根据需要暴露给他们。所以想象一下这样的情况：

一家公司正在开发它为公众托管的软件，该软件依赖于 OAuth2 对某个第 3 方进行身份验证。但不可避免的是，该应用程序的 OAuth 机密将暴露给公司的所有员工。据推测，一些不良员工可能会将其用于邪恶目的或与其他人分享。

我最初倾向于认为这样的环境应该使用implicit OAuth2 工作流程，该工作流程不依赖于在服务器上保持秘密的密钥。然而，我读得越多，我就越倾向于相信authorization code 工作流实际上可能更适合这里，因为密钥——虽然没有完全保密——至少只暴露于“受信任”参与者的子集。

我认为authorization code 工作流程仅在无法完全保密密钥的环境中提高安全性是否正确？ 是否引入了任何威胁如果秘密已被泄露，通过在implicit 工作流上使用authorization code？如果匿名/公共用户无法访问密钥，除了使用implicit 工作流而不是authorization code 更方便/简单之外，还有什么理由吗？

【问题讨论】：

感谢杰夫的赏金。

标签： ruby-on-rails security oauth oauth-2.0 google-oauth

【解决方案1】：

即使在客户端机密可能泄漏的情况下，授权代码授予也比隐式授予更安全。这种情况与对公共而非机密客户使用授权码授予相同。

隐式授权的唯一好处是简单性和性能改进（避免客户端和授权服务器之间的反向通道调用）。

隐式授权至少具有授权授权中不存在的这些弱点：

访问令牌在 URI 片段中传输，可能会将其暴露给未授权方（例如，在浏览器缓存、引用参数、日志中）
在隐式授权中，资源所有者有权访问访问令牌

如果机密在授权授权中泄露，潜在的攻击者将能够：

代表客户端请求令牌（并可能模拟客户端，例如通过 DNS 操作），但同样适用于隐式授权
如果攻击者能够获得刷新令牌（通过危害客户端），他将能够重新使用它们（可以通过不存储刷新令牌来缓解）

在任何情况下，您都应该确保授权服务器注册您的客户端的 URL，并验证在授权代码流期间提供的 redirect_uri 对客户端有效。您必须使用 SSL/TLS 将授权代码传输到客户端并交换访问令牌的授权代码。

您可以在 OAuth 2.0 威胁模型文档 (https://www.rfc-editor.org/rfc/rfc6819) 中找到有关此主题的更多讨论

【讨论】：