代码编织梦想

鉴权

鉴权(Authentication) 在信息安全领域是指对于一个声明者所声明的身份权利,对其所声明的真实性进行鉴别确认的过程。

在it领域:校验session、cookie、token的合法性和有效性。

1、HTTP鉴权

允许客户端在请求时,通过用户名+密码的方式,实现对用户身份的验证。

⚠️注意:几乎所有的网站都不会走该认证方案,看看就好

过程

  1. 客户端向服务器请求一个受限的数据
  2. 服务器返回 HTTP/401 Unauthorized
  3. 客户端弹窗询问用户
  4. 客户端携带Base64格式的用户名+密码再次向服务器发送请求
  5. 服务端进行身份验证
  6. 校验成功,服务端返回状态码200给客户端(或校验失败,返回状态码403给客户端)

优点

  • 简单,基本的浏览器都支持

缺点

  • 不安全:基于HTTP传输,几乎是裸奔的,而且Base64解码也很容易
  • 无法主动注销:HTTP协议没有提供机制清楚浏览器中的Basic认证信息,除非关闭标签页、浏览器、清除历史记录

使用场景

  • 内部网络
  • 对安全要求不是很高的网络

2、Session-Cookie鉴权

Session-Cookie 认证是利用服务端的 Session(会话)和 浏览器(客户端) 的 Cookie 来实现的前后端通信认证模式。

何为Cookie?

为了让服务器区分不同的客户端,用Cookie告知服务器前后两个请求是否来自同一浏览器。

特点:

  1. Cookie存储在客户端,可随意修改,不安全
  2. 最大为4kb
  3. 有数量限制,对于一个网站不能超过20个Cookie,浏览器一般能存300个Cookie
  4. Cookie是不可跨域的,但是一级域名和二级域名是可以共享的(domain)

何为Session?

Session的抽象概念是会话,是无状态协议通信过程中,为了实现中断/继续操作,将用户和服务器之间的交互进行的一种抽象。

过程:

  1. 客户端:用户向服务器首次发请求
  2. 服务器:接受到数据并自动为该用户创建特定的Session/Session ID,来识别用户并跟踪该用户的会话过程
  3. 客户端:浏览器收到相应获取会话信息,并在下一次请求时带上Session/Session ID
  4. 服务器:服务器提取后会与本地保存的Session/Session ID进行对比找到该特定用户的会话,然后获取会话状态
  5. 至此客户端与服务器的通信变成有状态的通信

特点:

  1. Session保存在服务器
  2. 通过服务器自动的加密协议进行

与Cookie的差异:

  1. Session的安全性优于Cookie:因为Cookie存在客户端可以被篡改,而Session存在服务器,无法伪造
  2. 大小不同:Cookie的大小不超过4k
  3. 有效期不同:Cookie可设置为长时间保存,Session一般失效时间较短
  4. 存取值的类型不同:Cookie只支持字符串数据,Session可以存放任意数据类型

Session-Cookie鉴权过程

  1. 客户端:发送登录信息(用户名+密码)至服务器
  2. 服务器:校验用户名+密码
  3. 服务器:通过校验后生成Session ID,并保存在Session服务器中
  4. 服务器:返回数据给客户端,并Set-Cookie:PHPSESSID=sid
  5. 客户端:携带Cookie,向服务器请求资源
  6. 服务器:通过Session服务器校验Session
  7. Session服务器:校验成功
  8. 服务器:接口处理数据
  9. 服务器:返回正确的数据给客户端

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认证过程

  1. 客户端发送登录信息(用户名+密码)给服务器
  2. 服务器校验登录信息,生成一个加密的Token令牌,返回给客户端
  3. 客户端获取Token后,保存至本地
  4. 客户端再次请求API数据时,携带Token至服务器
  5. 服务器拿到Token后,做解密和签名校验
  6. 校验成功,服务器返回数据给客户端

Token的优点

  • 服务端无状态化、可扩展性好:Token机制在服务器不需要存储Session信息,本身就已包含了用户的相关信息
  • 安全性好:避免CSRF
  • 支持跨域访问

