为什么以及何时应该使用 JSON Web Tokens？

Question

我认为 jwt.io 并没有很好地解释为什么或何时使用 jwt。它解释了其他可以考虑但对于决定是否使用它或为什么它会派上用场并不重要的事情。

我为什么要使用 JSON Web Tokens 的想法？

身份验证： 将会话存储在服务之外是很有用的，并且可以从无状态专家（例如：升级）中受益。

因此，JWT 可以方便地不实施远程会话解决方案，该解决方案将需要例如 memcached 基础设施、令牌管理器软件模块来创建、更新、使令牌无效。但它会有一个缺点，就是会话信息会在客户端中暴露出来。

信息交换：分享您的秘密（或公钥）以允许发送者签署令牌。 为什么不为此使用 https 或证书？

所以我的问题是：我的假设是否正确？我对何时需要使用 jwt 以及与当前/实际解决方案相比的好处感到困惑。

---

来自https://jwt.io/introduction/的其他信息

什么时候应该使用 JSON 网络令牌？

身份验证：这是使用 JWT 最常见的场景。用户登录后，每个后续请求都将包含 JWT，从而允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小并且能够轻松跨不同域使用。

信息交换：JSON Web 令牌是在各方之间安全传输信息的好方法。因为可以对 JWT 进行签名（例如，使用公钥/私钥对），所以您可以确定发件人就是他们所说的那个人。此外，由于使用标头和有效负载计算签名，您还可以验证内容没有被篡改。

JSON Web 令牌如何工作？

Jtw-Diagram（某种序列图）

我们为什么要使用 JSON 网络令牌？

让我们谈谈 JSON Web 令牌 (JWT) 与简单 Web 令牌 (SWT) 和安全断言标记语言令牌 (SAML) 相比的优势。

由于 JSON 不像 XML 那样冗长，因此在编码时它的大小也更小，这使得 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的不错选择。 ** 不是 jwt 本身属性，它是 json 属性**

在安全方面，SWT 只能通过使用 HMAC 算法的共享密钥进行对称签名。但是，JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名。与签署 JSON 的简单性相比，使用 XML 数字签名签署 XML 而不引入晦涩的安全漏洞是非常困难的。 ** 公钥/私钥对签名不是新的 **

JSON 解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML 没有自然的文档到对象映射。这使得使用 JWT 比使用 SAML 断言更容易。

关于使用，JWT 用于 Internet 规模。这突出了在多个平台（尤其是移动平台）上客户端处理 JSON Web 令牌的便利性。 **不要解释为什么它在互联网规模上使用（我认为是因为无状态服务器**

Answer 1

所以我的问题是：我的假设是否正确？我对何时需要使用 jwt 以及与当前/实际解决方案相比的好处感到困惑

您已经了解了宣传和营销，现在让我们花点时间了解一下 JWT 解决了哪些问题。

JWT 不是什么

当您verify 一个令牌时，您已经检查过该令牌的格式是否正确仅，您没有证明出示该令牌的一方具有任何授权，因此 JWT 本身不能证明Authz，它证明了身份验证了自己并被验证为他们当时声称的身份 - 并且生成 JWT 以表示验证身份在验证时所具有的声明。这些是声明，因此当 JWT 出现并且您检查它是否格式正确（通过进行验证检查）时，属性就像说的那样；

我声称我有这些授权，请授权我

即您必须确保这些声明有效！

有一些与 authz 无关的默认声明，但它们可以告诉您声明的 authz 在授权后应该信任多长时间 nbf 并且他们可以告诉您 authz 声明在用于特定目的时适用 @ 987654323@ 和自定义声明是您可以为 authz 添加应用程序特定逻辑的地方，以帮助您检查权限，例如用户的组名。

一个 JWT 是

我们的目标是有一种方法可以信任确保身份和授权的系统（C 方），以及要求这些身份和授权值得信赖的一方（最终用户 A 方），以便他们可以应用程序中的 ACL 或 Authz 决策（B 方）。

JWT 由 C 方在验证 A 方真实性时生成。 C 方是 Okta、Auth0、JumpCloud、Azure、GCP、Amazon (Cognito) 等公司。如果您发布 JWT，您通常与 JWT 的用户不是同一个组织。

如果您是应用程序开发人员，并且您需要一个系统来提供 Authz 和 ACL，那么您必须有一个良好的可信身份基础，并且您知道并且信任已经完成了适当的 Authn 检查，这就是设计 JWT 的原因。

因此，作为应用程序开发人员，您几乎不需要生成 JWT，他们唯一要做的就是如果您的软件提供了您已检查身份验证质询响应的第 3 方身份证明，并且您向第 3 方保证使用您生成的 JWT 的聚会。这方面的一个示例是 OIDC，其中身份提供者是生成 JWT 的 OIDC 生产者，您的应用程序和您的用户使用 OIDC 协议并传递 JWT 以表示最终用户的身份和授权。

因此，当您获得任何 JWT 时，您首先要确保它格式正确，然后在验证它是有效结构后，您读取 JWT 中的声明并应用应用程序逻辑来处理声明，例如添加您的自己的 authz 和 ACL 逻辑。因为 Authz 永远不能外包，所以业务逻辑总是 100% 写入您的应用程序中，并且每次您假设 authz 是通过不是您自己的代码的其他方式执行时，您实际上是在假设 信任不假设authz

除非你写了 100% 的 authz 逻辑，否则你实际上只有 0% 的 authz

所以 JWT 的使用是上下文相关的

您是智威汤逊的生产者吗？因此，您生成 JWT 的目的是确保您执行了 Authn，并向 JWT 的消费者保证身份是真实的

您是智威汤逊消费者吗？然后，您必须检查 JWT 的格式是否正确，以便可以使用声明，然后您必须将声明视为 声明，并确保它们已针对声明在您的应用中使用的用例进行了验证，如果您不检查声明，则表示您对提交 JWT 的请求者具有内在的信任。

如果您按原样处理声明并且不确定它们是否值得信赖，则请求者可以完全控制应用程序的操作，因为应用程序会盲目信任，如果您说您拥有权限，因为它在 JWT 中，那么应用程序将相信您被允许。

事实是，公钥创建了 RSA/ECDSA 签名的 JWT 的签名，即公钥！所以verify 证明它在使用 公钥 签名时格式正确...

您仍然信任 JWT 验证方法吗？