JSON令牌(JWT)是一个非常轻量级的规范。该规范允许我们使用JWT在用户和服务器之间传输安全可靠的信息。
让我们想象一个场景。当用户A关注用户B时，系统向用户B发送一封邮件，邮件中有一个链接“点击此处关注用户A”。链接的地址可以是这样的
https://your.app.com/make-friend/?From_user=Btarget_user=A上面的URL主要是用来描述这个的。当然这样做有一个弊端，就是要问用户B，用户必须先登录。能不能简化这个过程，让用户B不用登录就能完成这个操作？JWT允许我们这样做。
JWT的组成
JWT实际上是一个字符串，由三部分组成：报头、有效载荷和签名。
{ 'iss': '吴炯JWT '，' iat': 1441593502，' exp': 1441594722，' aud': 'www.example.com，' sub': 'kevin@example.com，' From _ user' 3360' b '，' target _ user' 3360' a'}前五个字段由JWT标准定义。
Iss:此JWT sub:用户aud:此JWT指向谁接收此JWT的party EXP (Expires) 3360何时到期？这里有一个Unix时间戳IAT(发布于)3360。这些定义可以在标准中找到。
通过运行上面的JSON对象，可以得到下面的字符串。这根弦被称为JWT的Payload(有效载荷)。
eyjpc 3 mioijkb 2 hui FD 1 epxvcisimlhdci 6 mtq 0 MTU 5 mzuwmiwizxhwijoxndqxntk 0 ziylc jhwqioij 3d 3 cuzxhbxbsz S5 JB 20 ilcjzdwiioijqcm 9 ja 2v 0 qgv 4 yw 1 wbguuy 29 tiiwiznjvbv 9 1c vyijoiiqiisinrhcmld f 91c 2 vyijoiqsj 9注：base64是一种代码，可以翻译回原来的形式。这不是一个加密过程。
头部（Header）
JWT还需要一个报头，用于描述关于JWT的最基本的信息，比如它的类型和用于签名的算法。这也可以表示为一个JSON对象。
{'typ' 3360' JWT '，' alg' 3360' HS256'}这里说明一下，这是一个JWT，我们使用的签名算法(后面会提到)是HS256算法。
它也需要进行Base64编码，然后字符串就变成了JWT的Header（头部）。
签名（签名）
用一个句号(头先)把上面两个编码字符串连在一起，就形成了。
ey 0 exaiijkv 1 qilcjbgcioijuzi 1 nij 9。eyjmcm 9 tx 3 vzzxioijciiwidgfyz 2v0x 3 vzzxioijbin 0最后，我们用HS256算法($algo)对上面拼接的字符串($input)进行加密。加密时，我们还需要提供一个密钥($secret)。例如，如果我们使用字符串mySecret作为密钥，我们可以通过下面的方法将加密的内容作为JWT的签名：
hash_hmac($algo，$input，$ secret)；//output 3360 rswamyaywuhco 7 if AGD 1 ORPsp 7 nzl 7 BF 5t 7 itqpkvim最后，我们将这部分签名拼接在带符号的字符串之后，得到了完整的JWT:
ey 0 exaiijkv 1 qilcjbgcioijuzi 1 nij 9。eyjmcm 9 tx 3 vzzxioijciwidgfyz 2v0x 3 vzzxioijbin 0。RSWAMYAYWUHCO 7IF AGD1或PSP7NZL7BF5T7ITQPKVIM因此，我们可以将邮件中的URL更改为
这样，https://your.app.com/make-fri.服务器验证JWT的签名无误后，就可以完成B用户添加A用户为好友的操作，而不需要用户重新登录。
看到这里你应该有两个疑问。
签名的目的是什么？Base64是一种编码，可逆，所以我的信息不暴露？
签名的目的
签名过程的最后一步实际上是对报头和有效载荷内容进行签名。一般来说，加密算法总是对不同的输入产生不同的输出。对于两种不同的输入，产生相同输出的概率极小。
因此，如果有人对报头和有效载荷的内容进行解码，然后对其进行修改和编码，那么新的报头和有效载荷的签名将与之前的不同。而且，如果不知道服务器加密用的密钥，得到的签名肯定会不一样。
一旦接收到JWT，服务器应用程序，
会首先对头部和载荷的内容用同一算法再次签名。那么服务器应用是怎么知道我们用的是哪一种算法呢？别忘了，我们在JWT的头部中已经用alg字段指明了我们的加密算法了。如果服务器应用对头部和载荷再次以同样方法签名之后发现，自己计算出来的签名和接受到的签名不一样，那么就说明这个Token的内容被别人动过的，我们应该拒绝这个Token，返回一个HTTP 401 Unauthorized响应。
关于两个签名的推荐用PHP中内建函数hash_equals来帮我们完成
hash_equals ( string $known_string , string $user_string ) : bool比较两个字符串，无论它们是否相等，本函数的时间消耗是恒定的。本函数可以用在需要防止时序攻击的字符串比较场景中， 例如，可以用在比较 crypt() 密码哈希值的场景。信息会暴露
JWT荷载和头部中的信息都可以通过base64解码拿到，所以在JWT中，不应该在载荷里面加入任何敏感的数据。在上面的例子中，我们传输的是用户的User ID。这个值实际上不是什么敏感内容，一般情况下被知道也是安全的。像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中，那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。
JWT的适用场景
我们可以看到，JWT适合用于向Web应用传递一些非敏感信息。例如在上面提到的完成加好友的操作，还有就是JWT还经常用于设计用户认证和授权系统，尤其是现在前后端分离开发架构下，用户登录成功后将携带着用户标示和登录时间、站点等信息的JWT给到前端，前端在API请求的HEADER头中携带JWT，服务端验证完JWT的合法性后就能通过用户标示找到本次API请求所属的用户。
