一、HTTP的无状态性
HTTP 是无状态协议，它不对之前发送过的要乞降相应的状态进行管理。也便是说，无法根据之前的状态进行本次的要求处理。假设哀求登录认证的 Web 页面本身无法进行状态的管理（不记录已登录的状态），那么每次跳转新页面不是要再次登录，便是要在每次要求报文中附加参数来管理登录状态。
不可否认，无状态协议当然也有它的优点。由于不必保存状态，自然可减少做事器的 CPU 及内存资源的花费。从另一侧面来说，也正是由于 HTTP 协议本身是非常大略的，以是才会被运用在各种场景里。
二、Cookie 技能的引入
如果让做事器管理全部客户端状态则会成为包袱，保留无状态协议这个特色的同时又要办理类似的抵牾问题，于是引入了 Cookie 技能。Cookie 技能通过在要乞降相应报文中写入Cookie信息来掌握客户真个状态。
Cookie会根据从做事器端发送的相应报文内的一个叫做Set-Cookie 的首部字段信息，关照客户端保存 Cookie。当下次客户端再往该做事器发送要求时，客户端会自动在要求报文中加入Cookie 值后发送出去。
1、没有 Cookie 信息状态下的要求（图片来源《图解HTTP》）
2、第 2 次往后（存有 Cookie 信息状态） 的要求（图片来源《图解HTTP》）
3、详细先容Cookie 传输过程
做事器端创造客户端发送过来的 Cookie 后， 会去检讨究竟是从哪一个客户端发来的连接要求， 然后比拟做事器上的记录， 末了得到之前的状态信息。
三、基于表单的认证
目前用户的认证多数是基于表单的认证，基于表单的认证一样平常会利用 Cookie 来管理Session（Session会话，Session代表着做事器和客户端一次会话的过程，直到Session失落效（做事端关闭）或者客户端关闭时结束）。基于表单认证本身是通过做事器真个 Web运用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于 HTTP 是无状态协议， 之前已认证成功的用户状态无法通过协议层面保存下来。 即无法实现状态管理， 因此纵然当该用户下一次连续访问，也无法区分他与其他的用户。于是我们会利用Cookie 来管理 Session，以填补 HTTP 协议中不存在的状态管理功能。
大略的来说便是，用户在登录的时候，会在Web做事器中开辟一段内存空间Session用于保存用户的认证信息和其他信息，用户登录成功之后会通过Set-Cookie的首部字段信息，关照客户端保存Cookie，而这Cookie保存的便是做事器端Session的ID，下次要求的时候客户端会带上该Cookie向做事器端发送要求，做事器端进行校验，如果Session中保存的有该ID的Session就表示用户认证通过，否则失落败！
四、Session存储位置以及集议论形下的问题
Session 是存储在Web做事器（例如：Tomcat）中的，并针对每个客户端（客户），通过SessionID来差异不同用户的。Session因此Cookie技能或URL重写实现，默认以Cookie技能实现，做事端会给这次会话创造一个JSESSIONID的Cookie值。
但是一个显著的问题便是，在集群模式下如果通过Nginx负载均衡的时候，如果有一个用户登录的时候要求被分配到做事器A上，登录成功后设置的Session就会存放在做事器A上了，但是在做事器B上却没有该用户的Session数据，当用户再次发起一个要求的时候，此时要求如果被分配到做事器B上，则就不会查询到该用户的登录状态，就会涌现登录失落败的情形！
一种可以想到的办法便是将多个Web做事器上存储的Session统一存储到某一存储介质中，担保进集群中的每一台机器都可以看到所有相同Session数据，这里的同步表示在所有的Session存储在同一的存储介质里边。
幸运的是我们常用的Tomcat容器已经为我们供应了一个接口，可以让我们实现将Session存储到除当前做事器之外的其他存储介质上，例如Redis等。
理解Spring Session的小伙伴可能都会知道Spring Session的实质便是通过实现Tomcat供应的该接口将Session存储到Redis中，以此来实现Session的统一存储管理，对Spring Session有兴趣的小伙伴可以参考往期的文章：
1、利用Redis存储Nginx+Tomcat负载均衡集群的Session
2、利用Spring Session和Redis办理分布式Session跨域共享问题
3、Spring Session办理分布式Session问题的实现事理
五、小结与需求痛点
Session和Cookie的目的相同，都是为了战胜HTTP协议无状态的毛病，但完成的方法不同。Session通过Cookie，在客户端保存SessionID，而将用户的其他会话保存在做事真个Session工具中，与此相对的，Cookie须要将所有信息都保存在客户端。因此Cookie存在着一定的安全隐患，例如本地Cookie中保存的用户名密码被破译，或Cookie被其他网站网络，例如：
appA主动设置域B cookie，让域B cookie获取；XSS，在appA上通过JavaScript获取document.cookie，并通报给自己的appB。上述过程我们大略的描述了Session的演进过程还有利用同步的办法办理Session在集群的时候涌现的问题，但是我们意识到了利用Spring Session的办法来实现Session的同步是一件相比拟较麻烦的事情，我们虽然利用Redis来进行同步，但是Redis并不是100%可靠的，我们须要对Redis搭建集群、进行主从同步复制、进行持久化等，显然这是一件很繁芜的事情，因此有没有一种小而轻便的办法来实现我们的这种认证需求！
那便是JWT了！
除了上述我们碰着的问题之外，在目前前后端分离的大环境下常常会碰着须要根据用户来分配权限和显示相对应信息的问题，虽然传统的Cookie和Session机制可以办理这个问题，但就通用性而言，JWT（JSON Web Token）相对来说更好。
看到这里很多小伙伴都已经按捺不住了！
那JWT到底是什么呢？
六、JWT是什么
Json web token (JWT)，是为了在网络运用环境间通报声明而实行的一种基于JSON的开放标准（(RFC 7519)。该标准被设计为紧凑且安全的，一样平常被用来在身份供应者和做事供应者间通报被认证的用户身份信息，以便于从资源做事器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息。当然该标准也可直接被用于认证，也可被加密。
JWT的几个特点：
1、由于它们的尺寸较小，JWT可以通过URL，POST参数或HTTP头部发送。 其余，尺寸越小意味着传输速率越快。
2、有效载荷包含有关用户的所有必需信息，避免了多次查询数据库的须要。
JWT的利用场景：
1、验证
这是利用JWT最常见的情形。 一旦用户登录，每个后续要求将包括JWT。它将许可用户访问该令牌许可的路由，做事和资源。 单点登录是当今广泛利用JWT的一项功能，由于它的开销很小，而且能够轻松地跨不同域利用。
2、信息交流
JWT是在各方之间安全传输信息的好方法， 由于JWT可以被署名（例如利用公钥/私钥对进行署名）。以是你可以确定发件人是他们说的那个人。 此外，由于利用头部（header）和有效载荷（payload）打算署名，因此您还可以验证内容是否未被修改。
七、JWT的构造解释
JWT包含三个由点（.）分隔的部分，它们是：
头部（header）有效负载（payload）署名（signature）因此，JWT常日看起来如下所示:
xxxxx.yyyyy.zzzzz
1、头部（header）
头部（header）常日由两部分组成：令牌的类型（即JWT）和正在利用的散列算法（如HMAC SHA256或RSA）。如下所示：
然后，将这个JSON用Base64编码，形成JWT的第一部分。
2、有效负载（payload）
令牌的第二部分是包含声明的有效载荷。 声明是关于实体（常日是用户）和附加元数据的声明。 有三种类型的声明：
标准中注册的声明；公开声明；私人声明；（1）标准中注册的声明：这是一组预先定义的声明，这些声明不是逼迫性的，但建议供应一套有用的，可互操作的声明。 如下：
iss: jwt签发者sub: jwt所面向的用户aud: 吸收jwt的一方exp: jwt的过期韶光，这个过期韶光必须要大于签发韶光nbf: 定义在什么韶光之前，该jwt都是不可用的.iat: jwt的签发韶光jti: jwt的唯一身份标识，紧张用来作为一次性token,从而回避重放攻击。把稳：声明名称只有三个字符长，由于JWT是紧凑的。
（2）公开声明：这些可以由利用JWT的职员随意定义。 但为避免冲突，应在IANA JSON Web令牌注册表中定义它们，或者将其定义为包含防冲突命名空间的URI。
（3）私人声明：这是为了共享利用它们确当事方之间共享信息而创建的声明，既不是登记声明，也不是公开声明。
示例如下：
然后将有效载荷进行Base64编码，以形成JSON Web令牌的第二部分。
3、署名（signature）
要创建署名部分，您必须采取头部（header），有效载荷（payload），密钥（secret），以及头部中指定的算法。例如，如果你想利用HMAC SHA256算法，署名将按以下办法创建：
署名常日用于验证JWT的发件人是谁，并JWT在传送的过程中不被修改。
把稳：上图红框中的secret是保存在做事器真个，JWT的签发生成也是在做事器真个，secret便是用来进行JWT的签发和jwt的验证，以是，它便是你做事真个私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret，那就意味着客户端是可以自我签发jwt了。
4、案例演示
下面显示了一个登录要求成功之后做事端返回的Token，它由编码头部（header）、编码有效载荷（payload）和署名（signature）通过（.）拼接而成：
如果须要，你可以利用jwt.io的Debugger工具，来编码、验证和天生JWT。操作界面如下：
八、JWT的事情事理
在身份验证中，当用户利用他们的凭据（如用户名、密码）成功登录时，后台做事器将返回一个token，前端吸收到这个token将其保存在本地（常日在本地存储中，也可以利用Cookie，但不是传统方法中创建会话，做事器并返回一个cookie）。下次用户想要访问受保护的路由或资源时，就将本地保存的token放在头部Header中发送到后台做事器。做事器吸收到要求，检讨头部中token的存在，如果存在就许可访问受保护的路由或资源，否则就不许可。如下所示：
一样平常默认的Value因此“Bearer ”开始，把稳这里的Bearer之后有一个空格，以便后端进行分割。
这是一种无状态身份验证机制，由于用户状态永久不会保存在做事器内存中。 由于JWT是独立的，所有必要的信息都在那里，以是减少了多次查询数据库的需求。
九、总结
1、优点
（1）由于Json的通用性，以是JWT是可以进行跨措辞支持的，像Java、JavaScript、NodeJS、PHP等很多措辞都可以利用。
（2）由于有了payload部分，以是JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
（3）便于传输，JWT的构成非常大略，字节占用很小，以是它是非常便于传输的。
（4）它不须要在做事端保存会话信息, 以是它易于运用的扩展
2、安全干系
（1）不应该在JWT的payload部分存放敏感信息，由于该部分是客户端可解密的部分。
（2）保护好secret私钥，该私钥非常主要。
（3）如果可以，请利用HTTPS协议，不！
是务必利用HTTPS!
后续得当机遇会有两至三篇文章先容JWT的利用和JWT的优缺陷以及如何担保token的安全性等，敬请期待！
