JSON Web Token
(JWT)是一个开放标准(RFC 7519
),它定义了一种紧凑和自包含的方式,用于在各方之间作为JSON对象安全地传输信息。
作为标准,它没有提供技术实现,但是大部分的语言平台都有按照它规定的内容提供了自己的技术实现,所以实际在用的时候,只要根据自己当前项目的技术平台,到官网上选用合适的实现库即可。
Token
,其实就是服务端生成的一串加密字符串、以作客户端进行请求的一个“令牌”
以下是JWT两种使用场景:
授权:这是使用
JWT
的最常见的使用场景。用户登录后,每个后续请求都将包含JWT
,允许用户访问使用该令牌允许的路由、服务和资源。单点登录是当今广泛使用JWT
的一项功能,因为它的开销很小,并且能够跨不同域轻松使用。
信息交换:
JWT
是在各方之间安全传输信息的比较便捷的方式。由于JWT
可以签名(例如,使用公钥
/私钥
对),因此可以确定发送者是否是在您的授权范围之内。并且,由于签名是使用标头和有效负载计算的,因此还可以验证内容是否未被篡改。
这是一个JWT的token串:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
其实这一串是经过加密之后的密文字符串,中间通过.
来分割。每个.
之前的字符串分别表示JWT
的三个组成部分:Header
、Payload
、Signature
。
Header的主要作用是用来标识,通常是两部分组成:
typ
:type
的简写,令牌类型,也就是JWT
。
alg
:Algorithm
的简写,加密签名算法。一般使用HS256
,jwt
官网提供了12种的加密算法
然后通过base64编码,将明文编码,防止在传输过程中能直接一眼看出明文并符合多种传输协议
也称为JWT claims
payload
用来承载要传递的数据,它的json
结构实际上是对JWT
要传递的数据的一组声明,这些声明被JWT
标准称为claims
,它的一个“属性值对”其实就是一个claim
,每一个claim
的都代表特定的含义和作用
claims有三类:
iss
发行者、exp
过期时间、sub
主题、aud
用户等。key | name | 说明 |
---|---|---|
iss | 发送者 | 标识颁发 JWT 的发送主体 |
sub | 主题 | 标识 JWT 的主题 |
aud | 接收者 | 标识 JWT 所针对的接收者。每个在处理 JWT 的主体都必须使用受众声明中的值来标识自己。如果处理的主体在存在此声明时未将自己标识为声明中的值,则必须拒绝 JWT |
exp | 到期时间 | 标识不得接受 JWT 进行处理的过期时间。该值必须是日期类型,而且是1970-01-01 00:00:00Z 之后的日期秒。 |
nbf | jwt 的开始处理的时间 | 标识 JWT 开始接受处理的时间。该值必须是日期。 |
iat | jwt 发出的时间 | 标识 JWT 的发出的时间。该值必须是日期。 |
jti | jwt id | 令牌的区分大小写的唯一标识符,即使在不同的颁发者之间也是如此。 |
保留claim
为jwt
标准中规定的claim
,验证方式已经定义好
明文实例:
{
"sub": "12344321",
"name": "Mars酱", // 私有claims
"iat": 1516239022
}
base64加密后:
eyJzdWIiOiIxMjM0NDMyMSIsIm5hbWUiOiJNYXJz6YWxIiwiaWF0IjoxNTE2MjM5MDIyfQ
Signature
部分是对Header
和Payload
两部分的签名,作用是防止 JWT
被篡改。这个部分的生成规则主要是是公式(伪代码)是:
Header中定义的签名算法alg(
base64编码(header) + "." + base64编码(payload),
secret//在服务端加密使用的密钥
)
JWT
如果从字面上理解感觉是基于JSON
格式用于网络传输的令牌。实际上,JWT
是一种紧凑的Claims
声明格式,,常见的场景如HTTP授权请求头参数和URI查询参数。JWT
会把Claims
转换成JSON
格式,而这个JSON
内容将会应用为JWS
结构的有效载荷或者应用为JWE
结构的(加密处理后的)原始字符串,通过消息认证码(Message Authentication Code
或者简称MAC
)和/或者加密操作对Claims
进行数字签名或者完整性保护。