Json Web Token分布式站点的单点登录场景

先了解基于token的认证和传统的session认证的区别

1、session认证

什么是cookies和session？

cookies浏览器会话技术，用来存储信息sessionid

session是服务器端的缓存技术

浏览器端的缓存技术，为了辨别用户身份，进行session跟踪而存储在用户本地终端上的数据。

HTTP协议 无连接和无状态的特性，是cookies和session产生的原因，用户向服务器提供用户名和密码来进行用户认证，因为http协议，每次认证的时候，无法获知是那个用户发动的请求，为了解决这个问题，服务器端存储用户登录信息，这些信息在响应的时传递给浏览器，浏览器将信息保存为cookie，浏览器再次发送请求时，就能根据sessionid识别是哪个用户。

- cookies是保存在客户端的一组识别信息（例如会员卡）

- cookies和session通过sessionid关联

- 当客户机登录成功后，关闭了相关页面，一段时间以内（没有到超时时间），再次访问相关网页，浏览器会自动携带响应的cookies信息（主要是包含sessionid），并发送给服务器，服务器检测相应的 sessionid的超时状态，如果没超时，按照已登录提供服务。

- 使用cookies实现免登录

在浏览器调试的时候：

请求的响应头里面的Set-Cookie是服务器发给客户端，用来设置客户端下次请求Cookie内容的。

请求头中Cookie是本次请求发送的Cookie

**注意：优先使用Set-Cookie,如果Set-Cookie不生效，尝试不同页面的Cookie**

 

问题在于哪呢？想一下随着用户的增多，不同客户端用户的增加，越来越多的登录状态存储在服务器端，这种基于session的认证会使服务器的压力增大。 还有一个问题，服务器认证记录存储在内存中，用户下次请求还必须在这台服务器上拿到授权的资源，这样在分布式的应用上，限制了负载均衡器的能力。除此之外，因为登录信息存储在浏览器端，cookie如果被截获，用户就会很容易收到跨站请求伪造的攻击（CSRF）

2、基于token的鉴权机制

先说一下流程，看看它带来的改进

用户提供用户名和密码，服务器进行验证后发送给用户一个token，客户端存储token，并在每次请求时带上token值，服务器就是根据自己的token来验证用户信息的。

token值时保存在请求头中的，服务端要自处CORS（跨源资源共享），一般在服务器我们将Access-Control-Allow-Origin: *

JWT 

JWT构成

头部（header）+ 载荷（payload）+ 签证（signature）,三部分信息文本之间用‘ . ’连接构成了JWT字符串

1、header

完整的header是下面这样的结构（第一部分是声明类型，第二部分是声明加密算法，通常使用的是HMAC SHA256）

{
    'typ': 'JWT',
    'alg': 'HS256'
}

然后对头部信息进行base64加密成字符串

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

2、payload

载荷包含三个部分：标准中注册的声明、公共声明、私有声明

标准中注册的声明(建议但不强制使用) ：

• iss: jwt签发者
• sub: jwt所面向的用户
• aud: 接收jwt的一方
• exp: jwt的过期时间，这个过期时间必须要大于签发时间
• nbf: 定义在什么时间之前，该jwt都是不可用的.
• iat: jwt的签发时间
• jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

公共的声明： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

私有的声明： 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

• 因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。

定义一个payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": True
}

然后将其进行base64加密，得到Jwt的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

3、signature

这个部分需要base64加密后的header和base64加密后的payload使用 . 连接组成的字符串，

然后通过header中声明的加密方式进行加盐secret组合加密，

加密结果就是jwt的第三部分。

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); //TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

以上三个部分最终的字符串用 . 连接起来就构成了jwt

注意：

secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

• 不应该在jwt的payload部分存放敏感信息，因为该部分是客户端可解密的部分。
• 保护好secret私钥，该私钥非常重要。
• 如果可以，请使用https协议

如何应用JWT

一般是在请求头里加入Authorization，并加上Bearer标注：

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})