OAuth 2.0 Bearer-Tokens 和 Mac-Tokens。为什么不使用 Mac-Tokens？

Question

我在这个主题中搜索了其他问题，但没有找到确切的答案。所以如果我错了，请告诉我。 我是新手，你可以很愉快地纠正我。以下是我目前的想法： 我现在在网上冲浪了两天，了解授权Web请求的实际状态。现在我很快就发现OAuth 2.0似乎是最常见的标准。但OAuth 2.0本身与标准化相去甚远。在我的视野中，这是每个大公司不同自定义的混乱局面。但无论如何，有两种技术用于交换授权信息：Mac-Tokens和Bearer-Tokens。

在我看来，Mac-Tokens提供更多的安全性。那么为什么它没有被广泛实现呢？我唯一能找到的原因是因为它有点更加复杂。我听到过许多次人们说，如果客户端不是100％可信的话，就不建议使用Mac-Tokens，因为客户端必须存储密钥。但是区别在哪里呢？客户端无论如何都必须存储授权信息。在我看来，无论是bearer-token还是mac-secret都没有关系。但是差异在于mac-secret（而不是bearer-token）不会在每个请求上通过网络提交。

那么，除了需要付出一些努力之外，您能告诉我为什么不使用Mac-Tokens的明智理由吗？我有什么遗漏吗？还是我误解了这两种令牌技术。

谢谢阅读和您的帮助。

- Daniel

Answer 1

危险在于，如果客户端不坚持要求SSL/TLS证书是有效的 - 这是许多客户端没有采取的步骤 - 那么Bearer token容易受到中间人攻击。

Mac token不会受到这种攻击；可以说，在缺少SSL/TLS或者未正确使用时，Mac token提供了一定的真实性。

Mac token增强了Bearer token已知的弱点。

客户端不应信任共享的MAC密钥。对于每个客户端都应该生成一个新的密钥。委托它们各自的密钥不会比信任Bearer tokens更加安全。

我认为问题出在将授权授予转换为访问令牌时。对于Mac密钥，这将返回对称秘密密钥。如果客户端松懈地检查SSL/TLS证书，那么它也容易受到MITM攻击。

简而言之，Mac token可能不太受欢迎，因为它更加复杂，但您仍然需要正确使用SSL/TLS才能使它安全，并且如果您这样做，则Bearer token也将是安全的。

- user2800708

---

是的，我完全同意你的观点。无论如何，你都不能没有SSL/TLS，否则这将显得不专业。我认为你是正确的，只不过它并不常用是因为它更加复杂。因为Mac-Token在各个方面都更加安全，无论你能否信任客户端。 - Daniel

请注意，当提到“MAC密钥”时，本答案指的是mac_key参数，该参数仅存在于MAC令牌中，并且是真正的秘密。请参阅MAC令牌规范。 - Akaisteph7

澄清一下，这个答案解释了使用 MAC 令牌时中间人攻击仍然可能发生，但仅限于授权授予阶段。但是，Bearer 令牌始终容易受到攻击，即使在稍后访问数据时也是如此，因为 access_token 是其真正的密钥，并且将直接发送请求中（参见示例）。因此，从技术上讲，MAC 令牌更安全，但在仅通过强制执行 SSL/TLS 协议的连接发送时，两者才能真正保证安全。而且，在使用 SSL/TLS 时，它们在安全性方面基本上是等效的。 - Akaisteph7

Answer 2

在我看来，答案可能很简单：Bearer令牌机制假定存在SSL/TLS层，而MAC令牌试图替换它。由于SSL/TLS被广泛接受和使用，为什么要把事情搞得比需要的更加复杂呢？

是的，正如最近发现的心脏出血漏洞一样，许多东西并不像预期的那样可靠，但是谁能保证MAC实现没有故障呢？

另一个问题是，正如你提到的，对称密钥的交换。在没有绝对可靠的次要信道的情况下，这可能会很棘手。而且信任客户端也可能成为一个问题。

- The Ancient

---

好的，我理解你的观点。但是在我看来，MAC-Token并不强制替换SSL/TLS。最好的选择是同时使用SSL/TLS和MAC-Token身份验证，这样比使用Bearer-Tokens更安全。或者我错了吗？ - Daniel

