鉴权
鉴权(Authentication) 在信息安全领域是指对于一个声明者所声明的身份权利,对其所声明的真实性进行鉴别确认的过程。
在it领域:校验session、cookie、token的合法性和有效性。
1、HTTP鉴权
允许客户端在请求时,通过用户名+密码的方式,实现对用户身份的验证。
⚠️注意:几乎所有的网站都不会走该认证方案,看看就好
过程
- 客户端向服务器请求一个受限的数据
- 服务器返回
HTTP/401 Unauthorized
- 客户端弹窗询问用户
- 客户端携带Base64格式的用户名+密码再次向服务器发送请求
- 服务端进行身份验证
- 校验成功,服务端返回状态码200给客户端(或校验失败,返回状态码403给客户端)
优点
缺点
- 不安全:基于HTTP传输,几乎是裸奔的,而且Base64解码也很容易
- 无法主动注销:HTTP协议没有提供机制清楚浏览器中的Basic认证信息,除非关闭标签页、浏览器、清除历史记录
使用场景
2、Session-Cookie鉴权
Session-Cookie 认证是利用服务端的 Session(会话)和 浏览器(客户端) 的 Cookie 来实现的前后端通信认证模式。
何为Cookie?
为了让服务器区分不同的客户端,用Cookie告知服务器前后两个请求是否来自同一浏览器。
特点:
- Cookie存储在客户端,可随意修改,不安全
- 最大为4kb
- 有数量限制,对于一个网站不能超过20个Cookie,浏览器一般能存300个Cookie
- Cookie是不可跨域的,但是一级域名和二级域名是可以共享的(domain)
何为Session?
Session的抽象概念是会话,是无状态协议通信过程中,为了实现中断/继续操作,将用户和服务器之间的交互进行的一种抽象。
过程:
- 客户端:用户向服务器首次发请求
- 服务器:接受到数据并自动为该用户创建特定的Session/Session ID,来识别用户并跟踪该用户的会话过程
- 客户端:浏览器收到相应获取会话信息,并在下一次请求时带上Session/Session ID
- 服务器:服务器提取后会与本地保存的Session/Session ID进行对比找到该特定用户的会话,然后获取会话状态
- 至此客户端与服务器的通信变成有状态的通信
特点:
- Session保存在服务器
- 通过服务器自动的加密协议进行
与Cookie的差异:
- Session的安全性优于Cookie:因为Cookie存在客户端可以被篡改,而Session存在服务器,无法伪造
- 大小不同:Cookie的大小不超过4k
- 有效期不同:Cookie可设置为长时间保存,Session一般失效时间较短
- 存取值的类型不同:Cookie只支持字符串数据,Session可以存放任意数据类型
Session-Cookie鉴权过程
- 客户端:发送登录信息(用户名+密码)至服务器
- 服务器:校验用户名+密码
- 服务器:通过校验后生成Session ID,并保存在Session服务器中
- 服务器:返回数据给客户端,并
Set-Cookie:PHPSESSID=sid
- 客户端:携带Cookie,向服务器请求资源
- 服务器:通过Session服务器校验Session
- Session服务器:校验成功
- 服务器:接口处理数据
- 服务器:返回正确的数据给客户端
Session-Cookie 的优点
- Cookie简单
- Session存在服务器,相较于JWT方便进行管理
- 只需后端操作,前端无感
Session-Cookie 的缺点
- 依赖Cookie,一旦浏览器禁用Cookie,就无法后续操作了
- 不安全,Cookie暴露在浏览器中,容易被盗用、CSRF攻击
- Session存粗在服务器,增大了服务器开销,用户量大的时候会降低性能
3、Token鉴权
Session-Cookie 的一些缺点,以及Session的维护给服务器造成的压力。然后我们又必须找个地方存放它,Token应运而生。
何为Token?
Token是一个令牌,客户端访问服务器时,验证通过后服务端会为其签发一张令牌,之后,客户端就可以携带令牌访问服务器,服务端只需言验证令牌的有效性即可。
Token的组成:
uid(用户唯一身份标识)+ time(当前的时间戳)+ sign(签名,token的前几位以hash算法压缩成的一定长度的十六进制字符串)
Token认证过程
- 客户端发送登录信息(用户名+密码)给服务器
- 服务器校验登录信息,生成一个加密的Token令牌,返回给客户端
- 客户端获取Token后,保存至本地
- 客户端再次请求API数据时,携带Token至服务器
- 服务器拿到Token后,做解密和签名校验
- 校验成功,服务器返回数据给客户端
Token的优点
- 服务端无状态化、可扩展性好:Token机制在服务器不需要存储Session信息,本身就已包含了用户的相关信息
- 安全性好:避免CSRF
- 支持跨域访问
Token的缺点
- 配合:需要前后端配合
- 占带宽:正常情况下比sid更大,消耗更多流量,挤占更多带宽
- 性能:需要加密解密Token,所以更耗性能
- 有效期短:为了避免盗用,一般设置的有效期较短
由于Token有效期较短,所以就有了Refresh Token
(刷新Token)
何为Refresh Token?
Token过期了,让用户重新登录获取Token会很麻烦,这个时候一个专门生成Access Token的Token就诞生了。Refresh Token的有效期可以长一些,通过独立服务和严格的请求方式增加安全性。由于不常验证,也可以如签名的Session一样处理。
Refresh Token认证过程
- 客户端:用户名+密码请求登录校验
- 服务器:收到请求,校验登录信息,成功后返回Access Token + Refresh Token 给客户端
- 客户端:将收到的Access Token + Refresh Toke存储在本地;再次请求API数据时,携带Access Token给服务器
- 服务器:验证Access Token有效:返回正常数据(无效:拒绝请求)
- 客户端Access Token过期:则重新传输Refresh Token给服务器
- 服务器Access Token过期:验证Refresh Token成功后,返回新Access Token给客户端
- 客户端:重新携带新的Access Token请求API
Token和Session-Cookie的区别
Token更像Session-Cookie的改良升级版
- 存储地不同:Session存在服务器;Token无状态的,一般前端来存储
- 安全性不同:Token安全性优于Session,因为每个请求都有签名还能防止监听
- 支持性不同:Session-Cookie需靠浏览器的Cookie机制实现,遇到原生NativaApp就不起作用了(或浏览器Cookie存储禁用);Token验证机制丰富了客户端类型
JWT(JSON Web Token)鉴权
使用Token鉴权的时候,不难发现,服务端验证需要每次去查询用户基本信息,再验证Token是否有效,都在增加查库带来的延迟等性能问题,这时候JWT就应运而生了。
何为JWT?
JWT 是 Auth0 提出的通过对 SON 进行加密签名来实现授权验证的方案。
登录成功后将相关信息组成JSON对象,并对它进行某种方式的加密返回给客户端,客户端在下次请求的时候带上这个Token,服务端会校验其合法性。
JWT的组成
- Header头部 :typ(Token的类型,JWT类型) + alg(Hash算法,‘HS256’)
- Payload负载:包含一些声明,用来存放实际需要传递的数据
- Signature签名:对上面两部分的签名,放篡改
中间用点(.)分隔三个部分,如下:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
JWT的使用方式
客户端收到服务器返回的JWT,可以存在Cookie里,也可以存在localStorage。
此后在请求API时,需要带上这个JWT。可以放在Cookie里自动发送,但是这样不能跨域,所以一般放在HTTP请求头信息Authorization字段里。
JWT认证过程
整体和Token认证过程差不多,只是不需要单独去查询数据库查找用户
- 客户端:发送登录信息(用户名+密码)
- 服务器:校验登录信息,使用密钥创建JWT;返回JWT给客户端
- 客户端:收到JWT后保存在本地;此后调用API携带JWT在请求头中
- 客户端:检查JWT是否有效,从JWT中获取用户信息,处理相关数据,返回数据给客户端
JWT的优点
- 不需要在服务器保存会话信息,所以易于应用的扩展
- JWT中Payload负载可以存常用信息,用于信息交换,有效地使用JWT可以避免多次查库
JWT的缺点
- 加密问题:JWT默认是不加密的,但是也可以加密,生成原始Token之后,可以用密钥再加密一次
- 到期问题:由于服务器不保存Session,因此无法在使用过程中废纸某个Token,或更改Token权限。也就是说,JWT一旦签发了,在到期时间之前都有效。
5、单点登录
随着企业的发展,一个大型系统里可能包含多个子系统,用户在操作不同系统时,需要多次登录,很麻烦,这时单点登录就能很好的解决这个问题。只需要登录一次,就可以访问其他相互信任的应用系统。
同域下的SSO(主域名相同)
当百度网站存在两个相同主域名下的贴吧子系统 tieba.baidu.com
和网盘子系统 pan.baidu.com
时,以下为他们实现 SSO 的步骤:
- 客户端:用户访问某个子系统时,如果没有登录,则跳转至SSO认证中心提供的登陆页进行登录
- 服务端:登录认证后,服务端把登录用户的信息存在Session中,并附加在相应头Set-Cookie字段中,设置Cookie的Domain为:
.baidu.com
- 客户端:再次发请求时,携带主域名Domain下的Cookie发送给服务器,此时服务器就可以通过Cookie验证登录状态了
6、OAuth 2.0
我们实际浏览网站时,除了输入用户名+密码之外,还有第三方的登录方式,比如:微信、QQ,这时候就要谈到OAuth了。
OAuth 协议又有 1.0 和 2.0 两个版本,2.0 版整个授权验证流程更简单更安全,也是目前最主要的用户身份验证和授权方式。
何为OAuth 2.0?
OAuth是一个开放标准,允许用户授权第三方网站(CSDN等)访问他们存储在另外的服务器提供的信息,而不需要将用户名密码提供给第三方网站。
常见的提供 OAuth 认证服务的厂商: 支付宝、QQ、微信、微博
OAuth就是一种授权机制,数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌Token,用来代替密码,供第三方应用使用。
令牌与密码的差异:
- 令牌是短期的,到期会自动失效:用户自己无法修改,密码一般长期有效,用户不修改
- 令牌可以被数据所有者撤销,会立即失效
- 令牌有权限范围scope
7、联合登录和信任登录
联合登录指同时包含多种凭证校验的登录服务,同时,也可以理解为使用第三方凭证进行校验的登录服务。
通俗点讲: 对于两个网站 A 和 B,在登录 A 网站的时候用 B 网站的帐号密码,就是联合登录,或者登录 B 网站的时候使用 A 网站的帐号密码,也是联合登录。
信任登录是指所有不需要用户主动参与的登录,例如建立在私有设备与用户之间的绑定关系,凭证就是私有设备的信息,此时不需要用户再提供额外的凭证。信任登录又指用第三方比较成熟的用户库来校验凭证,并登录当前访问的网站
通俗点讲: 在 A 网站有登录状态的时候,可以直接跳转到 B 网站而不用登录,就是信任登录。
8、唯一登录
唯一登录,指的是禁止多人同时登录同一账号,后者的登录行为,会导致前者掉线。
用户在客户端 A 操作:
- 输入账号请求登录接口
- 后端生成对应 Token 并且返回给客户端 A,并且在服务端保存一个登录状态
- 客户端A 保存 Token,并且每次请求都在 header 头中携带对应的 Token
用户在客户端 B 操作:
突然用户在客户端 B 上开始登录操作,我们会发现,步骤和在客户端A上面的操作几乎是一致的
只是后端在生成新的 Token 时,要先验证登录状态,然后再生成对应新的 Token
9、扫码登录
二维码又称二维条码,常见的二维码为 QR Code,QR 全称 Quick Response,是一个近几年来移动设备上超流行的一种编码方式,它比传统的Bar Code条形码能存更多的信息,也能表示更多的数据类型。
通过上面所述,我们不难发现,扫码登录需要三端 (PC端、手机端、服务端) 来进行配合才能达到登录成功的效果;
扫码登录的步骤详解 (待扫码阶段、待确认阶段、已确认阶段)
待扫码阶段:
- PC端:
打开某个网站 (如taobao.com) 或者某个 APP (如微信) 的扫码登录入口;就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求;
- 服务端:
服务器收到请求后,随机生成一个 UUID 作为二维码 ID,并将 UUID 与 PC 端的设备信息 关联起来存储在 Redis 服务器中,然后返回给 PC 端;同时设置一个过期时间,在过期后,用户登录二维码需要进行刷新重新获取。
- PC 端:
收到二维码 ID 之后,将二维码 ID 以 二维码的形式 展示,等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态,直到登录成功。
如果移动端未扫描,那么一段时间后二维码会自动失效。
已扫码待确认阶段:
-
手机端:
打开手机端对应已登录的 APP (微信或淘宝等),开始扫描识别 PC 端展示的二维码;
移动端扫描二维码后,会自动获取到二维码 ID,并将移动端登录的信息凭证(Token)和二维码 ID 作为参数发送给服务端,此时手机必须是已登录(使用扫描登录的前提是移动端的应用为已登录状态,这样才可以共享登录态)。
-
服务端:
收到手机端发来的请求后,会将 Token 与二维码 ID 关联,为什么需要关联呢?因为,当我们在使用微信时,移动端退出时,PC 端也应该随之退出登录,这个关联就起到这个作用。然后会生成一个临时 Token,这个 Token 会返回给移动端,一次性 Token 用作确认时的凭证。
已确认阶段:
-
手机端:
收到确认信息后,点击确认按钮,移动端携带上一步中获取的 临时 Token 发送给服务端校验。
-
服务端:
服务端校验完成后,会更新二维码状态,并且给 PC 端生成一个 正式的 Token,后续 PC 端就是持有这个 Token 访问服务端。
-
PC端:
轮询到二维码状态为已登录状态,并且会获取到了生成的 Token,完成登录,后续访问都基于 Token 完成。
10、一键登录
一键登录能不能做,取决于运营商是否开放相关服务;随着运营商开放了相关的服务,我们现在已经能够接入运营商提供的 SDK 并付费使用相关的服务。
一键登录步骤详解:
- SDK 初始化: 调用 SDK 方法,传入平台配置的 AppKey 和 AppSecret
- 唤起授权页: 调用 SDK 唤起授权接口,SDK 会先向运营商发起获取手机号掩码的请求,请求成功后跳到授权页。授权页会显示手机号掩码以及运营商协议给用户确认。
- 同意授权并登录: 用户同意相关协议,点击授权页面的登录按钮,SDK 会请求本次取号的 Token,请求成功后将 Token 返回给客户端
- 取号: 将获取到的 Token 发送到自己的服务器,由服务端携带 Token 调用运营商一键登录的接口,调用成功就返回手机号码。服务端用手机号进行登录或注册操作,返回操作结果给客户端,完成一键登录。