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

Question

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

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

Microsoft Graph webhooks 在每个 webhook 调用的正文中发送一个明文“clientState”。接收方根据已知值验证 clientState。这类似于基本身份验证，因为每个请求都会通过网络发送明文凭据。

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

在上述所有示例中，凭证永不过期。此外，每个钩子只有一个“令牌”值，这意味着如果令牌遭到破坏，就无法优雅地轮换令牌。

我对 Basic Auth 的理解是，它通常被避免，因为它要求客户端以明文形式存储凭据，这是一个安全风险。

继续前进，Github 和 Box webhook 使用共享密钥和签名进行身份验证。

用于 webhook 的安全机制与其各自 API 使用的安全机制形成对比——它们都使用 OAuth 2.0 和 JWT 不记名令牌。

我还没有看到使用基于令牌的身份验证的 webhook 实现 - 例如，在 Authorization 标头中发送 JWT 不记名令牌的平台。

我的问题是：Webhook 实现倾向于使用基本身份验证等不太安全的机制的原因是什么？他们为什么不直接使用 OAuth 2.0 和 JWT，就像他们自己的 API 一样？

Answer 1

基于令牌的身份验证系统并不意味着将 JWT 作为令牌格式。

如果您选择 Slack 或 MS Graph 实现并使用 Bearer 方案将 clientState/token 从请求正文移动到 Authorization 标头，您将不会发现显着差异。 _{确实，标头将是传递旨在对请求进行身份验证的信息的最合适的方式，并且服务器可能以比请求正文更安全的方式处理标头......但为了讨论，我们忽略这一点.}

令牌将是by-reference token，其中实际值没有意义，有效性和任何相关信息由消费者从独立商店获得。在这种情况下，有效性的判断纯粹是通过确保令牌与您期望的值匹配并且没有存储与令牌相关联的其他信息，但这仍然是基于不记名令牌的身份验证系统，因为任何拥有令牌的人都可以提出请求。此外，令牌不是通过任何 OAuth 2.0 流程获得的，但对于此类场景来说，这将是多余的。

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

结论

您可能找不到使用功能齐全的 OAuth 2.0 和 JWT 作为令牌格式的 webhook 实现，因为这对于手头的用例来说太过分了。

---

更新：

JWT 的过期时间是您想要的，因为它将是按引用令牌（您称为简单令牌）的过期时间。

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

在您只想确保打电话的人是您信任的人而不是完全陌生的人的系统中，JWT 似乎有点过头了；这当然是我的看法。

关于简单令牌本身就是秘密，这取决于您所说的秘密的确切含义。如果 JWT 或不记名身份验证方案中使用的引用令牌被泄露，它们会给您完全相同的结果。拥有令牌的人可以在令牌有效时发出请求。如果您指的是用于签署 JWT 的密钥/密钥，而该密钥未通过网络传输，那么如果您使用的是按引用签名的令牌，这将是完全相同的。

再次，对您的基本问题的诚实回答是，考虑到系统的威胁模型，这些系统添加了他们认为值得的安全机制。就个人而言，我不反对不使用 OAuth 2.0 和 JWT，因为在那个用例中似乎完全不值得。我更喜欢使用 Github 方法。

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