鉴权在信息安全领域是指对于一个声明者所声明的身份权利,对其所声明的真实性进行鉴别确认的过程
1、http鉴权
允许客户端在 请求时,通过用户名+密码的方式,实现对用户身份的验证
优点:
简单,基本的浏览器都支持
缺点:
不安全:基于http传输,几乎是裸奔的,而且base64解码也很容易
无法主动注销:http协议没有提供机制清除浏览器中的basic认证信息,除非关闭标签页、浏览器、清除历史记录
使用场景:
内部网络
对安全要求不是很高的网络
2、session-cookie鉴权
session-cookie认证是利用服务端的session(会话)和浏览器(客户端)的cookie来实现前后端通信认证模式
何为cookie?
为了让服务器区分不同的客户端,用cookie高职服务器前后两个请求是否来自同一浏览器。
特点:
- cookie存储在客户端,可随意修改,不安全
- 最大为4kb
- 有数量限制,对于一个网站不能超过20个cookie,浏览器一般能存300个cookie
- cookie是不可能跨域的,但是一级域名和二级域名是可以共享的
何为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 token存储在本地;再次请求API数据时,携带Access Token 给服务器
- 服务器:验证Access Token有效:返回正常数据(无效:拒绝请求)
- 客户端Access Token过期:则重新传输refresh token给服务器
- 服务器Access Token过期:验证Refresh Token成功后,返回新Access Token给客户端
- 客户端:重新携带新的Access Token请求API
token和session-cookie的区别
-
存储地不同:Session存在服务器;Token无状态的,一般前端来存储
-
安全性不同:Token安全性优于Session,因为每个请求都有签名还能防止监听
-
支持性不同:Session-Cookie需靠浏览器的Cookie机制实现,遇到原生NativaApp就不起作用了(或浏览器Cookie存储禁用);Token验证机制丰富了客户端类型
4、JWT(json web token)鉴权
什么是 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中Payload负载跨域存常用的信息,用于信息交换,有效地使用JWT可以避免多次查库
JWT缺点
加密问题:JWT默认是不加密的,但是也可以加密,生成原始token之后,可以用秘钥再加密一次
到期问题:由于服务器不保存session,因此无法在使用过程中废弃某个token,或更改token权限。也就是说,JWT一旦签发了,在到期时间之前都有效
5、单点登录
随着企业的发展,一个大型系统里可能包含多个子系统,用户在操作不同系统时,需要多次登录,很麻烦,这时单点登录就能很好的解决这个问题。只需要登录一次,就可以访问其他相互信任的应用系统。
同域下的SSO(主域名相同)
实现SSO的步骤:
- 客户端:用户访问某个子系统时,如果没有登录,则跳转至SSO认证中心提供的登录页进行登录
- 服务端:登录认证后,服务端把登录用户的信息存在session中,并附加在相应头Set-Cookie字段中,设置cookie的Domain为:
- 客户端:再次发请求时,
- 客户端:再次发请求时,携带主域名Domain下的Cookie发送给服务器,此时服务器就可以通过Cookie验证登录状态了
6、 OAuth 2.0
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调用运营商一键登录的接口,调用成功就返回手机号码。服务端用手机号进行登录或注册操作,返回操作结果给客户端,完成一键登录。