常用于用户认证的方式之JWT（Json Web Token）理解

简介

JWT，全称Json Web Token;是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519)。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。（如果不知道何为单点登录，请往下拉查看）。

JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

介绍

简单而言，JWT是一种认证用户身份信息的方式。

由于http是无状态的，所以http协议无法保存我们的用户信息。那么，设想一下，当我们输入用户名和密码登录了某个系统，如果没有任何认证能力，那么再下一次请求中，我们仍然需要认证用户信息。

那么，为了解决认证能力，传统的方式是采用cookie或者session来保存用户的信息。我们通过把用户信息放在以sessionId的形式cookie中，下一次请求，我们将cookie发送给服务器，服务器在自身存储的session表中查找，如果存在，则说明已经登录过了，不用再次验证。

乍一看，好像传统的认证方式已经解决了用户信息认证的问题，但是这其中存在着这几大隐患：

1.每个用户在认证后，我们都需要在服务端做记录，所以当用户量巨大时，服务端的开销会明显增加。

2.在分布式的应用场景下，用户访问的可能不是同一台服务器，那么，就需要在多台服务器上，记录相同的用户信息。

3.传统的方式是基于cookie存储的，容易被黑客获取，造成CSRF（跨站请求攻击）。

JWT组成

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：

Header
Payload
Signature

所以，一个JWT格式为：xxx.yyy.zzz

下面来具体介绍这几个部分；

Header

header典型的由两部分组成：
token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。

例子：

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

然后，用Base64对这个JSON编码就得到JWT的第一部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Payload(载荷)

载荷就是存放有效信息的地方。这些有效信息包含三个部分

标准中注册的声明
公共的声明
私有的声明

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

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

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

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

例子：

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

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

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

Signature

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

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

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

例子

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

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

将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

本博客下方有官方生成jwt字符串网址，可自行测试生成

JWT

在了解了JWT的组成后，我们来看他是如何解决传统session存储所带来的问题。

（对应问题的序号）
1.传统的方式是把认证信息存储在服务段，客户端只存储sessionId;而JWT存储在客户端，服务端不存储，那么这就很大程度上解放了服务端的压力。

2.通过1我们也可以知道在分布式场景下，这种方式也就不需要在多个服务器上存储相同的用户信息。

3.Token不是Cookie。每次请求的时候Token都会被发送。而且，任何更改都会导致JWT中的header或者payload造成更改，从而无法得出正确的signature，从而验证失败。这将有助于防止CSRF攻击。

流程

认证过程：

第一次登录，通过Header和payload生成signature，存储在客户端。
第二次请求，将JWT字符串发送给服务端，服务端通过解码header和payload得到一个签名，再将这个签名和signature中的签名进行比较，如果一致，则认证通过，否则不通过。

图解如下：

单点登录：

用户只需要登录一次就可以访问所有相互信任的应用系统。（涉及不同系统的跨域，如果用传统的session存储，则每个系统所在的服务器都需要保存session，这样就加重了服务器的负担）

CSRF:

攻击者通过获取你的访问地址和身份，并且更改其中相应的参数，来达到攻击的目的，如将转账目的用户更改为自己。而浏览器鉴权只能通过cookie来进行鉴别，而无法对每一次的请求进行鉴别，从而更改了参数仍然可以访问造成金钱损失。

资料

JWT字符串生成；https://jwt.io/#debugger-io