OAuth 2.0 Bearer-Tokens 与 Mac-Tokens。为啥不使用 Mac 令牌?

Posted

技术标签:

【中文标题】OAuth 2.0 Bearer-Tokens 与 Mac-Tokens。为啥不使用 Mac 令牌?【英文标题】:OAuth 2.0 Bearer-Tokens vs. Mac-Tokens. Why not using Mac-Tokens?OAuth 2.0 Bearer-Tokens 与 Mac-Tokens。为什么不使用 Mac 令牌? 【发布时间】:2015-09-21 10:56:25 【问题描述】:

我搜索了该主题中的其他问题,但没有找到答案。所以告诉我如果我错了。 我是这个话题的新手,你可以很高兴地纠正我。这是我目前的想法:

我现在在网上冲浪了 2 天,想知道授权网络请求的实际技术水平是什么。现在我很快发现 OAuth 2.0 似乎是最常见的标准。但是 OAuth 2.0 本身并不是标准化的。在我看来,每个更大的公司都有不同的自定义设置。但无论如何,有两种技术可以交换授权信息:Mac-Tokens 和 Bearer-Tokens。

在我看来,Mac-Tokens 提供了更多的安全性。那么为什么它没有被广泛实施呢?我能找到的唯一原因是它有点复杂。而且我多次听到不推荐使用 Mac 令牌,如果客户端不是 100% 受信任的,因为客户端必须存储秘密。但区别在哪里?无论如何,客户端必须存储授权信息。在我看来,它是承载令牌还是 mac-secret 无关紧要。但是有所不同的是,mac-secret(而不是承载令牌)并不是在每次请求时都通过网络提交的。

那么你能告诉我为什么不使用 mac-tokens 的合理原因吗? (除了多一点努力) 我错过了什么吗?还是我误解了这两种令牌技术。

感谢您的阅读和帮助。

【问题讨论】:

【参考方案1】:

通过 mac 身份验证,您可以将 mac 机密存储在 android 设备的安全存储中,或者存储在 tpm pc 设备中……这样您就无法检索机密,但您可以在不知情的情况下从该存储进行 hmac 挑战秘密...对于 tls 证书客户端,您必须将证书发送到服务器并且可以被拦截(使用 mitm)...

【讨论】:

【参考方案2】:

如果正确使用 SSL/TLS 并且以机密和自助方式发出的客户端凭据,则采用 MAC 而不是 Bearer 令牌并没有太多优势。只会增加复杂性。客户有责任维护 client_secret 的机密性。当然,有些客户更喜欢使用 MAC 思维来提高安全性。

【讨论】:

我绝对不和你在一起。 SSL/TLS 不是 100% 安全的。有弱点。例如中间人攻击。如果用户决定继续。保安没了。如果此安全性失败,还有另一种可靠的机制来保护身份验证。【参考方案3】:

危险在于,如果客户端在不坚持 SSL/TLS 证书有效的情况下继续进行 - 这是许多客户端未能采取的步骤 - 那么不记名令牌很容易受到中间人的攻击。

Mac 令牌不易受到这种攻击;可以说 Mac 令牌在没有 SSL/TLS 的情况下提供了一些真实性,或者确实在没有正确使用的情况下提供了一些真实性。

Mac 令牌加强了 Bearer 令牌的一个已知弱点。

不应使用共享的 MAC 密钥信任客户端。应为每个客户端生成一个新密钥。使用自己的密钥信任每个客户端不会带来更多安全风险,就像使用不记名令牌信任它们一样。

我认为在将授权授予交换访问令牌时会出现问题。对于 Mac 密钥,这将返回一个对称密钥。如果客户端检查 SSL/TLS 证书马虎,那么这也容易受到 MITM 攻击。

简而言之,Mac 令牌可能不太受欢迎,因为它更复杂,但您仍然需要正确执行 SSL/TLS 以使其安全,如果您这样做,那么 Bearer 令牌也将是安全的。

【讨论】:

是的,我绝对支持你。无论如何,你不能没有 SSL/TLS,这只是不专业的。我认为你是对的,它只是没有使用,因为它更复杂。因为 Mac-Token 在各个方面都更加安全。无论您是否可以信任客户。【参考方案4】:

在我看来,答案可能很简单:承载令牌机制假设存在 SSL/TLS 层,而 MAC 令牌试图取代它。既然 SSL/TLS 被广泛接受和使用,为什么要做的事情比需要的更复杂?

是的,正如最近在 heartbleed 漏洞中看到的那样,许多事情并不像预期的那样可靠,但谁保证 MAC 实现也没有故障?

正如您所提到的,另一点是交换对称秘密。在没有绝对可靠的辅助通道的情况下,这可能会很棘手。信任客户也可能是个问题。

【讨论】:

好的,我明白你的意思。但我认为 MAC-Token 不会强制替换 SSL/TLS。最好的选择是同时使用两者。 SSL/TLS 和 MAC-Token-Authentication,因此您拥有比 Bearer-Tokens 更好的安全性。还是我错了? 好吧,我可能对“替换”不太准确。承载令牌值必须受到保护,通常通过 SSL/TLS。如果由于某种原因不能涉及 HTTPS,则不能使用 Bearer 令牌方案。不过,您可以依赖 MAC 身份验证机制。 IETF 文档明确指出:“该机制的主要设计目标是简化和改进那些不愿意或无法为每个请求使用 TLS 的服务的 HTTP 身份验证。特别是,该机制利用初始 TLS 设置阶段来建立一个共享的客户端和服务器之间的秘密。” 好的。是的,现在我更好地理解了你的意思 =) 我与一位安全专家交谈,他告诉我他永远不会在没有加密 (HTTPS) 的情况下使用 mac-authentication,最好的选择是使用带有加密的 mac-token。但我知道你的意思。

以上是关于OAuth 2.0 Bearer-Tokens 与 Mac-Tokens。为啥不使用 Mac 令牌?的主要内容,如果未能解决你的问题,请参考以下文章

OAuth 2.0 认证的原理与实践

OAuth 2.0 与 JWT

Oauth 2.0 配置与 Spring Security 冲突

Spring Security 5 OAuth 2.0 ResourceServer 如何与 AuthorizationServer 通信?

授权与认证OAuth 2.0 和 OIDC 的异同点

OAuth 2.0 认证的原理与实践