jwt 认证登录流程
JWT 全称是 JSON Web Token，是目前非常流行的跨域认证解决方案，在单点登录场景中经常使用到。
有些人觉得它非常好用，用了它之后就不用在服务端借助 redis 实现认证过程了，但是，还有一部分人认为它生来就有缺陷，根本不能用。
这是为什么呢？
传统的认证方式
从一个登录场景说起
你平时用过那么多网站和 APP，其中有很多都是需要登录的吧，那咱们就选一个场景出来说说。
以一个电商系统为例，如果你想要下单，首先需要注册一个账号，拥有了账号之后，需要输入用户名（比如手机号或邮箱）、密码完成登录过程。之后你在一段时间内再次进入系统，是不需要输入用户名和密码的，只有在连续长时间不登录的情况下（例如一个月没登录过）访问系统，才需要再次输入用户名和密码。
对于那些使用频率很高的网站或应用，通常是很长时间都不需要输入密码的，以至于你在换了一台电脑或者一部手机之后，一些经常使用的网站或 APP 的密码都不记得了。
早期的 Cookie-Session 认证方式
早期互联网以 web 为主，客户端是浏览器 ，所以 Cookie-Session 方式是早期最常用的认证方式，直到现在，一些 web 网站依然用这种方式做认证。
认证过程大致如下：
- 用户输入用户名、密码或者用短信验证码方式登录系统；
- 服务端验证后，创建一个 Session 信息，并且将 SessionID 存到 cookie，发送回浏览器；
- 下次客户端再发起请求，自动带上 cookie 信息，服务端通过 cookie 获取 Session 信息进行校验；
但是为什么说它是传统的认证方式，因为现在人手一部智能手机，很多人都不用电脑，平时都是使用手机上的各种 APP，比如淘宝、拼多多等。
在这种潮流之下，传统的 Cookie-Session 就遇到了一些问题：
1、首先，Cookie-Session 只能在 web 场景下使用，如果是 APP 呢，APP 可没有地方存 cookie。
现在的产品基本上都同时提供 web 端和 APP 两种使用方式，有点产品甚至只有 APP。
2、退一万步说，你做的产品只支持 web，也要考虑跨域问题， 但Cookie 是不能跨域的。
拿天猫商城来说，当你进入天猫商城后，会看到顶部有天猫超市、天猫国际、天猫会员这些菜单。而点击这些菜单都会进入不同的域名，不同的域名下的 cookie 都是不一样的，你在 A 域名下是没办法拿到 B 域名的 cookie 的，即使是子域也不行。
3、如果是分布式服务，需要考虑 Session 同步问题。
现在的互联网网站和 APP 基本上都是分布式部署，也就是服务端不止一台机器。当某个用户在页面上进行登录操作后，这个登录动作必定是请求到了其中某一台服务器上。你的身份信息得保存下来吧，传统方式就是存 Session。
接下来，问题来了。你访问了几个页面，这时，有个请求经过负载均衡，路由到了另外一台服务器（不是你登录的那台）。当后台接到请求后，要检查用户身份信息和权限，于是接口开始从从 Session 中获取用户信息。但是，这台服务器不是当时登录的那台，并没存你的 Session ，这样后台服务就认为你是一个非登录的用户，也就不能给你返回数据了。
所以，为了避免这种情况的发生，就要做 Session 同步。一台服务器接收到登录请求后，在当前服务器保存 Session 后，也要向其他几个服务器同步。
4、cookie 存在 CSRF（跨站请求伪造）的风险。 跨站请求伪造，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。CSRF 利用的是网站对用户网页浏览器的信任。简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（比如购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户发起的操作。
比如说我是一个黑客，我发现你经常访问的一个技术网站存在 CSRF 漏洞。发布文章支持 html 格式，进而我在 html 中加入一些危险内容，例如
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
假设 src 指向的地址是一个你平时用的购物网站的付款地址（当然只是举例，真正的攻击可没这么简单），如果你之前登录过并且标识你身份信息的 cookie 已经保存下来了。当你刷到我发布的这篇文章的时候，img 标签一加载，这个 CSRF 攻击就会起作用，在你不知情的情况下向这个网站付款了。
Cookie-Session 改造版
由于传统的 Cookie-Session 认证存在诸多问题，那可以把上面的方案改造一下。
1、改造 Cookie 既然 Cookie 不能在 APP 等非浏览器中使用，那就不用 cookie 做客户端存储，改用其他方式。
改成什么呢？
web 中可以使用 local storage，APP 中使用客户端数据库，这样既能这样就实现了跨域，并且避免了 CSRF 。
2、服务端也不存 Session 了，把 Session 信息拿出来存到 Redis 等内存数据库中，这样即提高了速度，又避免了 Session 同步问题；
经过改造之后变成了如下的认证过程：
- 用户输入用户名、密码或者用短信验证码方式登录系统；
- 服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
- 客户端拿到返回的 key，存储到 local storage 或本地数据库；
- 下次客户端再次请求，把 key 值附加到 header 或者 请求体中；
- 服务端根据获取的 key，到 Redis 中获取认证信息；
下面两张图分别演示了首次登录和非首次登录的过程。
经过一顿猛如虎的改造，解决了传统 Cookie-Session 方式存在的问题。这种改造需要开发者在项目中自行完成。改造起来肯定是费时费力的，而且还有可能存在漏洞。
JWT 出场
这时，JWT 就可以上场了，JWT 就是一种Cookie-Session改造版的具体实现，让你省去自己造轮子的时间，JWT 还有个好处，那就是你可以不用在服务端存储认证信息（比如 token），完全由客户端提供，服务端只要根据 JWT 自身提供的解密算法就可以验证用户合法性，而且这个过程是安全的。
如果你是刚接触 JWT，最有疑问的一点可能就是： JWT 为什么可以完全依靠客户端(比如浏览器端)就能实现认证功能，认证信息全都存在客户端，怎么保证安全性？
JWT 数据结构
JWT 最后的形式就是个字符串，它由头部、载荷与签名这三部分组成，中间以「.」分隔。像下面这样：
头部
头部以 JSON 格式表示，用于指明令牌类型和加密算法。形式如下，表示使用 JWT 格式，加密算法采用 HS256，这是最常用的算法，除此之外还有很多其他的。
{
"alg": "HS256",
"typ": "JWT"
}
对应上图的红色 header 部分，需要 Base64 编码。
载荷
用来存储服务器需要的数据，比如用户信息，例如姓名、性别、年龄等，要注意的是重要的机密信息最好不要放到这里，比如密码等。
{
"name": "古时的风筝",
"introduce": "英俊潇洒"
}
另外，JWT 还规定了 7 个字段供开发者选用。
- iss (issuer)：签发人
- exp (expiration time)：过期时间
- sub (subject)：主题
- aud (audience)：受众
- nbf (Not Before)：生效时间
- iat (Issued At)：签发时间
- jti (JWT ID)：编号
这部分信息也是要用 Base64 编码的。
签名
签名有一个计算公式。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
Secret
)
使用HMACSHA256算法计算得出，这个方法有两个参数，前一个参数是 （base64 编码的头部 + base64 编码的载荷）用点号相连，后一个参数是自定义的字符串密钥，密钥不要暴露在客户端，近应该服务器知道。
使用方式
了解了 JWT 的结构和算法后，那怎么使用呢？假设我这儿有个网站。
1、在用户登录网站的时候，需要输入用户名、密码或者短信验证的方式登录，登录请求到达服务端的时候，服务端对账号、密码进行验证，然后计算出 JWT 字符串，返回给客户端。
2、客户端拿到这个 JWT 字符串后，存储到 cookie 或者 浏览器的 LocalStorage 中。
3、再次发送请求，比如请求用户设置页面的时候，在 HTTP 请求头中加入 JWT 字符串，或者直接放到请求主体中。
4、服务端拿到这串 JWT 字符串后，使用 base64的头部和 base64 的载荷部分，通过HMACSHA256算法计算签名部分，比较计算结果和传来的签名部分是否一致，如果一致，说明此次请求没有问题，如果不一致，说明请求过期或者是非法请求。
怎么保证安全性的
保证安全性的关键就是 HMACSHA256 或者与它同类型的加密算法，因为加密过程是不可逆的，所以不能根据传到前端的 JWT 传反解到密钥信息。
另外，不同的头部和载荷加密之后得到的签名都是不同的，所以，如果有人改了载荷部分的信息，那最后加密出的结果肯定就和改之前的不一样的，所以，最后验证的结果就是不合法的请求。
别人拿到完整 JWT 还安全吗
假设载荷部分存储了权限级别相关的字段，强盗拿到 JWT 串后想要修改为更高权限的级别，上面刚说了，这种情况下是肯定不会得逞的，因为加密出来的签名会不一样，服务器可能很容易的判别出来。
那如果强盗拿到后不做更改，直接用呢，那就没有办法了，为了更大程度上防止被强盗盗取，应该使用 HTTPS 协议而不是 HTTP 协议，这样可以有效的防止一些中间劫持攻击行为。
有同学就要说了，这一点也不安全啊，拿到 JWT 串就可以轻松模拟请求了。确实是这样，但是前提是你怎么样能拿到，除了上面说的中间劫持外，还有什么办法吗？
除非强盗直接拿了你的电脑，那这样的话，对不起，不光 JWT 不安全了，其他任何网站，任何认证方式都不安全。
虽然这样的情况很少，但是在使用 JWT 的时候仍然要注意合理的设置过期时间，不要太长。
一个问题
JWT 有个问题，导致很多开发团队放弃使用它，那就是一旦颁发一个 JWT 令牌，服务端就没办法废弃掉它，除非等到它自身过期。有很多应用默认只允许最新登录的一个客户端正常使用，不允许多端登录，JWT 就没办法做到，因为颁发了新令牌，但是老的令牌在过期前仍然可用。这种情况下，就需要服务端增加相应的逻辑。
