OAuth 2.0 Bearer-Tokens 与 Mac-Tokens。为什么不使用 Mac-Tokens？
OAuth 2.0 Bearer-Tokens vs. Mac-Tokens. Why not using Mac-Tokens?
我搜索了该主题中的其他问题，但我找不到确切的答案。所以告诉我，如果我错了。
我是这个话题的新手，您可以很高兴地纠正我。以下是我当时的想法：
现在我在网上冲浪了 2 天，弄清楚授权网络请求的实际技术水平是什么。现在我很快发现 OAuth 2.0 似乎是最常见的标准。但 OAuth 2.0 本身就是标准化之外的一切。在我看来，这是针对每家大公司的各种不同定制的混乱局面。但无论如何，有两种技术可以交换授权信息：Mac-Tokens 和 Bearer-Tokens。
在我看来 Mac-令牌提供了更多的安全性。那么为什么它没有广泛实施呢？我能找到的唯一原因是因为它有点复杂。我多次听说 Mac-Tokens 是不推荐的，如果客户端不是 100% 可信的，因为客户端必须存储秘密。但是区别在哪里呢？无论如何，客户端必须存储授权信息。在我看来，无论是不记名令牌还是 mac 秘密，都没有关系。但是 不同之处 是 mac-secret（而不是承载令牌）不是通过网络提交的每个请求。
所以你能告诉我为什么不使用 mac-tokens 的合理原因吗？ （除了付出更多的努力）
我错过了什么吗？还是我误解了这两种令牌技术。
感谢阅读和帮助。
在我看来，答案可能很简单：不记名令牌机制假设存在 SSL/TLS 层，而 MAC 令牌试图取代它。既然 SSL/TLS 被广泛接受和使用，为什么要做比需要的更复杂的事情？
是的，正如最近看到的 heartbleed 漏洞一样，很多事情并不像预期的那样可靠，但谁能保证 MAC 实施也没有故障？
另一点是，正如你提到的，对称秘密的交换。在没有绝对可靠的辅助渠道的情况下，这可能会很棘手。信任客户也可能是一个问题。
危险在于，如果客户端在不坚持 SSL/TLS 证书有效的情况下继续操作（这是许多客户端未能采取的步骤），那么不记名令牌很容易受到中间人攻击.
Mac 令牌不易受到此攻击；可以说 Mac 令牌在没有 SSL/TLS 的情况下提供了一些真实性，或者当它没有被正确使用时确实提供了一些真实性。
Mac 令牌加强了 Bearer 令牌的已知弱点。
不应使用共享的 MAC 密钥信任客户端。应该为每个客户端生成一个新密钥。使用自己的密钥信任每个客户端并不比使用不记名令牌信任它们更安全。
我认为问题出在将授权许可交换为访问令牌时。对于 Mac 密钥，此 returns 是一个对称密钥。如果客户端草率地检查 SSL/TLS 证书，那么这也很容易受到 MITM 攻击。
简而言之，Mac 令牌可能不太受欢迎，因为它更复杂，但您仍然需要做 SSL/TLS 正确以使其安全，如果您这样做，那么 Bearer 令牌也将是安全的。
如果 SSL/TLS 被正确使用并且客户端凭据以机密和 self-service 方式发出，那么采用 MAC 而不是 Bearer 令牌并没有太多优势。只会增加复杂性。维护 client_secret 机密性是客户的责任。当然，有些客户更喜欢使用 MAC 认为正在提高安全性。
通过 mac 身份验证，您可以将 mac 秘密存储在 Android 设备或 tpm pc 设备的安全存储中...这样您就无法检索秘密，但你可以在不知道秘密的情况下从这家商店发起 hmac 挑战...对于 tls 证书客户端，你必须将证书发送到服务器并且可以被拦截（使用 mitm）...
我搜索了该主题中的其他问题，但我找不到确切的答案。所以告诉我，如果我错了。 我是这个话题的新手，您可以很高兴地纠正我。以下是我当时的想法：
现在我在网上冲浪了 2 天，弄清楚授权网络请求的实际技术水平是什么。现在我很快发现 OAuth 2.0 似乎是最常见的标准。但 OAuth 2.0 本身就是标准化之外的一切。在我看来，这是针对每家大公司的各种不同定制的混乱局面。但无论如何，有两种技术可以交换授权信息：Mac-Tokens 和 Bearer-Tokens。
在我看来 Mac-令牌提供了更多的安全性。那么为什么它没有广泛实施呢？我能找到的唯一原因是因为它有点复杂。我多次听说 Mac-Tokens 是不推荐的，如果客户端不是 100% 可信的，因为客户端必须存储秘密。但是区别在哪里呢？无论如何，客户端必须存储授权信息。在我看来，无论是不记名令牌还是 mac 秘密，都没有关系。但是 不同之处 是 mac-secret（而不是承载令牌）不是通过网络提交的每个请求。
所以你能告诉我为什么不使用 mac-tokens 的合理原因吗？ （除了付出更多的努力） 我错过了什么吗？还是我误解了这两种令牌技术。
感谢阅读和帮助。
在我看来，答案可能很简单：不记名令牌机制假设存在 SSL/TLS 层，而 MAC 令牌试图取代它。既然 SSL/TLS 被广泛接受和使用，为什么要做比需要的更复杂的事情？
是的，正如最近看到的 heartbleed 漏洞一样，很多事情并不像预期的那样可靠，但谁能保证 MAC 实施也没有故障？
另一点是，正如你提到的，对称秘密的交换。在没有绝对可靠的辅助渠道的情况下，这可能会很棘手。信任客户也可能是一个问题。
危险在于，如果客户端在不坚持 SSL/TLS 证书有效的情况下继续操作（这是许多客户端未能采取的步骤），那么不记名令牌很容易受到中间人攻击.
Mac 令牌不易受到此攻击；可以说 Mac 令牌在没有 SSL/TLS 的情况下提供了一些真实性，或者当它没有被正确使用时确实提供了一些真实性。
Mac 令牌加强了 Bearer 令牌的已知弱点。
不应使用共享的 MAC 密钥信任客户端。应该为每个客户端生成一个新密钥。使用自己的密钥信任每个客户端并不比使用不记名令牌信任它们更安全。
我认为问题出在将授权许可交换为访问令牌时。对于 Mac 密钥，此 returns 是一个对称密钥。如果客户端草率地检查 SSL/TLS 证书，那么这也很容易受到 MITM 攻击。
简而言之，Mac 令牌可能不太受欢迎，因为它更复杂，但您仍然需要做 SSL/TLS 正确以使其安全，如果您这样做，那么 Bearer 令牌也将是安全的。
如果 SSL/TLS 被正确使用并且客户端凭据以机密和 self-service 方式发出，那么采用 MAC 而不是 Bearer 令牌并没有太多优势。只会增加复杂性。维护 client_secret 机密性是客户的责任。当然，有些客户更喜欢使用 MAC 认为正在提高安全性。
通过 mac 身份验证，您可以将 mac 秘密存储在 Android 设备或 tpm pc 设备的安全存储中...这样您就无法检索秘密，但你可以在不知道秘密的情况下从这家商店发起 hmac 挑战...对于 tls 证书客户端，你必须将证书发送到服务器并且可以被拦截（使用 mitm）...