相关概念
认证与授权
认证(authentication )是验证你的身份的过程,而授权(authorization)是验证你有权访问的过程
用户认证的逻辑
- 获取用户提交的用户名和密码
- 根据用户名,查询数据库,获得完整的用户信息,包括真正的密码
- 比较提交的密码和查询到的密码
- 如果二者相等,则用户认证成功;否则用户认证失败
密码加密
加密与解密
加密
数据加密 的基本过程,就是对原来为 明文 的文件或数据按 某种算法 进行处理,使其成为 不可读 的一段代码,通常称为 “密文”。通过这样的途径,来达到 保护数据 不被 非法人窃取、阅读的目的。
解密
加密 的 逆过程 为 解密,即将该 编码信息 转化为其 原来数据 的过程。
加密算法
加密算法分 对称加密 和 非对称加密,其中对称加密算法的加密与解密 密钥相同,非对称加密算法的加密密钥与解密 密钥不同,此外,还有一类 不需要密钥 的 散列算法。
常见的 对称加密 算法主要有
DES
、3DES
、AES
等
常见的 非对称算法 主要有RSA
、DSA
等
散列算法 主要有SHA-1
、MD5
等。
对称加密
对称加密算法 是应用较早的加密算法,又称为 共享密钥加密算法。在 对称加密算法 中,使用的密钥只有一个,发送 和 接收 双方都使用这个密钥对数据进行 加密 和 解密。这就要求加密和解密方事先都必须知道加密的密钥。
常见算法:
- 数据加密过程:在对称加密算法中,数据发送方 将 明文 (原始数据) 和 加密密钥 一起经过特殊 加密处理,生成复杂的 加密密文 进行发送。
- 数据解密过程:数据接收方 收到密文后,若想读取原数据,则需要使用 加密使用的密钥 及相同算法的 逆算法 对加密的密文进行解密,才能使其恢复成 可读明文。
非对称加密
非对称加密算法,又称为 公开密钥加密算法。它需要两个密钥,一个称为 公开密钥 (public key
),即 公钥,另一个称为 私有密钥 (private key
),即 私钥。
常见算法:RSA
因为 加密 和 解密 使用的是两个不同的密钥,所以这种算法称为 非对称加密算法。
- 如果使用 公钥 对数据 进行加密,只有用对应的 私钥 才能 进行解密。
- 如果使用 私钥 对数据 进行加密,只有用对应的 公钥 才能 进行解密。
例子:甲方生成 一对密钥 并将其中的一把作为 公钥 向其它人公开,得到该公钥的 乙方 使用该密钥对机密信息 进行加密 后再发送给甲方,甲方再使用自己保存的另一把 专用密钥 (私钥),对 加密 后的信息 进行解密。
比较:
(1) 对称加密加密与解密使用的是同样的密钥,所以速度快,但由于需要将密钥在网络传输,所以安全性不高。
(2) 非对称加密使用了一对密钥,公钥与私钥,所以安全性高,但加密与解密速度慢。
(3) 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密,然后发送出去,接收方使用私钥进行解密得到对称加密的密钥,然后双方可以使用对称加密来进行沟通。
散列算法
一类 不需要密钥 的 散列算法。
常见算法:md5,
加盐
密码一般不会直接明文存储
会通过使用一定的算法,例如md5,进行加密存储
但是存在暴力破解的可能
解决方法:最终密码=其他+盐值+md5(明文密码+盐值)
大大提高了安全性
盐值:随机的一段字符串
- 密码加密——加盐算法(两种方式)_fiance111的博客-CSDN博客
协议
OAuth2
-
准备工作 | 微信开放文档 (qq.com)
用户登录状态的保存
HTTP 是一种不保存状态,即无状态(stateless)协议。
cookie
- 将状态保存在客户端
- 客户端访问服务端的登录接口
- 服务端根据请求的用户名和密码,认证用户,认证成功后,向响应中写入Cookie
//创建cookie
Cookie cookie = new Cookie("islegal","yes");
//设置cookie的访问路径(哪些请求路径可以访问cookie),默认所有都可以访问
cookie.setPath("/project1/checkServlet");
//设置生命周期,取值有三种:
//大于0,单位是秒;
//等于0,浏览器关闭
//小于0,-1 (默认)内存释放
cookie.setMaxAge(60*60);
resp.addCookie(cookie);
3. 客户端接收响应,并保存
- 用户再次请求的时候,就会携带cookie
- 服务端如果可以访问cookie,则可以从中取出数据
Cookie[] cookies = req.getCookies();
if(cookies!=null){
for (Cookie cookie : cookies) {
System.out.println(cookie.getName()+" "+cookie.getValue());
}
}
tip:
如何修改cookie?
新创建cookie,只要路径和cookie的名称一致,就可以修改cookie值
优缺点
session
基于服务端的状态保存
- 服务器会为每一次会话分配一个 Session对象
- 同一个浏览器发起的多次请求,同属于一次会话( Session)
流程:
- 首次使用到 Session时,服务器会自动创建 Session和JSeeisonID,并创建 Cookie用来存储 JSessionId发送回客户端,
- 下一次统一浏览器再次访问服务器的时候,就会通过cookie携带JSessionId,来获取原来的Session
- 作用域
- 一次会话(可能有多次请求,浏览器关闭,会话结束)有效
- 不同组件之间的session可以共享,java中有一块专门的内存保存session
钝化:指关闭服务器后,未关闭浏览器,存储在session中的数据会通过序列化存储在磁盘上
活化:指session中的数据被钝化过的浏览器未关闭,服务器重新启动并将存储在磁盘上的数据读取到session中
- session生命周期
//通过req获得session ,
//有一个boolean参数,默认true,没有则会创建一个新的会话;false如果没有回话,则不会创建
HttpSession session = request.getSession();
System.out.println(session.getId());
//保存数据
session.setAttribute("name","gao");
//获取数据
String name = (String)session.getAttribute("name");
//移除数据
session.removeAttribute("name");
//设置sesison的最大有效时间,单位秒
session.setMaxInactiveInterval(60*60);
//手动销毁
session.invalidate();
分布式
cookie
之前的方案都是在服务器端进行改造的,cookie方案是客户端的方案,就是把session信息保存到cookie中,即用户信息保存到cookie中,这样就不需要服务器保存session(用户信息)了。每次请求时,把此cookie传给服务器端,这样服务器端就知道是哪个用户了。
此方案比较实现比较简单,而且还不占用服务器端的内存资源。但是此方案的问题很大哦。
1、cookie在客户端是有限的,存储容量也是很小的
2、安全是很有问题的,因为保存在本地,很容易被人拿到
session复制
session复制是小型企业应用使用较多的一种服务器集群session管理机制,在真正的开发使用的并不是很多,通过对web服务器(例如Tomcat)进行搭建集群。
存在的问题:
session同步的原理是在同一个局域网里面通过发送广播来异步同步session的,一旦服务器多了,并发上来了,session需要同步的数据量就大了,需要将其他服务器上的session全部同步到本服务器上,会带来一定的网路开销,在用户量特别大的时候,会出现内存不足的情况
优点:
服务器之间的session信息都是同步的,任何一台服务器宕机的时候不会影响另外服务器中session的状态,配置相对简单
Tomcat内部已经支持分布式架构开发管理机制,可以对tomcat修改配置来支持session复制,在集群中的几台服务器之间同步session对象,使每台服务器上都保存了所有用户的session信息,这样任何一台本机宕机都不会导致session数据的丢失,而服务器使用session时,也只需要在本机获取即可
session绑定(黏贴)
我们利用nginx的反向代理和负载均衡,之前是客户端会被分配到其中一台服务器进行处理,具体分配到哪台服务器进行处理还得看服务器的负载均衡算法(轮询、随机、ip-hash、权重等),但是我们可以基于nginx的ip-hash策略,可以对客户端和服务器进行绑定,同一个客户端就只能访问该服务器,无论客户端发送多少次请求都被同一个服务器处理
缺点:
- 容易造成单点故障,如果有一台服务器宕机,那么该台服务器上的session信息将会丢失
- 前端不能有负载均衡,如果有,session绑定将会出问题
优点:
- 配置简单
redis:session集中管理
优缺点
session优点:
1.session中的信息存储在服务端,相比于cookie就在一定程度上加大了数据的安全性。
2.session数据存储在服务端,相比于jwt方便进行管理,也就是说当用户登录和主动注销,只需要添加删除对应的session就可以,这样管理起来很方便。
session缺点:
1.session存储在服务端,这就增大了服务器的开销,当用户多的情况下,服务器性能会大大降低。
3、因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。
4、用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
token
- 客户端请求服务端登录
- 服务端验证用户之后,返回响应的时候,生成一个token
- 常见生成token的方式就是JWT
- 客户端接收响应,并保存token到localStor age或sessionStorage
- 客户端下一次访问服务端的时候,就通过Header携带token
JWT
JSON Web Tokens
JWT 标准的 Token 有三个部分:
1.header(头部),头部信息主要包括(参数的类型–JWT,签名的算法–HS256)
2.poyload(负荷),负荷基本就是自己想要存放的信息(因为信息会暴露,不应该在载荷里面加入任何敏感的数据)
3.sign(签名),签名的作用就是为了防止恶意篡改数据
中间用点分隔开,并且都会使用 Base64 编码,所以真正的 Token 看起来像这样:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
Header
Header 部分主要是两部分内容,一个是 Token 的类型,另一个是使用的算法,比如下面类型就是 JWT,使用的算法是 HS256。
{
"typ" : "JWT",
"alg" : "HS256"
}
上面的内容要用 Base64 的形式编码一下,所以就变成这样:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
Payload 里面是 Token 的具体内容,这些内容里面有一些是标准字段,你也可以添加其它需要的内容。下面是标准字段:
iss:Issuer,发行者
sub:Subject,主题
aud:Audience,观众
exp:Expiration time,过期时间
nbf:Not before
iat:Issued at,发行时间
jti:JWT ID
比如下面这个 Payload,用到了 iss 发行人,exp 过期时间,另外还有两个自定义的字段,一个是 name ,还有一个是 admin 。
{
"iss" : "csdn.net",
"exp" : "201511205211314",
"name" : "维C果糖",
"admin" : true
}
使用 Base64 编码以后就变成了这个样子:
eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ
Signature
JWT 的最后一部分是 Signature ,这部分内容有三个部分,先是用 Base64 编码的 header 和 payload ,再用加密算法加密一下,加密的时候要放进去一个 Secret ,这个相当于是一个密钥,这个密钥秘密地存储在服务端。
header
payload
secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
HMACSHA256(encodedString, 'secret');
处理完成以后看起来像这样:
SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
客户端收到这个 Token 以后把它存储下来,下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ,然后进行验证,通过以后就会返回给客户端想要的资源。
服务端如何验证?
和生成signature的方式一样,然后比较signature是否一样文章来源:https://www.toymoban.com/news/detail-520556.html
优缺点
- 不需要在服务端保存会话信息,特别适用于分布式微服务。
- 自包含(Self-contained):负载中包含了所有用户所需要的信息,避免了多次查询数据库
- 简洁(Compact):可以通过URL, POST参数或者在HTTP header发送,因为数据量小,传输速度也很快
- 因为Token是以JSON加密的形式保存在客户端的,所以JWT是跨语言的,原则上任何web形式都支持。
安全问题
CSRF
-
- 35.CSRF_哔哩哔哩_bilibili
当网站使用cookie保存用户登陆状态时,可能受到恶意站点的诱导,在不知道的情况下下向目标网站发起敏感请求
csrf保护就是当向目标网站发起敏感请求时,要求携带csrf_token,这是一个客户端浏览器附带的伪随机数,通过恶意站点发送的请求不会携带这个数据
springsecurity默认开启csrf保护,对于put,post等方法(不包含get),要求请求时携带csrf_token,前后分离项目本来就是使用token,不必开启csrf的保护文章来源地址https://www.toymoban.com/news/detail-520556.html
框架
Spring Security
- Spring Security
- Spring Security Community :: Spring Security
Shrio
参考资料
- 认证 vs 授权 | Authing 文档
- Token的详细说明,看这一篇就够了 - 简书 (jianshu.com)
- JSON Web Token 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)
- 4种分布式session解决方案_断橋殘雪的博客-CSDN博客
- session-cookie,jwt状态保持的差异,以及优缺点_他们叫我浪浪的博客-CSDN博客
- 浅谈常见的七种加密算法及实现 - 知乎 (zhihu.com)
- 对称加密和非对称的加密 的优缺点和理解 - 知乎 (zhihu.com)
- 密码加密——加盐算法(两种方式)_fiance111的博客-CSDN博客
到了这里,关于【用户认证】密码加密,用户状态保存,cookie,session,token的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!