JWT详细讲解-实用版

什么是JWT

jwt（Json web token）是目前最流行的跨域认证解决方案。

JWT, 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

原理介绍 

 由于http协议本身是一种无状态的协议，这意味着当用户使用账户和密码进行用户认证完成后并不能存在登录状态。导致下次请求依旧需要再次认证。因为服务器仅仅通过http协议，并不能知道是哪个用户发出的请求，所以需要借助一些处理机制来记录认证状态，从而完成请求和响应。

基于token的认证和传统的session认证

传统的session认证

session认证是将用户的认证信息存储在服务器端，并且会在认证通过后将这一份认证信息传递给浏览器端，浏览器将其保存为cookie。浏览器在下次发送请求时会将该cookie携带并且发送给我们的服务器，这样我们的应用就能识别请求来自哪个用户了，这就是基于传统的session认证。

但是基于session认证的的应用本身很难扩展，随着不同客户端用户的增加，独立的服务器无法承载越来越多的用户，这时候session认证的问题也就暴露出来了。

基于session认证的常见问题

1. session：由于每个用户经过我们的认证服务器认证之后，都要在该认证服务器端做一次记录，通常而言该记录保存在内存中，这就导致内存占用量随着认证用户数量的增加而越来越大，服务器的开销也会越来越大。
2. 扩展性：用户认证之后，服务器端将认证记录存储在内存中，这意味着该用户的下次请求还必须要请求在这台服务器上，只有这样授权才能通过。这种方式下也就限制了负载均衡器的能力。也就限制了应用的扩展能力。
3. CSRF:因为基于cookie来进行用户识别，所以当cookie被劫持，用户就很容易受到跨站请求伪造的攻击。

基于token的鉴权机制

token认证和session最大的区别在于服务器端不需要保存用户的认证信息或者会话信息。这也就意味着基于token认证机制的应用不需要考虑用户是在哪台服务器上登录的，这也就适应了分布式服务器的特点需求。对负载均衡器更加友好。

token的认证流程：

1. 用户使用用户名（账户）、密码请求服务器进行登录。
2. 服务器验证用户信息，对比用户名和密码是否存在且一致。
3. 验证用户信息没有问题后，服务器端根据token生成的机制生成token。
4. 服务器端返回给用户一个token。
5. 客户端（浏览器）存储token，并且每次请求时附送上这个token。
6. 服务器端通过验证机制验证token，并且返回数据。

这个token在验证后每次请求时都要传递给服务器端，通过请求头传递。另外服务器要支持CORS（跨来源资源共享）策略，一般在服务端这样做：

Access-Control-Allow-Origin：*

 

JWT结构

JWT由三段信息构成，通过 .链接在一起构成jwt字符串。类似这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

 JWT三部分介绍：

header

jwt的头部承载两部分信息：

• 声明token类型，这里是jwt
• 声明token的加密方式 通常使用 HMAC SHA256等

完整的头部如下：

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

 通过对该json字符串进行BASE64压缩就得到了header部分。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Payload

有关实体的声明，存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分

声明有三种类型: registered, public 和 private。

• Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
  • 标准中注册的声明 (建议但不强制使用) ：
    • iss: jwt签发者
    • sub: jwt所面向的用户
    • aud: 接收jwt的一方
    • exp: jwt的过期时间，这个过期时间必须要大于签发时间
    • nbf: 定义在什么时间之前，该jwt都是不可用的.
    • iat: jwt的签发时间
    • jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
• Public claims : 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
• Private claims : 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

{
  "uid": "1234567890",
  "name": "John Doe",
  "admin": true
}

对该json字符串进行BASE64压缩就得到了第二部分。从这里可以看出payload完全是明文暴露的，请不要放置一些重要信息。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

signature

jwt的第三部分是一个签证信息，以token的前两部分作为明文，用共同协商好的秘钥进行签名（对称签名和非对称签名）。这个签证信息由三部分组成：

• header (base64后的)
• payload (base64后的)
• secret

签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。

 通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

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

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

如何应用

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

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

总结

优点：

• 因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
• 因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
• 便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。
• 它不需要在服务端保存会话信息, 所以它易于应用的扩展

• 无状态和可扩展性：Tokens存储在客户端。完全无状态，可扩展。我们的负载均衡器可以将用户传递到任意服务器，因为在任何地方都没有状态或会话信息。
• 安全：Token不是Cookie。（The token, not a cookie.）每次请求的时候Token都会被发送。而且，由于没有Cookie被发送，还有助于防止CSRF攻击。即使在你的实现中将token存储到客户端的Cookie中，这个Cookie也只是一种存储机制，而非身份认证机制。没有基于会话的信息可以操作，因为我们没有会话!
• 过期性：token在一段时间以后会过期，这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫token撤销，它允许我们根据相同的授权许可使特定的token甚至一组token无效。