Labs 导读
我们在做应用系统时避免不了用户的认证授权，说简单点就是：认证你是谁，授权你有什么权限。在这里先来谈谈用户的认证，目前常用的认证方式有两种：基于session认证、基于token认证。
Part 01、 JWT是什么？
JWT（JSON
Web Token）是一个开放的行业标准（RFC
7519），自身包含了身份验证所需要的所有信息，因此我们的服务器不需要存储用户Session信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。可以看出JWT更符合设计RESTful
API时的Stateless（无状态）原则。并且使用JWT认证可以有效避免CSRF攻击，因为JWT一般是存在在localStorage中，使用JWT进行身份验证的过程中是不会涉及到Cookie的。
Part 02、 JWT由哪些部分组成？
图片
JWT本质上是一组字串，通常是这样的：xxxxx.yyyyy.zzzzz，通过（.）切分成三个为Base64编码的部分：
- Header：描述JWT的元数据，定义了生成签名的算法以及Token的类型。
- Payload：用来存放实际需要传递的数据。
- Signature：服务器通过Payload、Header和一个密钥(Secret)
使用Header里面指定的签名算法（默认是 HMAC SHA256）生成。
示例：
图片
可以通过https://jwt.io对上述JWT进行解码，解码之后便可得到Header、Payload、Signature这三部分。Header和Payload都是JSON格式的数据，Signature由Payload、Header和Secret(密钥)通过特定的计算公式和加密算法得到。
图片
- Header
通常由两部分组成。
- typ（Type）：令牌类型，也就是JWT
- alg（Algorithm）：签名算法，比如HS256
示例：
图片
JSON形式的Header被转换成Base64编码，成为JWT的第一部。
- Payload
包含了三种类型的声明。
- Registered Claims（注册声明）：预定义的一些声明，建议使用，但不强制。
- Public Claims（公有声明）：JWT签发方可以自定义的声明。
- Private Claims（私有声明）：JWT签发方因为项目需要而自定义的声明。
下面是一些常见的注册声明：
- iss（issuer）：JWT 签发方。
- iat（issued at time）：JWT签发时间。
- sub（subject）：JWT主题。
- aud（audience）：JWT接收方。
- exp（expiration time）：JWT的过期时间。
- nbf（not before time）：JWT生效时间，早于该定义的时间的JWT不能被接受处理。
- jti（JWT ID）：JWT唯一标识。
示例：
图片
Payload部分默认是不加密的，一定不要将隐私信息存放在 Payload 当中！！！
JSON 形式的Payload被转换成Base64编码，成为JWT的第二部分。
- Signature
对前两部分的签名，作用是防止JWT（主要是payload）被篡改。签名的生成需要用到：Header+Payload、存放在服务端的密钥(一定不要泄露出去)、签名算法。签名的计算公式如下：
图片
算出签名以后，把 Header、Payload、Signature三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，这个字符串就是JWT。
Part 03、 JWT如何进行用户认证？
在基于JWT进行身份验证的的应用程序中，服务器通过
Payload、Header和Secret(密钥)创建JWT并将JWT发送给客户端。客户端接收到JWT之后，会将其保存在Cookie或者localStorage里面，以后客户端发出的所有请求都会携带这个令牌。
图片
简化后的步骤如下：
1．用户向服务器发送用户名、密码以及验证码用于登陆系统。
2．如果用户用户名、密码以及验证码校验正确的话，服务端会返回已签名的Token，也就是JWT。
3．用户以后每次向后端发请求都在Header中带上这个JWT。
4．服务端检查JWT并从中获取用户相关信息。
两点建议：
1．建议将JWT存放在localStorage中，放在Cookie中会有CSRF风险。
2．请求服务端并携带JWT的常见做法是将其放在HTTP Header的Authorization字段中（Authorization：Bearer Token）
Part 04、 JWT如何防止被篡改？
服务器返回签名之后，即使JWT被泄露或者截获，黑客也没办法同时篡改Signature、Header、Payload。
这是为什么呢？因为服务端拿到JWT之后，会解析出其中包含的Header、Payload
以及Signature。服务端会根据Header、Payload、密钥再次生成一个Signature。拿新生成的Signature和JWT中的Signature作对比，如果一样就说明Header和Payload没有被修改。
不过，如果服务端的秘钥也被泄露的话，黑客就可以同时篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后，再重新生成一个Signature就可以了。
❖注意：密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。
Part 05、 JWT如何加强安全性？
1．使用安全系数高的加密算法。
2．使用成熟的开源库，没必要造轮子。
3．JWT存放在localStorage中而不是Cookie中，避免CSRF风险。
4．一定不要将隐私信息存放在Payload当中。
5．密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。
6．Payload要加入exp（JWT的过期时间），永久有效的JWT不合理。并且JWT的过期时间不易过长。
Part 06、 JWT有哪些优缺点？
- 优点
1．无状态：自身携带用户信息，不需要在服务器上保存session信息。
2．可有效避免CSRF攻击：CSRF攻击需要依赖Cookie，然而JWT选择存放在localStorage中，因此非法链接无法获取JWT。
- 缺点
1．不可控：就比如说，我们想要在JWT有效期内废弃一个JWT或者更改它的权限的话，并不会立即生效，通常需要等到有效期过后才可以。再比如说，当用户Logout的话，JWT也还有效。
Part 07、 JWT使用总结
在“约定优于配置，配置优于编码”的开发理念下，通过Apollo配置中心，程序员不需要每次更改线上配置都要重新发布服务，成功实现了将配置与编码解耦，为线上服务变更配置提供了解决方案。