Token的缺点

  • 配合:需要前后端配合
  • 占带宽:正常情况下比sid更大,消耗更多流量,挤占更多带宽
  • 性能:需要加密解密Token,所以更耗性能
  • 有效期短:为了避免盗用,一般设置的有效期较短

由于Token有效期较短,所以就有了Refresh Token(刷新Token)

何为Refresh Token?

Token过期了,让用户重新登录获取Token会很麻烦,这个时候一个专门生成Access Token的Token就诞生了。Refresh Token的有效期可以长一些,通过独立服务和严格的请求方式增加安全性。由于不常验证,也可以如签名的Session一样处理。

Refresh Token认证过程

  1. 客户端:用户名+密码请求登录校验
  2. 服务器:收到请求,校验登录信息,成功后返回Access Token + Refresh Token 给客户端
  3. 客户端:将收到的Access Token + Refresh Toke存储在本地;再次请求API数据时,携带Access Token给服务器
  4. 服务器:验证Access Token有效:返回正常数据(无效:拒绝请求)
  5. 客户端Access Token过期:则重新传输Refresh Token给服务器
  6. 服务器Access Token过期:验证Refresh Token成功后,返回新Access Token给客户端
  7. 客户端:重新携带新的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认证过程差不多,只是不需要单独去查询数据库查找用户

  1. 客户端:发送登录信息(用户名+密码)
  2. 服务器:校验登录信息,使用密钥创建JWT;返回JWT给客户端
  3. 客户端:收到JWT后保存在本地;此后调用API携带JWT在请求头中
  4. 客户端:检查JWT是否有效,从JWT中获取用户信息,处理相关数据,返回数据给客户端

JWT的优点

  • 不需要在服务器保存会话信息,所以易于应用的扩展
  • JWT中Payload负载可以存常用信息,用于信息交换,有效地使用JWT可以避免多次查库

JWT的缺点

  • 加密问题:JWT默认是不加密的,但是也可以加密,生成原始Token之后,可以用密钥再加密一次
  • 到期问题:由于服务器不保存Session,因此无法在使用过程中废纸某个Token,或更改Token权限。也就是说,JWT一旦签发了,在到期时间之前都有效。

5、单点登录

随着企业的发展,一个大型系统里可能包含多个子系统,用户在操作不同系统时,需要多次登录,很麻烦,这时单点登录就能很好的解决这个问题。只需要登录一次,就可以访问其他相互信任的应用系统。

同域下的SSO(主域名相同)

当百度网站存在两个相同主域名下的贴吧子系统 tieba.baidu.com 和网盘子系统 pan.baidu.com 时,以下为他们实现 SSO 的步骤:

  1. 客户端:用户访问某个子系统时,如果没有登录,则跳转至SSO认证中心提供的登陆页进行登录
  2. 服务端:登录认证后,服务端把登录用户的信息存在Session中,并附加在相应头Set-Cookie字段中,设置Cookie的Domain为:.baidu.com
  3. 客户端:再次发请求时,携带主域名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端、手机端、服务端) 来进行配合才能达到登录成功的效果;

扫码登录的步骤详解 (待扫码阶段、待确认阶段、已确认阶段)

待扫码阶段:

  1. PC端:
    打开某个网站 (如taobao.com) 或者某个 APP (如微信) 的扫码登录入口;就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求;
  2. 服务端:
    服务器收到请求后,随机生成一个 UUID 作为二维码 ID,并将 UUID 与 PC 端的设备信息 关联起来存储在 Redis 服务器中,然后返回给 PC 端;同时设置一个过期时间,在过期后,用户登录二维码需要进行刷新重新获取。
  3. PC 端:
    收到二维码 ID 之后,将二维码 ID 以 二维码的形式 展示,等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态,直到登录成功。
    如果移动端未扫描,那么一段时间后二维码会自动失效。

已扫码待确认阶段:

  1. 手机端:
    打开手机端对应已登录的 APP (微信或淘宝等),开始扫描识别 PC 端展示的二维码;
    移动端扫描二维码后,会自动获取到二维码 ID,并将移动端登录的信息凭证(Token)和二维码 ID 作为参数发送给服务端,此时手机必须是已登录(使用扫描登录的前提是移动端的应用为已登录状态,这样才可以共享登录态)。

  2. 服务端:
    收到手机端发来的请求后,会将 Token 与二维码 ID 关联,为什么需要关联呢?因为,当我们在使用微信时,移动端退出时,PC 端也应该随之退出登录,这个关联就起到这个作用。然后会生成一个临时 Token,这个 Token 会返回给移动端,一次性 Token 用作确认时的凭证。

