为什么webhook实现会避免基于令牌的安全性？

Question

在研究了各种webhook实现之后，我注意到它们使用的安全机制有一种趋势。

Visual Studio Team Services Webhook使用基本身份验证。

微软图形网络钩子在每个网络钩子调用的正文中发送一个明文“clientState”。接收器根据已知值验证clientState。这与基本身份验证类似，因为每个请求都通过线路发送明文凭据。

Slack outgoing Webhook使用了一种与Microsoft Graph非常相似的技术：在每个请求的主体中发送一个明文“令牌”。接收方根据已知值验证令牌。同样，与基本身份验证非常相似：每次请求都会通过网络发送明文凭证。

在上述所有示例中，凭据永远不会过期。此外，每个钩子只有一个“令牌”值，这意味着如果令牌受损，就无法优雅地旋转它。

我对基本身份验证的理解是，通常避免使用它，因为它要求客户端以明文形式存储凭据，这是一种安全风险。

接下来，Github和Box网络钩子使用共享的秘密和签名进行身份验证。

网络钩子使用的安全机制与其各自的应用编程接口使用的安全机制形成对比——它们都使用OAuth 2.0和JWT承载令牌。

我还没有看到使用基于令牌的身份验证的webhook实现——例如，在授权头中发送JWT承载令牌的平台。

我的问题是：webhook实现趋向于基本身份验证等不太安全的机制的原因是什么？他们为什么不像自己的API那样使用OAuth 2.0和JWT呢？

Answer 1

基于令牌的认证系统并不意味着JWT是令牌格式。

如果选择Slack或MS Graph实现，并使用承载方案将clientState/令牌从请求主体移动到授权头，则不会发现显著差异_{的确，报头将是传递用于验证请求的信息的最合适的方式，服务器可能会以比请求体更安全的方式处理报头。。。但是，为了讨论这个问题，我们可以忽略这一点}

令牌将是一个引用令牌，其中实际值是无意义的，有效性和任何相关信息是由消费者从独立存储中获得的。在这种情况下，有效性的判断纯粹是通过确保令牌符合您期望的值，并且没有与令牌关联存储的额外信息，但这仍然是一个基于无记名令牌的身份验证系统，在这个意义上，任何拥有令牌的人都可以请求。此外，令牌不是通过任何OAuth 2.0流获得的，但对于像这样的场景来说，这将是过度的。

Github实现将被归类为对纯承载实现的改进，因为没有令牌在线路上移动，只有有效负载的签名，这意味着能够解密通信通道的攻击者只能重放捕获的请求，而不能发出具有不同有效负载的请求。

您可能找不到使用功能齐全的OAuth 2.0 plus JWT作为令牌格式的webhooks实现，因为这对于手头的用例来说是一种过分的杀伤力。

更新：

JWT的到期时间是您希望它是什么样子的，就像它是引用令牌（您称之为简单令牌）的到期时间一样。

我试图传递的信息是，您不需要JWT或OAuth来拥有基于令牌的身份验证系统。基于令牌的系统的安全特性可以独立于所使用的令牌格式来设计；是的，有些格式会简化某些方面，同时可能会使其他方面更加复杂。这总是一个权衡...

在这样一个系统中，你只想确保打电话的人是你信任的人，而不仅仅是一个完全陌生的人，JWT似乎有些过分；这当然是我的观点。

简单的标记本身就是秘密，这取决于你所说的秘密的确切含义。承载身份验证方案中使用的JWT或by引用令牌如果泄露，会给出完全相同的结果。任何拥有令牌的人都可以在令牌有效时发出请求。如果您指的是用于对JWT进行签名的密钥/密钥，而JWT不是通过有线传输的，那么如果您使用的是通过引用进行签名的令牌，这也是完全相同的。

同样，对你潜在问题的诚实回答是，考虑到系统的威胁模型，这些系统添加了他们认为值得的安全机制。就个人而言，我并不反对不使用OAuth 2.0 plus JWT，因为在那个用例中它似乎完全不值得。我倾向于使用Github方法。

您可能不喜欢它们提供的安全特性，但MS Graph和Slack方法都是使用承载令牌的基于令牌的系统。