JWT
JWT (JSON Web Token) 是目前最流行的跨域认证解决方案,是一种基于 Token 的认证授权机制。 从 JWT 的全称可以看出,JWT 本身也是 Token,一种规范化之后的 JSON 结构的 Token。
JWT 自身包含了身份验证所需要的所有信息,因此,我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性,大大减轻了服务端的压力。
可以看出,JWT 更符合设计 RESTful API 时的「Stateless(无状态)」原则 。
并且, 使用 JWT 认证可以有效避免 CSRF 攻击,因为 JWT 一般是存在在 localStorage 中,使用 JWT 进行身份验证的过程中是不会涉及到 Cookie 的。
JWT 由哪些部分组成?
-
Header : 描述 JWT 的元数据,定义了生成签名的算法以及
Token
的类型。 -
Payload : 用来存放实际需要传递的数据
-
Signature(签名) :服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法(默认是 HMAC SHA256)生成。
JWT 通常是这样的:xxxxx.yyyyy.zzzzz
。
Header
Header 通常由两部分组成:
-
typ
(Type):令牌类型,也就是 JWT。 -
alg
(Algorithm) :签名算法,比如 HS256。
示例:
{
"alg": "HS256",
"typ": "JWT"
}
JSON 形式的 Header 被转换成 Base64 编码,成为 JWT 的第一部分。
Payload 也是 JSON 格式数据,其中包含了 Claims(声明,包含 JWT 的相关信息)。
Claims 分为三种类型:
-
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 唯一标识。
示例:
{
"uid": "ff1212f5-d8d1-4496-bf41-d2dda73de19a",
"sub": "1234567890",
"name": "John Doe",
"exp": 15323232,
"iat": 1516239022,
"scope": ["admin", "user"]
}
Payload 部分默认是不加密的,一定不要将隐私信息存放在 Payload 当中!!!
JSON 形式的 Payload 被转换成 Base64 编码,成为 JWT 的第二部分。
Signature 部分是对前两部分的签名,作用是防止 JWT(主要是 payload) 被篡改。
这个签名的生成需要用到:
-
Header + Payload。
-
存放在服务端的密钥(一定不要泄露出去)。
-
签名算法。
签名的计算公式如下:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出签名以后,把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(.
)分隔,这个字符串就是 JWT 。
在基于 JWT 进行身份验证的的应用程序中,服务器通过 Payload、Header 和 Secret(密钥)创建 JWT 并将 JWT 发送给客户端。客户端接收到 JWT 之后,会将其保存在 Cookie 或者 localStorage 里面,以后客户端发出的所有请求都会携带这个令牌。
简化后的步骤如下:
-
用户向服务器发送用户名、密码以及验证码用于登陆系统。
-
如果用户用户名、密码以及验证码校验正确的话,服务端会返回已经签名的 Token,也就是 JWT。
-
用户以后每次向后端发请求都在 Header 中带上这个 JWT 。
-
服务端检查 JWT 并从中获取用户相关信息。
两点建议:
-
-
请求服务端并携带 JWT 的常见做法是将其放在 HTTP Header 的
Authorization
字段中(Authorization: Bearer Token
)。
如何防止 JWT 被篡改?
有了签名之后,即使 JWT 被泄露或者解惑,黑客也没办法同时篡改 Signature 、Header 、Payload。
这是为什么呢?因为服务端拿到 JWT 之后,会解析出其中包含的 Header、Payload 以及 Signature 。服务端会根据 Header、Payload、密钥再次生成一个 Signature。拿新生成的 Signature 和 JWT 中的 Signature 作对比,如果一样就说明 Header 和 Payload 没有被修改。
不过,如果服务端的秘钥也被泄露的话,黑客就可以同时篡改 Signature 、Header 、Payload 了。黑客直接修改了 Header 和 Payload 之后,再重新生成一个 Signature 就可以了。