JWT认为，许多朋友知道JSON Web令牌，如果您通过项目中的JJWT支持JWT，您可能只需要了解JWT的概念，但是现在很多次我们可能不会使用JJWT，但是选择Nimbus-Jose-Jwt库，目前可能会暴露于JWE和JWS等一些新概念。那么JWE，JWS和JWT之间有什么关系？
最近，我看到了一篇很好的文章。让我们一起看看。以下是文本。
什么是JWT，JWT，应采用以下形式：
这些东西看起来很混乱，但非常紧凑，并被打印以验证签名的真实性。
JWT解决了什么问题？JWT的主要目的是以服务器和客户端之间的安全方式传输语句。主要的应用程序方案如下：
JWT的一些名词解释了JWT的组成。通常，您会看到JWT，由以下三个部分组成。他们是：
三个部分用于分裂。这就像xxxxx.yyyy.zzzzzz的样式。
JWT标题
JWT标头组成
头部通常由两个部分组成：令牌的类型，即JWT和所使用的宽敞算法，例如HMAC SHA256或RSA。
当然，有两个选项，一个是JTI，即JWT ID，代表JWT号码的使用。该数字应该在相应的服务器上是唯一的。当然，JTI也可以放置在有效载荷中。
另一个是CTY，是内容类型。这是相对罕见的。当有效载荷是任意数据时，无需设置此头部，但是当内容也具有JWT。即当嵌套JWT时，必须将此值设置为JWT。这种情况相对较少。
JWT标头的加密算法
加密方法如下：
JWT有效载荷
JWT有效载荷的组成通常由三个部分组成，是注册索赔；公共蛤;私人主张；每个语句都有自己的字段。
注册索赔
可以根据需要使用JWT的那些标准化组织来定义公众索赔，并应参考文档IANA JSON Web令牌注册表。
私人索赔是由同意他们的共享信息创建的定制声明。他们既不是注册声明也不是公开声明。在上述有效载荷中，没有公开索赔，只有私人索赔。
JWT有效加密算法
加密方法如下：
暴露的信息
因此，在JWT中，不应将任何敏感数据添加到负载中。在上面的示例中，我们传输了用户的用户ID，邮箱等。该值实际上不是敏感内容，并且通常知道它也是安全。但是像密码之类的内容不能放置在JWT中。如果用户的密码放在JWT中，那么恶意的第三方可以通过Base64解码快速了解您的密码。
当然，这也是一个解决方案，即加密有效载荷。它将在后面提及。
JWS的概念是JWS，它是JWT签名。该结构基于以前的非外观JWT，声明头部上的签名算法，并在末尾添加签名。签名的创建是为了确保不能随意篡改JWT。
为了完成签名，除了使用标头信息和有效载荷信息外，算法的键，即秘密。使用非对称加密方法时，秘密是私钥。
为了促进后来的文章的扩展，我们将JSSON Web密钥（即JWK）统一转介给JWT密钥或密钥。
JWT Signatur的签名算法
到目前为止，JWT中有三种签名算法。
最后，签名用于与前两个内容连接。您可以获得签名JWT，即JWS。
在验证签名时，请使用公共密钥或密钥进行解密符号，以及base64urlencode（header） +“”的内容。+ base64urlencode（有效负载）完全相同，指示验证通过。
如果有一些CA.在确保服务器的可靠性和有效性的概念中，将更好地理解JWS的其他头部声明，对于第三部分CA代理商可以签署JWT而不是该机器服务器以签名JWT，则也很方便。对于JWS的头部，可以使用JWS。如下：
多验证和JWS序列化需要多个签名或JOSE头与JW混合，并且经常需要使用JW的序列化。JWS的序列化结构如下：
结构很容易理解。首先是有效负载字段。这不是必需的，然后是代表多个签名的数组的签名字段。每个签名的结构如下：
JWE相关的JWE概念是一个非常新的概念。简而言之，除了JWT的官方手册外，很少有网站或博客会介绍此内容。库鲁并不支持JWE。在查看官方手册后，您了解的是您所理解的。
JWS将验证数据，JWE（JSON Web加密）可以通过保护第三方的数据来看到。通过JWE，JWT变得更安全。
JWE和JWS的公共密钥解决方案不同。在JWS中，私有密钥持有人加密令牌，公共密钥持有人验证了token.in jwe，私钥应该是唯一可以解密令牌的方面。
在JWE中，公共钥匙持有可以将新数据放入JWT，但是在JWS中，公共密钥持有人只能验证数据并不能引入新数据。因此，对于公共密钥/私钥方案，JWS和JWE是互补的。
JWE的组成是JWE，应采用以下形式：
如您所见，总共有五个部分，有五个部分，其中：
一般而言，JWE的加密算法需要加密密钥，这意味着在同一JWT中至少有两个加密算法扮演角色。但是，不可能使用键。在需要加密密钥之后，我们使用JWK密钥管理模式导出这些密钥。JWK的管理模型具有以下五种类型，即：
并非所有JWA都能支持这五个关键管理模式，而不是每个密钥管理模式都可以相互转换。您可以参考SPMKY-LABS/JOSE中给出的表：
https://github.com/spomky-labs/jose/blob/master/doc/encrypt.md
至于每种密钥管理模式的详细信息，请参见JWT的官方手册，这更复杂。
JWE标头就像JWS的头。JWE的头还有自己的其他声明字段，如下所示：
JWE的加密过程步骤2和步骤3，更多不同的关键管理模式应具有不同的处理方式。这里有一些常见的情况。
如前所述，jwe.let在详细介绍加密过程中有五个部分：
多重验证类似于JWE序列化和JWS。JWE还定义了紧凑的序列化格式以完成多种形式的加密。一般格式如下：
该结构易于理解，如下所示：
JWT的工作原理在这里JWT如何通过Juice Shop.IN身份验证，当用户成功登录他的凭据时，他将返回JSON Web Token。。
每当用户想要访问受保护的路由或资源时，用户通常会在授权标题中使用[BEARER]模式发送JWT。标题的内容应如下：
随后，服务器将取出令牌中的内容返回相应的内容。应注意，该令牌可能不会存储在cookie中。如果有一个cookie，则需要设置为仅HTTP，以防止XSS。此外，您还可以将其放置在其他地方，例如LocalStorage，SessionStorage。如果您使用VUE，则也可以在VUEX中存在。
此外，如果您在授权中发送令牌：携带者，交叉域资源共享（CORS）不会成为问题，因为它不使用cookie。
此时，转到“身份验证”页面，请求标题如下所示。如预期的那样，授权的请求标题：持有人可以访问。
ECDSA |rsassa还是HMAC？我应该选择哪一个？当我以前见过JWT时，我在论坛上看到了一个话题，我感到非常有趣。让我们利用自己的理解：
https://stackoverflow.com/questions/38588319/understanding-sa-signing-for-jwt。
首先，我们必须清楚地表明，无论HMAC，RSASSA，ECDSA如何；钥匙，公共钥匙，私钥不会被发送到服务器上的客户端。
对称算法HMAC适用于单点登录，一个-to -One Scenes.high速度。
但是，面对一个大对，例如应用程序中的不同服务模块，当需要JWT登录时，主服务器[App]具有一个私钥来完成签名，并且用户将JWT访问不同的服务模块使用不同的服务模块。[sub -server sine]在辅助服务器时，辅助服务器只需要使用公共密钥验证签名。在一定程度上，主服务器的压力也减少了。
当然，还有另一种情况是，当开发不同的成员时，您可以使用统一的私钥来完成签名，然后使用自己的公共钥匙来完成JWT的认证，这也是一种很好的开发方法。
因此，构建一个没有多个“微服务应用程序”的应用程序，只有一组开发人员。选择HMAC进行签名。在其他情况下，尝试选择RSA。
作者：Ninthdevilhunster
资料来源：https：//www.freebuf.com/articles/web/180874.html