我们为什么以及何时应该使用JSON Web令牌？

Question

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

我想为什么要使用JSON Web令牌？

身份验证: 将会话存储在服务之外并从无状态专业人员中获益(例如:升级)非常有用.

因此,JWT将不会实现远程会话解决方案,这将需要例如memcached基础架构,令牌管理器软件模块来创建,更新,使令牌无效.但它的缺点是会话信息将在客户端中暴露出来.

信息交换:共享您的秘密(或公钥),以便允许发件人签署令牌.为什么不使用https这个或证书？

所以我的问题是:我的假设是否正确？我很困惑何时需要使用jwt以及当前/实际解决方案的优势.

---

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

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

身份验证:这是使用JWT的最常见方案.一旦用户登录,每个后续请求将包括JWT,允许用户访问该令牌允许的路由,服务和资源.Single Sign On是一种现在广泛使用JWT的功能,因为它的开销很小,并且能够在不同的域中轻松使用.

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

JSON Web令牌如何工作？

Jtw-Diagram(某种序列图)

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

让我们来谈谈JSON Web Tokens(JWT)与Simple Web Tokens(SWT)和Security Assertion Markup Language Tokens(SAML)相比的好处.

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

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

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

关于使用,JWT用于互联网规模.这突出了在多个平台(尤其是移动平台)上轻松进行JSON Web令牌的客户端处理.**不解释为何在互联网上使用它(在我看来是因为无状态服务器**

Answer 1

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

您已经介绍了宣传和营销，现在让我们花点时间了解智威汤逊解决了什么问题。

JWT 不是什么

当您使用令牌时，您仅verify检查了令牌的格式是否正确，您没有证明提供令牌的一方具有任何授权，因此 JWT 本身并不是 Authz 的证明，而是身份经过自身验证并经过验证的证明成为他们当时声称的身份 - 并且 JWT 的生成是为了代表经过验证的身份在验证时所具有的声明。这些是声明，因此，当 JWT 出现并且您检查其格式是否良好（通过进行验证检查）时，属性就像在说；

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

也就是说，您必须确保这些声明有效！

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

JWT 是

目标是有一种方法可以让系统（丙方）信任确保身份和授权的系统，并信任需要这些身份和授权的一方（最终用户甲方），以便他们可以进行 ACL 或 Authz在他们的应用程序中做出决定（乙方）。

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

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

因此，作为应用程序开发人员，您几乎不需要生成 JWT，只有在您的软件提供第三方身份证明（您已经检查了身份验证质询响应）并且您使用以下方式向第三方保证时，您才需要生成 JWT：您生成的 JWT。OIDC 就是一个例子，其中身份提供者是生成 JWT 的 OIDC 生产者，您的应用程序和用户使用 OIDC 协议并传递 JWT 来表示最终用户的身份和授权。

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

你实际上拥有 0% authz 除非你编写了 100% 的 authz 逻辑

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

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

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

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

事实上，公钥创建了 RSA/ECDSA 签名的 JWT 的签名，即公钥！所以证明当它用公钥verify签名时它是格式良好的......

您还信任 JWT 验证方法吗？