我在这个主题中搜索了其他问题，但我发现这不是一个很好的答案。所以告诉我，如果我错了。 我是这个话题的新手，你可以高兴地纠正我。以下是我在实际时刻的想法：
我现在在网上冲浪了2天，弄清楚授权网络请求的实际状态是什么。现在我很快发现，OAuth 2.0似乎是最常见的标准。但OAuth 2.0本身就是标准化以外的一切。在我看来，对于每个更大的公司来说，这是一堆乱七八糟的不同定制。但无论如何，有两种技术可以交换授权信息：Mac-Tokens和Bearer-Tokens。
在我看来，Mac-Tokens提供更多安全性。那为什么没有广泛实施呢？我能找到的唯一原因是因为它有点复杂。我听过多次说不推荐使用Mac-Tokens，如果客户端不是100％可信的话，因为客户端必须存储秘密。但差异在哪里？无论如何，客户端必须存储Authorazation-Information。在我看来，无关紧要它是一个持有者令牌还是一个mac-secret。但产生差异的原因是，每次请求都不会通过网络提交mac-secret（而不是bearer-token ）。
那么你能告诉我一个理由，为什么不使用mac-tokens？ （除了更多的努力） 我错过了什么吗？或者我错过了两种令牌技巧。
感谢您的阅读和帮助。
答案 0 :(得分：2)
在我看来，答案可能很简单：承载令牌机制假定存在SSL / TLS层，而MAC令牌试图替换它。由于SSL / TLS被广泛接受和使用，为什么要做的事情比需要的更复杂？
是的，正如最近看到的那个脆弱的漏洞，很多事情并不像预期的那样可靠，但谁保证MAC实施也没有毛刺呢？
另一点是，正如你所提到的，交换对称秘密。在缺乏绝对可靠的二级通道的情况下，它可能很棘手。信任客户也可能是一个问题。
答案 1 :(得分：2)
危险在于，如果客户在没有坚持SSL / TLS证书有效的情况下继续进行 - 这是许多客户未能采取的步骤 - 那么持票人令牌容易受到中间人攻击的影响。
Mac令牌不容易受到这种攻击;在没有SSL / TLS的情况下，或者在没有正确使用时，Mac令牌可以提供一些真实性，这可能是正确的。
Mac令牌加强了承载令牌的已知弱点。
不应信任客户端使用共享的MAC密钥。应为每个客户端生成一个新密钥。使用自己的密钥信任每个客户端不再存在安全风险，而不是信任承载令牌。
我认为在为访问令牌交换Auhtorization Grant时会出现问题。对于Mac密钥，这将返回对称密钥。如果客户端在检查SSL / TLS证书方面很草率，那么这也很容易受到MITM攻击。
简而言之，Mac令牌可能不那么受欢迎，因为它更复杂，但您仍需要正确执行SSL / TLS以确保其安全，如果您这样做，那么承载令牌也将是安全的。
答案 2 :(得分：1)
如果正确使用SSL / TLS并且以机密和自助服务方式发出的客户端凭证采用MAC而不是承载令牌没有多少优势。只会增加复杂性。客户有责任维护client_secret的机密性。当然，有些客户更喜欢使用MAC思维来提高安全性。
答案 3 :(得分：0)
通过mac身份验证，您可以将macsecret存储在android设备或tpm pc设备中的安全存储中...这样，您就不愿意撤回该秘密，但是您可以在不知道的情况下从该存储中进行hmac挑战秘密...对于tls证书客户端，您必须将证书发送到服务方，并且可以被拦截（使用mitm）...