文章目录
登录鉴权
概念
认证
- 用户名密码登录
- 邮箱发送登录链接
- 手机接收验证码
实现授权的方式
- cookie
- session
- token
- OAuth
凭证
- 实现认证和授权的前提是需要一种媒介标记访问者的身份
- token令牌可以表明身份
Cookie
如何工作
网页发HTTP请求时,浏览器会先检查是否有相应的cookie
,有则自动添加在request header
中的cookie
字段中。
作用
HTTP是无状态的协议,需要cookie或session保存状态,告知服务器前后两个请求是否来自同一浏览器
问题
存储在cookie
中的数据,每次都被浏览器自动放在HTTP请求中,若这些数据并不是每个请求都需要发给服务器的数据,浏览器设置自动处理便增加了网络开销;若这些数据是每个请求都需要携带的数据,浏览器设置自动处理就免去了重复添加操作。
因此,在cookie
中,最适合存放每次请求都要携带的数据(典型的就是身份认证信息)
cookie标准限制
每个域名下cookie大小最大为4 KB,每个域名下的cookie数量最多为20个
属性
expires|max-age
设置cookie什么时间内有效
- expires
expires=w,D M Y h:m:s GMT
表示cookie将在Y年M月D日h时m分s秒星期w之后失效,失效的cookie浏览器会清空- 未设置expires,默认有效期为session,即会话cookie,浏览器关闭后消失
- http1.0协议中的选项
- max-age
max-age=正数
cookie有效期为创建时刻+max-age
max-age=0
删除cookiemax-age=负数
cookie有效期为session
- http1.1协议中的选项,替代了expires
domain&path
domain是域名,path是路径,二者共同构成url,一起限制cookie能被哪些url访问
domain = 'd.com'; path='/p'
对于域名是d.com
或其子域为xxx.d.com/xxx.xxx.d.com
,且路径是/p
或子路径/p/xxx
,浏览器会将此cookie添加到该请求的cookie头部中- 未设置,domain默认值为该cookie的网页所在的域名;path默认值为设置该cookie的网页所在的目录
发送跨域请求时,即使url的域名和路径都满足cookie的domain和path,默认情况下cookie也不会自动添加到请求头部中
secure
设置cookie只在确保安全的请求中才会发送,当请求是HTTPS或其他安全协议时,包含secure选项的cookie才能被发送至服务器
document.cookie='key=value; secure'
当请求是安全协议的情况下,才会发送给服务器,在控制台还是可以看到该cookie的- 未设置,默认情况下cookie不会带secure选项。因此,默认情况下,不管是否为安全协议的请求,cookie都会被发送到服务器。
- 若在网页中通过js设置secure类型的cookie,必须保证网页是HTTPS协议的
HttpOnly
设置cookie是否能通过js访问,默认情况下,cookie不会带httpOnly选项,客户端可以通过js代码访问(读取、修改、删除等)该cookie
- HttpOnly只能通过服务端设置
- 限制客户端访问cookie,是为了保障安全。例如:某页面遭受XSS攻击时,有一段恶意脚本插到了网页中,该脚本通过
document.cookie
读取用户身份验证相关的cookie,并将这些cookie发送到攻击者的服务器,攻击者轻而易举地拿到用户验证信息
设置cookie
服务端设置
Set-Cookie=Path=/;Expires=Thu,01-Jan-1970 00:00:00 GMT;...
- 一个
set-cookie
只能设置一个cookie,设置多个cookie,需要添加多个set-cookie
字段 - 服务端可以设置cookie的所有选项:expires|domain|path|secure|HttpOnly
客户端设置
document.cookie='name=value;expire=...;secure'
- 一个
document.cookie
只能设置一个cookie,设置多个cookie,需要添加多个document.cookie
字段 - 客户端可以设置cookie的选项:expires|domain|path|secure(只能在HTTPS协议中设置成功)
修改删除cookie
修改cookie
path|domain选项保持一致,其他选项重新赋值,便能修改该cookie
删除cookie
path|domain选项保持一致,expires选项设置为一个过去的时间,或者max-age设置为负数,便能删除该cookie
跨域请求中的cookie
cookie作为一种credential信息(还有HTTP authentication schemes
),发生跨域时,默认情况下不会被传送给服务器。除非客户端手动设置xhr.withCredentials=true
,服务端必须允许request能携带认证信息,即在response header
中包含Access-Control-Allow-Credentials:true
,这样浏览器才会自动将cookie加在request header
中。并且,服务端不能将Access-Control-Allow-Origin
设置为*,而必须设置为请求页面的域名。
Session
session是另一种记录服务器和客户端会话状态的机制,基于cookie实现。session存储在服务器端,
sessionid
会被存储到客户端的cookie中
基于session的身份认证
浏览器向服务器发送登录请求时,服务器验证通过后,会将用户信息存入session中,服务器会生成一个sessionid
放入cookie中,返回给浏览器,浏览器再次发送请求时,会携带cookie,cookie中有sessionid
,会一并发送给服务器
弊端:数据量大,需要多个服务器支持时,一次登录,数据跨多个服务器时,需要重新登录认证
Session和Cookie的区别
session | cookie | |
---|---|---|
安全性 | 存储在服务器端,安全性较好 | 存储在客户端,安全性较差 |
存储类型 | 任意数据类型 | 字符串类型,其他类型的需要转换为字符串类型存储 |
有效期 | 客户端关闭或session超时会失效 | 设置过期时间,在此时间之前均有效 |
存储大小 | 存储量远高于cookie,但访问量过多,会占用服务器资源 | 单个cookie不超过4k |
Token
访问资源接口(API)时所需要的资源凭证
- 简单token组成
- uid 用户唯一身份标识
- time 当前时间戳
- sign 签名,token的前几位以哈希算法压缩成的一定长度的十六进制字符串
- 特点:
- 服务端无状态化、可扩展性好
- 支持移动端设备
- 安全
- 支持跨程序调用
基于token的身份认证
将各个应用程序与内存数据库redis相连,对登录成功的用户信息进行一定的算法加密,生成的ID称为token,将token以及用户信息存入redis;当用户再次发起请求时,将token和请求数据一并发送给服务器,服务器验证token是否存在redis中,如果存在,验证通过,不存在,告诉浏览器跳转到登录页面
好处:token保证了服务的无状态,所有信息都是存在分布式缓存中,基于分布式缓存,可以水平扩展支持高并发
Refresh Token
用于刷新access token的token。刷新access token时,不用用户输入用户名密码,客户端直接用refresh token更新access token,无需用户做额外操作)
Token和Session的区别
Token | Session | |
---|---|---|
概念 | 令牌,访问资源接口API时所需要的资源凭证 | 记录服务器端和客户端会话状态的机制 |
状态 | 使服务端无状态化 | 使服务器端有状态化 |
是否存储信息 | 不会存储会话信息 | 可以记录会话信息 |
安全性 | 安全性较好。每个请求都有签名,还能防止监听以及重放攻击 | 依赖链路层保证通信安全 |
适用范围 | 用户数据需要和第三方共享,允许第三方调用API接口时 | 需要实现有状态的会话时 |
JWT
- JSON Web Token(简称JWT)是目前最流行的跨域认证解决方案,是一种认证授权机制
基于JWT的身份认证
JWT全称JSON Web Token,前台在登录时,将用户信息发送给服务器,服务器将用户信息进行加密,返回JWT给前台,前台将其存到localStorage中,前台在axios中二次封装,拦截请求,后续发送请求时,在Authorization Header中携带上JWT,后台通过提前协商的密钥,解密JWT,验证用户信息,验证成功,响应请求数据,验证失败,返回登录页重新登录。
JWT和Token的区别
相同点:访问资源的令牌、记录用户的信息、使服务器端无状态化、验证成功后客户端才能访问服务端上受保护的资源
JWT | Token | |
---|---|---|
验证方式 | 将token和payload加密后存储于客户端,服务端使用密钥解密进行校验即可 | 服务端验证客户端发送过来的token时,需要查询数据库获取用户信息,然后验证token是否有效 |