嗯，我可能在“替换”方面没有表达得很准确。Bearer令牌值必须受到保护，通常通过SSL/TLS进行保护。如果由于某些原因您无法使用HTTPS，则不得使用Bearer令牌方案。但是，您仍然可以依赖MAC身份验证机制。IETF文档明确指出：“该机制的主要设计目标是简化和改进对于那些不愿或无法为每个请求使用TLS的服务的HTTP身份验证。特别地，该机制利用初始TLS设置阶段来建立客户端和服务器之间的共享密钥。” - The Ancient

好的。现在我更明白你的意思了 =) 我和一位安全专家交谈过，他告诉我他永远不会使用没有加密（HTTPS）的MAC身份验证，最好的选择是使用带有加密的MAC令牌。但我知道你的意思。 - Daniel

Answer 3

如果SSL/TLS被正确使用，并且客户端凭据以保密和自助方式发出，那么采用MAC而不是Bearer令牌没有太多优势。这只会增加复杂性。客户端有责任保持client_secret的机密性。当然，有些客户端认为使用MAC可以提高安全性。

- Anderson Marques

---

我完全不同意你的观点。SSL/TLS并非百分之百安全，存在弱点，例如中间人攻击。如果用户决定继续操作，安全性将会受到影响。如果该安全机制失效，还有其他可靠的机制来保证身份验证的安全性。 - Daniel

使用正确的TLS（最新的TLS堆栈和拒绝不可验证的服务器证书），令牌并不比MAC更安全...而MAC有效地增加了更多复杂性...但是MAC不能被拦截（取决于您传输秘密的方式），因为只有客户端和服务器之间传输挑战...而不是秘密...这就像基本身份验证与摘要身份验证一样...另外，使用MAC可以将其存储在安全存储中（Android / iOS安全存储或PC上的TPM），并在不检索秘密的情况下进行挑战。 - Mathieu CARBONNEAUX

Answer 4

MAC令牌的实现比Bearer令牌复杂得多，这就是为什么Bearer令牌被广泛使用的原因。如果需要非常高的安全性或客户端和服务器之间需要进行HTTP通信，则使用MAC令牌。

MAC令牌是针对特定令牌发放的。它就像一张飞机票。只有票上写的名字才能使用该票。只有在客户端请求获取令牌时的第一步中才使用TLS协议。因为响应对象包括对称密钥，我们不希望中间人获得它。MAC令牌

{
    " access_token " : " HIAV43jkKG " ,
    " token_type " : " mac " ,
    " expires_in " : 3600 ,
    " refresh_token " : " 9xLPXBtZp " ,
    <!-- this is the symmetric key. we dont want man in the middle capture this.  -->
    " mac_key " : " yildij39jdlaska 9ud " ,
    " mac_algorithm " : " hmac - sha - 256 "
}

MAC令牌没有重放攻击保护。您必须自己实现。https://crypto.stackexchange.com/questions/77827/replay-attack-resistant-mac

在Bearer令牌实现中，客户端不需要显示其ID。就像电影票一样，拥有有效票证的人可以使用它，因为没有身份验证。这是Bearer令牌的缺点。Bearer令牌需要TLS，否则中间人实际上可以拿走令牌并使用该令牌。

- Yilmaz

Answer 5

使用Mac身份验证，您可以将Mac密钥存储在Android设备或tpm pc设备的安全存储中...这样，您无法检索密钥，但是可以从此存储中进行hmac挑战而不知道密钥...对于tls证书客户端，您必须将证书发送到服务器并可能被拦截（使用mitm）...

- Mathieu CARBONNEAUX

Answer 6

另一个角度：

假设客户端和资源服务器之间已经正确设置了TLS（现在几乎是普遍的），MAC令牌的剩余优势在于发送方被认证，而不是承载者。

然而，由于TLS将攻击面缩小到客户端，因此受损的客户端将使发送方身份验证优势无效。此外，愿意向第三方泄露访问令牌的客户端也很可能与该第三方共享从资源服务器获取的实际信息。

总结一下：TLS的普及已经将MAC令牌相对于承载者令牌的安全优势最小化，同时还必须考虑到实施MAC令牌比承载者令牌更加困难。

- Hans Z.

---

谢谢，从今天的角度来看是有道理的。我也转换到了Json Web Tokens... - Daniel