【SpringSecurity】九、Base64与JWT
文章目录
1、base64编码
base64是一种编码方式,不是加密方式。
所谓Base64,就是说选出64个字符:小写字母a-z、大写字母A-Z、数字0-9、符号"+“、”/“(再加上作为垫字的”=",实际上是使用65个字符),作为一个基本字符集。然后,其他文件(视频、文本、字符串…)里的所有符号都转换成这个字符集中的字符。
所谓的垫字的=号,即base64三个字节一分,最后不够分的时候拿等号占位一下,也就是说等号只能出现在末尾,且最多两个。(缺三字节那就是前面刚好够分,所以最多可能有两个==)
在Linux下,编码为:
echo -n 'Hello World' | base64SGVsbG8gV29ybGQ=
解码为:
echo -n 'SGVsbG8gV29ybGQ=' | base64 -dHello World
其中:
echo 命令带换行echo -n 即不换行输出
echo -n '{"alg":"HS256","typ":"JWT"}' | base64
以上是通过管道将echo的结果传给后面的指令,当然可以直接base64,配合Ctrl+D结束输入。
也可以对文件进行base64编码和解码:
#base64编码# base64 待编码的文件名 > 编码后的文件名base64 1.mp3 > mymp3 #打开就是一堆64个字符组成的文件
#base64 解码#base64 -d 待解码的文件名 >解码后的文件名base64 -d mymp3>88.mp3
2、Base64Url
Base64Url是一种在Base64的基础上编码形成新的编码方式,为了编码能在网络中安全顺畅传输,需要对Base64进行的编码,特别是互联网中。
Base64Url编码的步骤是:
- 明文使用BASE64进行编码
- 在Base64编码的基础上进行以下的处理
1)去除尾部的"=" 2)把"+"替换成"-" 3)斜线"/"替换成下划线"_"
3、JWT的产生背景
互联网服务离不开用户认证,基于session的流程是:
- 用户向服务器发送用户名和密码
- 服务器验证通过后,在当前对话(session)里面保存相关数据,比如用户角色、登录时间等等
- 服务器并向用户返回一个session_id,写入用户的cookie
- 用户随后的每一次请求,都会通过 Cookie,将 session_id 传回服务器
- 服务器收到 session_id,找到服务端前期保存的数据,由此得知用户的身份
这种模式的问题在于,扩展性(scaling)不好。单机当然没有问题,如果是服务器集群,或者是跨域的服务导向架构,就要求 session 数据共享,每台服务器都能够读取 session。
举例来说,A 网站和 B 网站是同一家公司的关联服务。现在要求,用户只要在其中一个网站登录,再访问另一个网站就会自动登录(单点登录),请问怎么实现?
解决方案一:服务端做session数据持久化
即服务端将写入数据库或别的持久层。各种服务收到请求后,都向这个持久层请求数据。这种方案的优点是架构清晰,缺点是工程量比较大。另外,持久层万一挂了,就会单点失败。
解决方案二:服务端不再保存 session 数据了,所有数据都保存在客户端
如JWT,服务器不存数据,客户端存,服务器解析就行了,解析出来JWT合法,则允许访问系统。
以上是JWT实现登录的原理图,即客户端认证通过后,被下发一个令牌,客户端发起请求时携带这个令牌,服务端可以通过算法和密钥进行令牌合法性校验,不再依赖数据库,Memcached的等存储系统,因此可以做到跨服务器验证,只要密钥和算法相同,不同服务器程序生成的Token可以互相验证通过。这就是JWT和session的区别,用JWT时,服务端啥也不用存,就做个校验。
直白讲就是服务端用解析 token 的计算时间换取 session 的存储空间,从而减轻服务器的压力,减少频繁的查询数据库。
4、JWT介绍
JSON Web Token
(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑且独立的方式,用于在各方之间作为JSON对象安全地传输信息。 此信息可以通过数字签名进行验证和信任。JWT可以使用密钥(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对进行签名。
相关文档:
- 官方网址:https://jwt.io/
- 调试页面:https://jwt.io/
- 学习文档:https://jwt.io/introduction/
JWT的主要用途有:
- 授权:一次登录后,后续请求携带token,校验合法的token,则允许访问系统的资源。JWT广泛应用于单点登录SSO(Single Sign On)上,因为其开销很小且可以在不同领域轻松使用
- 信息交换:JSON Web Token是一种在各方面之间安全信息传输的好的方式 因为JWT可以签名 - 例如,使用公钥/私钥对 - 您可以确定发件人是他们所说的人。 此外,由于使用标头和有效负载计算签名,您还可以验证内容是否未被篡改。
5、JWT组成
一个JWT由三部分组成,各部分以点分隔:xxxxx.yyyyy.zzzzz格式
Header(头部)
-----base64Url编码的Json字符串
Payload(载荷)
—base64url编码的Json字符串
Signature(签名)
—使用指定算法,通过Header和Playload加盐计算的字符串
举例:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
5.1 Header
头部由两部分组成:
- 1)token的类型,目前只能是JWT
- 2)签名算法,比如HMAC 、 SHA256 、 RSA
示例:
{ "alg":"HS256", "typ":"JWT"}
编码:
echo -n '{"alg":"HS256","typ":"JWT"}' | base64
得到的就是JWT的第一部分。
5.2 Payload
payload就像车厢,里面拉了很多东西,比如用户名。 payload(有效负载),其中包含claims(声明)。Claims是关于一个实体(通常是用户)和其他数据类型的声明。Claims又有三种类型:
- registered
- public
- private
1)
Registered(已注册的声明):这些是一组预定义声明,不是强制性的,但建议使用,以提供一组有用的,可互操作的声明。 其中一些是:iss(发行人),exp(到期时间),sub(主题),aud(观众)and others。(请注意,声明名称只有三个字符,因为JWT意味着紧凑。)
2)
Public(公开声明):这些可以由使用JWT的人随意定义。 但为避免冲突,应在IANA JSON Web Token Registry中定义它们,或者将其定义为包含防冲突命名空间的URI。
3)
private (私人声明):这些声明是为了在同意使用它们的各方之间共享信息而创建的,并且既不是注册声明也不是公开声明。
示例:{ "sub": "1234567890", "name": "John Doe", "admin": true}
5.3 Signature
Signature是用来保证数据安全的,是对前两部分head、payload的签名,防止数据篡改。首先,需要指定一个密钥(secret)。这个密钥只有服务器才知道
,不能泄露给用户。然后,使用 Header 里面指定的签名算法(默认是 HMAC SHA256),按照下面的公式产生签名:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出Signature值后,再把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(.)分隔,就可以返回给用户。这就是一个JWT值。
6、JWT的使用方式
客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage(本地存储)。此后,客户端每次与服务器通信,都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送,但是这样不能跨域,所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。即:
Authorization: Bearer jwt
另一种做法是,跨域的时候,JWT 就放在 POST 请求的数据体里面。
当放本地存储localStorage的时候,每次请求,需要前端同事从localStorage里取出来,放到请求头里,再请求后端的controller,controller中httpServletRequest.getHeader()从请求头里获取出来,然后校验合法性,合法则允许访问。
7、JWT的几个特点
- JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。
- JWT 不加密的情况下,不能将秘密数据写入 JWT。
- JWT 不仅可以用于认证,也可以用于交换信息。有效使用 JWT,可以降低服务器端查询数据库的次数。
JWT 的最大缺点是,由于服务器不保存 session 状态,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 JWT 签发了,在到期之前就会始终有效,除非服务器部署额外的逻辑(JWT的登出问题)。(后面再说redis)就是因为服务端无状态了,所以正常情况下, 修改了密码后就会跳转到登录页面重新登录,修改成功后清空浏览器保存的token了,重新认证,拿新的token(服务端无状态,改不了令牌)。JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。为了减少盗用,JWT 不应该使用 HTTP 80 协议明码传输,要使用 HTTPS 443 协议传输。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341