JSON Web Token(JWT)是一个开放的标准(RFC 7519),它定义了一个紧凑且自包含的方式,用于在各方之间作为 JSON 对象安全地传输信息。由于此信息是经过数字签名的,因此可以被验证和信任。
今天我们就来简单的认识一下 JSON Web Token。
JWT 认证和 session认证的区别
首先需要说明 JSON Web Token 是可以用于认证的,那么就先来对比一下 JSON Web Token 认证和 传统的 session 认证的区别,传统的 session 认证是有状态的,也就是说我们需要在服务端保存用户的认证信息,如果服务端重新或者换一台服务器,那么这个认证就失效了,并且传统的 session 的认证方式扩展起来不是那么的容易。
基于 JSON Web Token 的鉴权机制类似于 http 协议,是一种无状态的,服务器不需要保存用户的认证信息或者会话信息,这也就意味着 JWT 认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利,也是由于这个特性,JWT 在微服务架构中应用广泛。
JSON Web Token 的组成
一个 JSON Web Token 实际上就是一个字符串,它由三部分组成:头部、载荷与签名,如下图所示:
1、头部(header )
头部用于描述关于该 JSON Web Token 的最基本的信息,例如其类型以及签名所用的算法等,通常如下所示:
{
"alg": "HS256",
"typ": "JWT"
}
- alg属性:表示签名使用的算法,默认为HMAC SHA256(写为HS256)
- typ属性:表示令牌的类型,JWT令牌统一写为JWT
头部一般使用 base64 加密,加密后密文:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
2、载荷(payload)
载荷是 JSON Web Token 的主体内容部分,里面存放一些有效信息,JSON Web Token 标准定义中定义了以下 5 个字段:
- iss: 该JWT的签发者
- sub: 该JWT所面向的用户
- aud: 接收该JWT的一方
- exp(expires): 什么时候过期,这里是一个Unix时间戳
- iat(issued at): 在什么时候签发的
除了标准定义中的字段外,我们还可以自定义字段,比如在 JWT 中,我们的载荷信息可能如下:
{
"sub": "1234567890",
"name": "chongchong",
"admin": true
}
我们需要注意,在默认情况下 JWT 是未加密的,每一个人都可以读取其内容,因此在载荷中,不要存放私密信息,防止信息泄露。
3、签名(signature)
签名是 JSON Web Token 中比较重要的一部分,前面两部分都是使用 Base64 进行编码的,signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥,然后使用 header 中指定的签名算法(HS256)进行签名,签名的作用是保证 JWT 没有被篡改过。
为什么需要签名?
对于加密算法来说,碰撞概率还是比较小的,一般而言,不同的输入加密后的输出是不一样的,不同输入产生相同结果的概率还是相当小的,所以可以利用加密算法的这个特性来判断 JWT 是否被篡改过。
假如有人篡改了载荷中的信息,再进行编码的话,那么新的头部和载荷的签名跟之前的签名是不一样的,并且如何加密的密钥不一样的话,得出来的签名结果也会不一样。
JWT使用场景
- Authentication(鉴权)
这是使用JWT最常见的情况。 一旦用户登录,每个后续请求都将包含JWT,允许用户访问该令牌允许的路由,服务和资源。 单点登录是当今广泛使用JWT的一项功能,因为它的开销很小,并且能够轻松地跨不同域使用。
- Information Exchange(信息交换)
JSON Web Tokens是在各方之间安全传输信息的好方式。 因为JWT可以签名:例如使用公钥/私钥对,所以可以确定发件人是他们自称的人。 此外,由于使用标头和有效载荷计算签名,因此您还可以验证内容是否未被篡改。
以上就是 JSON Web Token 相关知识,希望这篇文章对您的学习或者工作有所帮助,如果您觉得文章有帮助,欢迎帮忙转发,谢谢。
最后
目前互联网上很多大佬都有 JSON Web Token 相关文章,如有雷同,请多多包涵了。原创不易,码字不易,还希望大家多多支持。若文中有所错误之处,还望提出,谢谢。
互联网平头哥(id:pingtouge_java)
作者:平头哥,学会伺机而动,实现弯道超车
共同学习,写下你的评论
评论加载中...
作者其他优质文章