. yyyyy.zzzzz header（头信息）
由令牌类型“JWT”、散列算法“HMAC、RSASSA、RSASSA-PSS等”两部分组成。 以下是一个示例：
{ 'alg': 'HS256 '，' type': 'JWT'}然后此JSON编码为Base64Url，形成JWT的第一部分。
Payload（有效载荷）
JWT的第二部分是payload，其中包含claims。 claims是关于实体(最常用的是用户信息)和其他数据的声明，claims有注册、公共、和私有三种。
Registered claims这些是预定义的claims集，虽然不是强制性的，但推荐iss (发行者)、exp (发行者)、sub (辅助)、aud (观众) )等
请注意，Public claims:自定义claims不要与JWT注册表中的属性冲突。 在这里可以确认JWT注册表
Private claims:这些是定制的claims，用于在同意使用这些claims的各方之间共享信息。 它们既不是注册剪辑，也不是公共剪辑。
以下是payload的示例。
{ 'sub': '1234567890 '，' name': 'John Doe '，' admin': true}然后经过Base64Url代码，形成JWT的第二部分；
注意：对于签名令牌，此信息可以防止篡改，但任何人都可以读取。 除非加密，否则请勿将敏感信息放入Payload或Header元素中。
Signature
要创建签名部分，必须使用由编码的Header、编码的Payload、私钥和Header指定的算法并对其签名。
例如，如果使用HMAC SHA256算法，则签名创建如下：
hmac sha 256 (base64 urlencode (header ).' base64 urlencode (payload )，secret
)签名用于验证消息在此过程中未被篡改，并且，在使用私钥签名令牌的情况下，它还可以验证JWT的请求方是否是它所声明的请求方。
输出是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递，与SAML等基于XML的标准相比更加紧凑。
四、JWT工作机制？
在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web Token（即：JWT）。由于令牌是凭证，因此必须非常小心以防止出现安全问题。一般情况下，不应将令牌保留的时间超过要求。理论上超时时间越短越好。
每当用户想要访问受保护的路由或资源时，用户代理应该使用Bearer模式发送JWT，通常在Authorization header中。标题内容应如下所示：
Authorization: Bearer <token>在某些情况下，这可以作为无状态授权机制。服务器的受保护路由将检查Authorization header中的有效JWT ，如果有效，则允许用户访问受保护资源。如果JWT包含必要的数据，则可以减少查询数据库或缓存信息。
如果在Authorization header中发送令牌，则跨域资源共享（CORS）将不会成为问题，因为它不使用cookie。
注意：使用签名令牌，虽然他们无法更改，但是令牌中包含的所有信息都会向用户或其他方公开。这意味着不应该在令牌中放置敏感信息。
五、使用JWT的好处是什么？相比Simple Web Tokens (SWT)（简单Web令牌） and Security Assertion Markup Language Tokens (SAML)（安全断言标记语言令牌）；
JWT比SAML更简洁，在HTML和HTTP环境中传递更方便；
在安全方面，SWT只能使用HMAC算法通过共享密钥对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公钥/私钥对进行签名。与签名JSON的简单性相比，使用XML数字签名可能会存在安全漏洞；
JSON解析成对象相比XML更流行、方便。