jsonwebtoken
JSONWebToken(JWT)是一个敞开规范(RFC7519)，它界说了一种紧凑且自包括的方法，运用JSON对象在各方之间安全地传输信息。此信息能够验证和信赖，由于它是数字签名的。JWT能够运用密钥（运用HMAC算法）或运用RSA或ECDSA的公钥/私钥对进行签名。
虽然JWT能够加密以在各方之间供给保密性，但我们将专注于签名令牌。已经签名的token能够验证其间包括的声明（claims）的完整性，而加密的令牌会向其他方躲藏这些声明。当运用公钥/私钥对对令牌进行签名时，签名还能证明只有持有私钥的一方才是签署它的一方。
jsonwebtoken安装使用教程
JSONWebToken（缩写JWT）是目前最盛行的跨域认证解决计划，本文介绍它的原理和用法。
一、跨域认证问题
互联网服务离不开用户认证。一般流程是下面这样。
用户向服务器发送用户名和暗码
服务器验证通往后，在当前对话（session）中保留相关数据，如用户人物、登陆时刻等
服务器向用户回来一个session_id，写入用户的Cookie
用户随后的每一次恳求，都会通过Cookie，将session_id传回服务器
服务器收到session_id，找到前期保存的数据，由此得知用户身份
这种形式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或许是跨域的服务导向架构，就要求session数据共享，每台服务器都能够读取session。
举例来说，A网站和B网站是同一家公司的关联服务。现在要求，用户只需在其中一个网站登录，再拜访另一个网站就会主动登录，请问怎样完成？
一种计划是session数据耐久化，写入数据库或其他耐久层。各种服务收到恳求后，都向耐久层恳求数据。这种计划的长处是架构清晰，缺陷是工程量比较大。别的，耐久层如果挂了，就会单点失利。
另一种计划是服务器索性不保存session数据了，所有数据都保存在客户端，每次恳求都发回服务器。JWT便是这种计划的一个代表。
二、JWT的原理
JWT的原理是，服务器认证今后，生成一个JSON目标，发回给用户，就像下面这样。
{“姓名”:”张三”,”人物”:”管理员”,”到期时刻”:”2022年02月22日22点22分”}
今后，用户与服务端通信的时分，都要发回这个JSON目标。服务器彻底只靠这个目标确定用户身份。为了避免用户篡改数据，服务器在生成这个目标的时分，会加上签名（详见后文）。
服务器就不保存任何session数据了，也便是说，服务器变成无状态了，从而比较简单完成扩展。
三、JWT的数据结构
实际的JWT大约就像下面这样。
它是一个很长的字符串，中间用点（.）分隔成三个部分。留意，JWT内部是没有换行的，这里仅仅为了便于展现，将它写成了几行。
JWT的三个部分顺次如下。
header（头部）
payload（负载）
signature（签名）
写成一行，便是下面的姿态。
header.payload.signature
下面顺次介绍这三个部分。
3.1Header
Header部分是一个JSON目标，描绘JWT的元数据，通常是下面的姿态。
{“alg”:”HS256″,”typ”:”JWT”}
上边代码中，alg特色表明签名的算法（algorithm），默认是HMACSHA256（写成HS256）；typ特色表明这个令牌（token）的类型（type），JWT令牌统一写为JWT。
最后，将上边的JSON目标运用Base64URL算法（详见后文）转成字符串。
3.2Payload
Payload部分也是一个JSON目标，用来寄存实际需求传递的数据。JWT规则了7个官方字段，供选用。
iss(issuer)：签发人
exp(expirationtime)：过期时刻
sub(subject)：主题
aud(audience)：受众
nbf(NotBefore)：收效时刻
iat(IssuedAt)：签发时刻
jti(JWTID)：编号
除了官方字段，你还能够在这个部分定义私有字段，下面便是一个例子。
{“sub”:”1234567890″,”name”:”JohnDoe”,”admin”:true}
留意，JWT默认是不加密的，任何人都能够读到，所以不要把秘密信息放在这个部分。
这个JSON目标也要运用Base64URL算法转成字符串。
3.3Signature
Signature部分是对前两部分的签名，避免数据篡改。
首先，需求指定一个密钥（secret）。这个密钥只有服务器才知道，不能走漏给用户。然后，运用Header里边指定的签名算法（默认是HMACSHA256），依照下面的公式产生签名。
HMACSHA256(
base64UrlEncode(header)+”.”+
base64UrlEncode(payload),
secret)
算出签名今后，把Header、Payload、Signature三个部分拼成一个字符串，每个部分之间用”点”（.）分隔，就能够回来给用户。
3.4Base64URL
前面说到，Header和Payload串型化的算法是Base64URL。这个算法跟Base64算法根本相似，但有一些小的不同。
JWT作为一个令牌（token），有些场合可能会放到URL（比方api.example.com/?token=xxx）。Base64有三个字符+、/和=，在URL里边有特别含义，所以要被替换掉：=被省略、+替换成-，/替换成_。这便是Base64URL算法。
四、JWT的运用方法
客户端收到服务器回来的JWT，能够储存在Cookie里边，也能够储存在localStorage。
此后，客户端每次与服务器通信，都要带上这个JWT。你能够把它放在Cookie里边主动发送，但是这样不能跨域，所以更好的做法是放在HTTP恳求的头信息Authorization字段里边。
Authorization:Bearer<token>
另一种做法是，跨域的时分，JWT就放在POST恳求的数据体里边。
五、JWT的几个特色
（1）JWT默认是不加密，但也是能够加密的。生成原始Token今后，能够用密钥再加密一次。
（2）JWT不加密的情况下，不能将秘密数据写入JWT。
（3）JWT不仅能够用于认证，也能够用于交流信息。有用运用JWT，能够降低服务器查询数据库的次数。
（4）JWT的最大缺陷是，由于服务器不保存session状态，因此无法在运用过程中废止某个token，或许更改token的权限。也便是说，一旦JWT签发了，在到期之前就会始终有用，除非服务器布置额定的逻辑。
（5）JWT本身包含了认证信息，一旦走漏，任何人都能够获得该令牌的所有权限。为了减少盗用，JWT的有用期应该设置得比较短。关于一些比较重要的权限，运用时应该再次对用户进行认证。
（6）为了减少盗用，JWT不应该运用HTTP协议明码传输，要运用HTTPS协议传输。
本文链接：https://my.lmcjl.com/post/8738.html
4 评论