我们在做应用系统时避免不了用户的认证授权，说简单点就是：认证你是谁，授权你有什么权限。在这里先来谈谈用户的认证，目前常用的认证方式有两种：基于session认证、基于token认证。
JWT（JSON Web Token）是一个开放的行业标准（RFC 7519），自身包含了身份验证所需要的所有信息，因此我们的服务器不需要存储用户Session信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。可以看出JWT更符合设计RESTful API时的Stateless（无状态）原则。并且使用JWT认证可以有效避免CSRF攻击，因为JWT一般是存在在localStorage中，使用JWT进行身份验证的过程中是不会涉及到Cookie的。
图片
JWT本质上是一组字串，通常是这样的：xxxxx.yyyyy.zzzzz，通过（.）切分成三个为Base64编码的部分：
使用Header里面指定的签名算法（默认是 HMAC SHA256）生成。
示例：
图片
可以通过https://jwt.io对上述JWT进行解码，解码之后便可得到Header、Payload、Signature这三部分。Header和Payload都是JSON格式的数据，Signature由Payload、Header和Secret(密钥)通过特定的计算公式和加密算法得到。
图片
通常由两部分组成。
示例：
图片
JSON形式的Header被转换成Base64编码，成为JWT的第一部。
包含了三种类型的声明。
下面是一些常见的注册声明：
示例：
图片
Payload部分默认是不加密的，一定不要将隐私信息存放在 Payload 当中！！！
JSON 形式的Payload被转换成Base64编码，成为JWT的第二部分。
对前两部分的签名，作用是防止JWT（主要是payload）被篡改。签名的生成需要用到：Header+Payload、存放在服务端的密钥(一定不要泄露出去)、签名算法。签名的计算公式如下：
图片
算出签名以后，把 Header、Payload、Signature三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，这个字符串就是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）
服务器返回签名之后，即使JWT被泄露或者截获，黑客也没办法同时篡改Signature、Header、Payload。
这是为什么呢？因为服务端拿到JWT之后，会解析出其中包含的Header、Payload 以及Signature。服务端会根据Header、Payload、密钥再次生成一个Signature。拿新生成的Signature和JWT中的Signature作对比，如果一样就说明Header和Payload没有被修改。
不过，如果服务端的秘钥也被泄露的话，黑客就可以同时篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后，再重新生成一个Signature就可以了。
❖注意：密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。
1．使用安全系数高的加密算法。
2．使用成熟的开源库，没必要造轮子。
3．JWT存放在localStorage中而不是Cookie中，避免CSRF风险。
4．一定不要将隐私信息存放在Payload当中。
5．密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。
6．Payload要加入exp（JWT的过期时间），永久有效的JWT不合理。并且JWT的过期时间不易过长。
- 优点
1．无状态：自身携带用户信息，不需要在服务器上保存session信息。
2．可有效避免CSRF攻击：CSRF攻击需要依赖Cookie，然而JWT选择存放在localStorage中，因此非法链接无法获取JWT。
- 缺点
1．不可控：就比如说，我们想要在JWT有效期内废弃一个JWT或者更改它的权限的话，并不会立即生效，通常需要等到有效期过后才可以。再比如说，当用户Logout的话，JWT也还有效。
在“约定优于配置，配置优于编码”的开发理念下，通过Apollo配置中心，程序员不需要每次更改线上配置都要重新发布服务，成功实现了将配置与编码解耦，为线上服务变更配置提供了解决方案。
本文链接：http://www.28at.com/showinfo-26-52590-0.html一文读懂JWT
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 微服务开发，这十个点你要知道
下一篇： 15个跨平台的VS Code插件
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
