ruby-on-rails - 具有半私密性的 OAuth 授权码的安全性

Question

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

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

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

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

Answer 1

即使在客户端 secret 可能泄漏的情况下，授权代码授予也比隐式授予更安全。这种情况与使用授权代码授予公共(public)而不是 secret 客户端相同。
隐式授权的唯一好处是简单性和性能改进(避免客户端和授权服务器之间的反向 channel 调用)。
隐式授权至少具有授权授权中不存在的这些弱点:

访问 token 在 URI 片段中传输，可能会将其暴露给未授权方(例如在浏览器缓存、引用参数、日志中)

在隐式授权中，资源所有者有权访问访问 token

如果 secret 在授权授予中泄露，潜在的攻击者将能够:

代表客户端请求 token (并可能模拟客户端，例如通过 DNS 操作)，但同样适用于隐式授权

如果攻击者能够获得刷新 token (通过危害客户端)，他将能够重新使用它们(可以通过不存储刷新 token 来缓解)

在任何情况下，您都应该确保授权服务器注册您的客户端的 URL，并验证在授权代码流期间提供的 redirect_uri 对客户端有效。您必须使用 SSL/TLS 将授权代码传输到客户端并交换访问 token 的授权代码。
您可以在 OAuth 2.0 威胁模型文档 (https://www.rfc-editor.org/rfc/rfc6819) 中找到有关此主题的更多讨论