已确认阶段:

  1. 手机端:
    收到确认信息后,点击确认按钮,移动端携带上一步中获取的 临时 Token 发送给服务端校验。

  2. 服务端:
    服务端校验完成后,会更新二维码状态,并且给 PC 端生成一个 正式的 Token,后续 PC 端就是持有这个 Token 访问服务端。

  3. PC端:
    轮询到二维码状态为已登录状态,并且会获取到了生成的 Token,完成登录,后续访问都基于 Token 完成。

10、一键登录

一键登录能不能做,取决于运营商是否开放相关服务;随着运营商开放了相关的服务,我们现在已经能够接入运营商提供的 SDK 并付费使用相关的服务。

一键登录步骤详解:

  1. SDK 初始化: 调用 SDK 方法,传入平台配置的 AppKey 和 AppSecret
  2. 唤起授权页: 调用 SDK 唤起授权接口,SDK 会先向运营商发起获取手机号掩码的请求,请求成功后跳到授权页。授权页会显示手机号掩码以及运营商协议给用户确认。
  3. 同意授权并登录: 用户同意相关协议,点击授权页面的登录按钮,SDK 会请求本次取号的 Token,请求成功后将 Token 返回给客户端
  4. 取号: 将获取到的 Token 发送到自己的服务器,由服务端携带 Token 调用运营商一键登录的接口,调用成功就返回手机号码。服务端用手机号进行登录或注册操作,返回操作结果给客户端,完成一键登录。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_42224055/article/details/127223220

前端鉴权方式_ywltoread的博客-爱代码爱编程

四种常见的鉴权方式。 1.HTTP Basic Authentication:用的比较少,平常FTP登录是用的这种方式吧?感觉可以用在内部网系统。 2.session-cookie:这个在老的系统见得多,只适用于web系统。以前用java servlet写服务端时候,都会自动维护session,会在cookie写一个JSESSIONID的值。 3.T

关于前后端鉴权的几种方式-爱代码爱编程

关于前后端鉴权的几种方式 “ 人生亦有命,安能行叹复坐愁**”** 01 前言 最近看的比较多的方面都是关于计算机网络的内容,不得不说这个方面是真的很广泛,然后花了一些时间来了解一下如何实现前后端鉴权的方式,查阅了一下文章,也顺便写一下总结。 02 鉴权方式 前后之间进行数据交互,当然后端要判断你是否是真正的操作者,只有符合条件

抢先看GitHub的重大更新———Codespaces,可以在手机、平板直接进行开发的VS Code编辑器-爱代码爱编程

Github 最新推出的 Codespaces 可以实现基于 VS Code 的云端代码编译。云端开发不能更美好了,用上 Codespaces 后,不仅可以把 IDE 卸载掉,什么 Conda、Docker 都可以删了。 Codespace,它是在Azure上运行的基于浏览器的完整VS Code编辑器,可以像本地的IDE一样添加你喜爱的插件。这也意味着,你

前端常见的鉴权方式-爱代码爱编程

目前我们常用的鉴权有四种: HTTP Basic Authentication (HTTP基本认证)session-cookieToken 验证(包括JWT,SSO)OAuth(开放授权)HTTP Basic Authentication http1.0或1.1规范的客户端(如IE,FIREFOX)收到401返回值时,将自动弹出一个登录窗口,要求用户输

前端鉴权-爱代码爱编程

前端鉴权 前端权限的控制从本质上来说,就是控制前端视图层的展示和前端所发送的请求 ,但是只有前端权限控制没有后端权限控制是万万不可的,前端权限只是达到一个锦上添花的效果 前端权限的意义 1.降低非法操作的可能性 比如页面上的一个按钮,通过控制台改变按钮的属性,如果前端没有权限控制虽然点击了,但是不会有效果,如果有权限设置的话,没有权限的用户我们可以让

