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协议传输。