JSON Web Token 简介

1. 跨域认证的问题
一般流程
用户向服务器发送用户名和密码 。服务器验证通过后 , 在当前对话()里面保存相关数据 , 比如用户角色、登录时间等等 。服务器向用户返回一个  , 写入用户的。用户随后的每一次请求 , 都会通过  , 将传回服务器 。服务器收到  , 找到前期保存的数据 , 由此得知用户的身份 。
问题:扩展性()不好 。单机没有问题 , 如果是服务器集群 , 或者是跨域的服务导向架构 , 就要求数据共享 , 每台服务器都能够读取 (例如 , A 网站和 B 网站是同一家公司的关联服务 。现在要求 , 用户只要在其中一个网站登录 , 再访问另一个网站就会自动登录 , 请问怎么实现?)
解决方案1: 数据持久化 , 写入数据库或别的持久层 。各种服务收到请求后 , 都向持久层请求数据 。这种方案的优点是架构清晰 , 缺点是工程量比较大 。另外 , 持久层万一挂了 , 就会单点失败
【JSON Web Token 简介】解决方案2:服务器不保存数据 , 所有数据都保存在客户端 , 每次请求都发回服务器 , 也就是 Token
2. Token 工作流程 登陆时 , 客户端发送用户名密码服务端验证用户名密码是否正确 , 校验通过就会生成一个有时效的 token , 发送给客户端客户端储存 token , 一般都会存储在或者里面客户端每次请求时都带有 token , 可以将其放在请求头里 , 每次请求都携带 token服务端验证 token , 所有需要校验身份的接口都会被校验 token , 若 token 解析后的数据包含用户身份信息 , 则身份验证通过 , 返回数据
客户端获取到 token 后 , 可以存储在  , 也可以存储在
此后 , 客户端每次与服务器通信 , 都要带上这个 JWT 。你可以把它放在里面自动发送 , 但是这样不能跨域 , 所以更好的做法是放在 HTTP 请求的头信息字段里面 。
Authorization: Bearer
另一种做法是 , 跨域的时候 , JWT 就放在 POST 请求的数据体里面 。
3. (JWT)
官方手册
3.1 JWT 生成的 Token 格式
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjoiNWM5Yzk2NGUyMjE3YzIzM2I1ZjQ0YWVmIiwiZXhwIjoxNTU1MTM1OTc3LCJpYXQiOjE1NTQ4NzY3Nzd9.osPAb7eywjEAs4qfRobC5fstM5eHAxgTYGV7Q0W8YOt8dxv2VP2S8Y7q3eW66AViDHRrFgFIlRunighlrmC9XtUTnotXCTuWEg288Bx_RjP_pAuj0eQiiWEeFvYeUZX8OR51x2JB1AUGXbLv5853HFYdiluoJIe8ADGneYRaLIfCegTSoq7RtDumfn8U11e8WBIhDjYobGFaFqNBzYaW0fA52oQglJjq5vr8RoVcVgA9LufE4CEA5yB24b0xln9Wf6ul7ZKSQDciNKDJr_QKKj5isFGZU3NMM7u3DEG7EeAtIhUzLbQJ1hSUNymc7WwqF7L1QjaiDkOlGlbVg
生成的 Token 是一个很长的字符串 , 由 . 分割为三段(此处为了方便展示分段展示 , 实际是一行的)
这三段字符串其实原本都是 JSON 对象 , 然后通过算法生成的 , 接下来来简单介绍这三段的含义
3.1.1 (头部)
存储 JWT 的元数据 , 与生成 Token API jwt.sign(, , [, ])中的对应
3.1.2 (负载数据)
存放需要实际传递的数据 , 官方定义了7个官方字段
此外 , 可以定义一些自定义的字段 , 方便存储数据
3.1.3 (签名)
是对前两部分的签名 , 防止数据篡改
首先 , 需要指定一个密钥() 。这个密钥只有服务器才知道 , 不能泄露给用户 。然后 , 使用里面指定的签名算法(默认是 HMAC ) , 按照下面的公式产生签名 。