前端鉴权+如何处理权限列表-爱代码爱编程

前言 在写后台管理时,我们根据不同用户的权限,给用户展示不同的页面,后台定义用户的权限数据,前端进行获取,并渲染在侧边栏导航上,称为鉴权,这是页面级的鉴权,以及按钮级别的鉴权,那么如何编码呢? 思路: login(登录,所有人均可见) → 登录成功,获取权限 → 权限不同,侧边栏的数据展示不同 先定义一份公共的路由表,里面仅有一些公共的路由,如 l

鉴权html5服务器,前端鉴权知识学习-爱代码爱编程

1、Cookie 指某些网站为了辨别用户身份而储存在用户本地终端(Client Side)上的数据(通常经过加密)。 HTTP是一种无状态传输协议,它不能以状态来区分和管理请求和响应。也就是说,服务器单从网络连接上无从知道客户身份。于是给客户端发布一个通行证—cookie来区分,这就是Cookie的工作原理。 服务器通过response的set-

前端鉴权的几种方式-爱代码爱编程

1. Http basic Authorization 基于浏览器的一种鉴权方式。 1. 未授权请求,拦截,返回 401 Unauthorised 2. 支持的浏览器弹出用户名密码框,输入用户名密码,连同上次请求数据,一起发送到服务端 使用授权头,Authorization: Basic [base64]编码的用户名密码 3. 服务端验证通过,返回资源

vue项目中前端鉴权实现(菜单权限,按钮权限)-爱代码爱编程

这段时间比较忙,参与了公司一个新的B端项目的研发,从无到有搭建项目的过程中,遇到了关于项目鉴权的问题,和后端同事讨论了一下思路,自己也找了这方面的资料,整理如下文 权限管理分类: 1,菜单权限控制(页面级) 2,按钮权限控制(按钮级) 3,接口权限控制(url级别) 目前根据项目需求,实现了页面级和按钮级权限控制。 从实现思路来说,很

终于有人把前端鉴权讲明白了-爱代码爱编程

什么是鉴权 鉴权也叫身份认证,指验证用户是否有系统的访问权限。就很像我们经常乘坐动车的票据(对应的标识,一定的时间范围)。 认证方式 接下来介绍几种我们工作中通常用到的认证方式。 Session-Cookie 认证 利用服务端的 Session(会话)和浏览器(客户端)的 Cookie 来实现的前后端通信认证模式。 来源 由于 HTTP 请求

前端鉴权如何做-爱代码爱编程

登录接鉴权 用户名密码=>客户端=>/login=>服务端=>比对数据库=>数据库返回数据=>服务端=>返回数据=>给客户端 鉴权 基础鉴权,session/cookie,JWT,Oauth 算法加密 Base64,MD5/SHA-1,DES/AES ,RSA/ECC HTTPS SSL,HTTP劫持,

每天都在使用编辑器,language-service-protocol的工作原理到底是什么?-爱代码爱编程

language-service-protocol是什么 身为开发工程师,我们每天使用的最多的工具就是编辑器。在使用的过程中,有一些特定的功能,比如:为编程语言添加自动完成、转到定义、悬停文档等。传统上,必须为每个独立的开发工具重复这项工作,因为每个工具都提供不同的API来实现相同的功能。 language-service是为了提供特定语言智慧和通信协

前端鉴权、路由守卫_只想躺平的咸鱼的博客-爱代码爱编程

一、前端携带参数给后端的几种方法 ①查询参数?后面携带的 ②路径参数:后面携带的也就是我们常说的query的 ③请求头携带 ④请求体携带 axios({ method:'PUT', //路径参数 url:'/products/'+100, //查询参数(axios比较特殊) params:{ page:1,

vue3简单的前端权限路由实现(通过前端鉴权+侧边栏过滤)_前端筱攻城狮的博客-爱代码爱编程

首先是侧边栏根据不同的权限过滤,然后侧边栏能按照不同权限显示了。但是用户在url输入地址仍然能访问,所以需要鉴权 一.侧边栏过滤思路 1.通过路由的meta下的auth存储权限数组 const routes = [ { path: '/', redirect: isClient ? '/clientApp' : '/screen'