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

Question

我正在开发一个无法完全保护OAuth秘密的应用程序;有一组用户必须将其暴露给他们。想象一下如下情况：

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

我最初倾向于认为这样的环境应该使用implicit OAuth2工作流，该工作流不是基于保留在服务器上的秘密的密钥。但是，我越了解它，我越倾向于认为authorization code工作流程实际上可能更适合这里，因为秘密密钥 - 虽然不完全保密 - 至少只是暴露到“可信赖的”演员的子集。

我是否认为authorization code工作流只会 在一个不能保密的环境中提高安全性？我是否有任何理由？如果秘密被泄露，在authorization code工作流程上使用implicit引入威胁？如果匿名/公共用户无权访问该密钥，除了implicit以外的authorization code工作流程是否有任何理由（方便/简单）？

Answer 1

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

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

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

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

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

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

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

您可以在OAuth 2.0威胁模型文档（http://tools.ietf.org/html/rfc6819）中找到有关此主题的更多讨论