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

Question

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

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

我最初倾向于认为这样的环境应该使用implicitOAuth2工作流程,该工作流程不是基于在服务器上保密的秘密密钥.然而,我越了解它,我越倾向于认为authorization code工作流实际上可能更适合这里,因为秘密密钥 - 虽然不完全保密 - 至少只暴露于"值得信赖的"演员

我是否正确地相信authorization code工作流程只会增加密钥不能完全保密的环境中的安全性？是否有利用引入的任何威胁,authorization code在implicit工作流程,如果这个秘密已经被泄露？如果匿名/公共用户无法访问密钥,除了方便/简单之外还有其他任何原因可以使用implicit工作流authorization code吗？

Answer 1

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

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

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

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

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

• 代表客户端请求令牌（并且可能冒充客户端，例如通过 DNS 操作），但这同样适用于隐式授予
• 如果攻击者能够获得刷新令牌（通过损害客户端），他将能够重新使用它们（可以通过不存储刷新令牌来缓解这种情况）

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

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