侯体宗的博客
  • 首页
  • Hyperf版
  • beego仿版
  • 人生(杂谈)
  • 技术
  • 关于我
  • 更多分类
    • 文件下载
    • 文字修仙
    • 中国象棋ai
    • 群聊
    • 九宫格抽奖
    • 拼图
    • 消消乐
    • 相册

聊聊鉴权那些事(推荐)

前端  /  管理员 发布于 5年前   306

在系统级项目开发时常常会遇到一个问题就是鉴权,身为一个前端来说可能我们距离鉴权可能比较远,一般来说我们也只是去应用,并没有对权限这一部分进行深入的理解。

什么是鉴权

鉴权:是指验证用户是否拥有访问系统的权利。传统的鉴权是通过密码来验证的。这种方式的前提是,每个获得密码的用户都已经被授权。在建立用户时,就为此用户分配一个密码,用户的密码可以由管理员指定,也可以由用户自行申请。这种方式的弱点十分明显:一旦密码被偷或用户遗失密码,情况就会十分麻烦,需要管理员对用户密码进行重新修改,而修改密码之前还要人工验证用户的合法身份。 -- 节选自百度百科

上述简单扼要的说明了一下鉴权的概念,但是这也只是简单的鉴权,也是项目中最最常见的及安全形式了,但是对于后端鉴权又是如何去做的,我们仍是一无所知,一般来说对于后端来说,鉴权最长见的方式分为三种:

  • Session/Cookie
  • Token或Jwt
  • OAuth

这种授权方式是浏览器遵守http协议实现的基本授权方式,HTTP协议进行通信的过程中,HTTP协议定义了基本认证认证允许HTTP服务器对客户端进行用户身份证的方法。接下来就一一介绍一下这三种鉴权方式。

Session/Cookie

Cookie是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏览器实现的一种数据存储功能。Cookie由服务器生成,发送给浏览器,浏览器把Cookie以KV形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该Cookie发送给服务器。由于Cookie是存在客户端上的,所以浏览器加入了一些限制确保Cookie不会被恶意使用,同时不会占据太多磁盘空间,所以每个域的Cookie数量是有限的。

Cookie.js

const Http = require("http");const app = Http.createServer((req,res) => { if(req.url === "/favicon.ico"){  return; }else{  res.setHeader("Set-Cookie","cx=Segmentfault");  res.end("hello cookie"); };});app.listen(3000);

使用node Cookie.js运行上面代码,等程序启动后访问http://localhost:3000/,就可以看到hello cookie字样,这样的话就代表该服务已经启动了。若想查看到到我们所设置的Cookie,首先观察一下在Network中Response Headers中,可以看到我们所写的Set-Cookie属性,当我们访问http://localhost:3000/的时候,当浏览器接收到Set-Cookie这个属性的时候,浏览器会根据其内部约定,并在其浏览器内部对其cookie进行存储,打开浏览器控制台,在Application中找到Cookies中找到相对应的域名,就可以看到我们所设置的cookie值了。当在同域的情况下,当再次请求数据的时候浏览器会默认发送cookie在该请求中,一起发送给后端。为了证实上面的说法,刷新一下http://localhost:3000/页面,在控制台Network找到Request Headers中可以看到Cookie: cx=Segmentfault属性,既然发送给服务端之后,相应的在后端也是可以接收到该Cookie的,修改一下上面的例子:

const Http = require("http");const app = Http.createServer((req,res) => { if(req.url === "/favicon.ico"){  return; }else{  console.log("cookie",req.headers.cookie)  res.setHeader("Set-Cookie","cx=Segmentfault");  res.end("hello cookie"); };});app.listen(3000);

在接收到访问的时候,就可以接收到了cx=Segmentfault,如果说现在这份Cookie是一份加密的数据的话,里面包含一些用户信息,在通过前后端进行交互之后,当客户端再次请求服务端的时候,服务端拿到相对应的Cookie并对其进行解密,对其中用户的信息进行鉴权处理就可以了。

服务端通过Set-Cookie在Response Headers设置了一段加密数据,客户端接收到了其相对应的数据之后,浏览器对其进行存储,当可客户端再次发送请求的时候,会携带已有的Cookie在Request Headers中一并发送给服务端,服务端解密数据完成鉴权,由此可以得出Cookie是服务端存储在客服端的状态标志,再由客户端发送给服务端,由服务端解析。Cookie在使用中必须是同域的情况下才可以,一般常用的是在MVC这种开发形式中很常用。

说了半天Cookie,但是对于Session却只字未提,接下来就介绍一下Session,Session从字面上讲,就是会话。这个就类似于你和一个人交谈,你怎么知道当前和你交谈的是张三而不是李四呢?对方肯定有某种特征(长相等)表明他就是张三。Session也是类似的道理,服务器要知道当前发请求给自己的是谁。为了做这种区分,服务器就要给每个客户端分配不同的身份标识,然后客户端每次向服务器发请求的时候,都带上这个身份标识,服务器就知道这个请求来自于谁了。至于客户端怎么保存这个身份标识,可以有很多种方式,对于浏览器客户端,大家都默认采用Cookie的方式。

const Http = require("http");let session = {};const app = Http.createServer((req,res) => { const sessionKey = "uId"; if(req.url === "/favicon.ico"){  return; }else{  const uId = parseInt(Math.random() * 10e10);  const cookie = req.headers.cookie;  if(cookie && cookie.indexOf(sessionKey) !== -1){   let _uId = cookie.split("=")[1];   res.end(`${session[_uId].name} Come back`);  }  else{   res.setHeader("Set-Cookie",`${sessionKey}=${uId}`);   session[uId] = {"name":"Aaron"};   res.end("hello cookie");  } };});app.listen(3000);

代码中解析cookie只是用了和很简单的方式,只是为了完成Dome而已,在实际项目中获取cookie比这个要复杂很多。

Session/Cookie认证主要分四步:

  1. 服务器在接受客户端首次访问时在服务器端创建seesion,然后保存seesion(我们可以将seesion保存在内存中,也可以保存在redis中,推荐使用后者),然后给这个session生成一个唯一的标识字符串,然后在响应头中种下这个唯一标识字符串。
  2. 签名。这一步只是对sid进行加密处理,服务端会根据这个secret密钥进行解密。(非必需步骤)
  3. 浏览器中收到请求响应的时候会解析响应头,然后将sid保存在本地cookie中,浏览器在下次http请求的时候,请求头中会带上该域名下的cookie信息,
  4. 服务器在接受客户端请求时会去解析请求头cookie中的sid,然后根据这个sid去找服务器端保存的该客户端的session,然后判断该请求是否合法。

利用服务器端的session和浏览器端的cookie来实现前后端的认证,由于http请求时是无状态的,服务器正常情况下是不知道当前请求之前有没有来过,这个时候我们如果要记录状态,就需要在服务器端创建一个会话(seesion),将同一个客户端的请求都维护在各自得会会话中,每当请求到达服务器端的时候,先去查一下该客户端有没有在服务器端创建seesion,如果有则已经认证成功了,否则就没有认证。

与redis结合使用:

const koa = require("koa");const session = require("koa-session");const redisStore = require("koa-redis");const redis = require("redis");const wrapper = require("co-redis");const app = new koa();const redisClient = redis.createClient(6379,"localhost");const client = wrapper(redisClient);// 类似于密钥app.keys = ["Aaron"];const SESSION_CONFIG = { // 所设置的session的key key:"sId", // 最大有效期 maxAge:8640000, // 是否防止js读取 httpOnly:true, // cookie二次签名 signed:true, // 存储方式 stroe:redisStore({client})};app.use(session(SESSION_CONFIG,app));app.use((ctx) => { redisClient.keys("*",(err,keys) => {  keys.forEach(key => {   redisClient.get(key,(err,val) => {    console.log(val);   });  }) }) if(ctx.path === "/favicon.ico") return; let n = ctx.session.count || 0; ctx.session.count = ++n; ctx.body = `第${n}次访问`});app.listen(3000);

虽然Session/Cookie可以解决鉴权问题,但是会有很大的问题,对于服务端来说说是一个巨大的开销,严重的限制了服务器扩展能力,比如说我用两个机器组成了一个集群,小F通过机器A登录了系统,那sessionId会保存在机器A上,假设小F的下一次请求被转发到机器B怎么办?机器B可没有小F的sessionId,有时候会采用一点小伎俩:session sticky,就是让小F的请求一直粘连在机器A上,但是这也不管用,要是机器A挂掉了, 还得转到机器B去。那只好做session的复制了,把sessionId在两个机器之间搬来搬去,再好的服务器也经不起这样的折腾。

Token或Jwt

在计算机身份认证中是令牌(临时)的意思,在词法分析中是标记的意思。一般作为邀请、登录系统使用。现在前后端分离火热,Token混的风生水起,很多项目开发过程中都会用到Token,其实Token是一串字符串,通常因为作为鉴权凭据,最常用的使用场景是API鉴权。

客户端使用用户名跟密码请求登录服务端收到请求,去验证用户名与密码验证成功后,服务端会签发一个Token,再把这个Token发送给客户端客户端收到Token以后可以把它存储起来,比如放在Cookie里或者Local Storage里客户端每次向服务端请求资源的时候需要带着服务端签发的Token服务端收到请求,然后去验证客户端请求里面带着的Token,如果验证成功,就向客户端返回请求的数据

示例:

前端

Document
  • {{item}}

后端:

const Koa = require("koa");const jwt = require("jsonwebtoken");const jwtAuth = require("koa-jwt");const Router = require('koa-router'); // koa 路由中间件const bodyParser = require("koa-bodyparser");const cors = require("koa2-cors");const app = new Koa();const router = new Router();// 密钥const secret = "this is a secret";app.use(bodyParser());app.use(cors());router.post("/users/login/token",(ctx) => { const {body} = ctx.request; const {username} = body; ctx.body = {  code:1,  message:"登陆成功",  body:{  username  },  token:jwt.sign({   data:body,   exp:Math.floor(Date.now() / 1000) + 60 * 60,  },secret) }});router.post("/users/logout",(ctx) => { const {body} = ctx.request; ctx.body = {  code:1,  message:"退出成功" }})router.get("/users/get/user/info",jwtAuth({secret}),(ctx) => { // jwtAuth token参数 console.log(ctx.state.user.data) ctx.body = {  code:1,  message:"成功",  data:ctx.state.user.data }})app.use(router.routes());app.listen(3000);

上面代码用到了很多的依赖模块,最关键的的是jsonwebtoken和koa-jwt,这两个模块一个是用来对token进行加密,一个是用来对数据进行解密的,同时在每次访问需要保护的路由的时候需要使用jwtAuth对其进行拦截处理,jwtAuth会根据其secret进行数据解密,把解密的数据存放到ctx.state中,供用户读取。

有关jwt相关请查看深入理解令牌认证机制详细的解释了其加密后数据token的构成。

加密后的数据主要分为三个部分机密头部、载荷、数据如果我们想查看其加密前内容是什么样子的,可以通过base64对其没一部分进行解密。

  • 机密头部:声明加密规则,可反解
  • 载荷:数据信息,也就是我们需要加密的信息,可反解
  • 验证:这部分是对前两部分使用hash算法的摘要,是不可逆的

在使用jsonwebtoken时需要注意的是,由于加密信息是可以反解的所以,尽量不要在加密数据中存放敏感信息,比如用户的密码,用户私密信息等等(千万不要效仿Dome,这是不对的O(∩_∩)O)。同过上面所述,所传递给前端的token一旦发生变化,仅仅是一个字母大小写发生变化也是不行的,当服务端接收到token解密时,是无法正确解密的,这种token可以是发篡改的。如果想要篡改token必须要有其secret才可以对其进行篡改和伪造。

OAuth

OAuth(开放授权)是一个开放标准,允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容,为了保护用户数据的安全和隐私,第三方网站访问用户数据前都需要显式的向用户征求授权。我们常见的提供OAuth认证服务的厂商有支付宝,QQ,微信。

OAuth协议又有1.0和2.0两个版本。相比较1.0版,2.0版整个授权验证流程更简单更安全,也是目前最主要的用户身份验证和授权方式。

OAuth认证主要经历了如下几步:

  • 需要第三方应用存储资源所有者的凭据,以供将来使用,通常是明文密码。
  • 需要服务器支持密码身份认证,尽管密码认证天生就有安全缺陷。
  • 第三方应用获得的资源所有者的受保护资源的访问权限过于宽泛,从而导致资源所有者失去对资源使用时限或使用范围的控制。
  • 资源所有者不能仅撤销某个第三方的访问权限而不影响其它,并且,资源所有者只有通过改变第三方的密码,才能单独撤销这第三方的访问权限。
  • 与任何第三方应用的让步导致对终端用户的密码及该密码所保护的所有数据的让步。

简单概括,就是用于第三方在用户授权下调取平台对外开放接口获取用户相关信息。OAuth引入了一个授权环节来解决上述问题。第三方应用请求访问受保护资源时,资源服务器在获准资源用户授权后,会向第三方应用颁发一个访问令牌(AccessToken)。该访问令牌包含资源用户的授权访问范围、授权有效期等关键属性。第三方应用在后续资源访问过程中需要一直持有该令牌,直到用户主动结束该次授权或者令牌自动过期。

总结

授权方式多种多样,主要还是要取决于我们对于产品的定位。如果我们的产品只是在企业内部使用,token和session就可以满足我们的需求,现在前后端分离如此火热jwt认证方式更加适合。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

您可能感兴趣的文章:

  • Vue中axios的封装(报错、鉴权、跳转、拦截、提示)
  • thinkjs微信中控之微信鉴权登陆的实现代码
  • 前后端常见的几种鉴权方式(小结)
  • Java中使用JWT生成Token进行接口鉴权实现方法
  • koa2服务端使用jwt进行鉴权及路由权限分发的流程分析
  • 详解用JWT对SpringCloud进行认证和鉴权
  • 详解nuxt路由鉴权(express模板)
  • Node.js Koa2使用JWT进行鉴权的方法示例
  • nuxt框架中路由鉴权之Koa和Session的用法
  • 一步步教会你微信小程序的登录鉴权
  • springmvc用于方法鉴权的注解拦截器的解决方案代码


  • 上一条:
    Mac电脑因出现问题而重新启动请按一下怎么解决?附解决方法
    下一条:
    深入理解令牌认证机制(token)
  • 昵称:

    邮箱:

    0条评论 (评论内容有缓存机制,请悉知!)
    最新最热
    • 分类目录
    • 人生(杂谈)
    • 技术
    • linux
    • Java
    • php
    • 框架(架构)
    • 前端
    • ThinkPHP
    • 数据库
    • 微信(小程序)
    • Laravel
    • Redis
    • Docker
    • Go
    • swoole
    • Windows
    • Python
    • 苹果(mac/ios)
    • 相关文章
    • 使用 Alpine.js 排序插件对元素进行排序(0个评论)
    • 在js中使用jszip + file-saver实现批量下载OSS文件功能示例(0个评论)
    • 在vue中实现父页面按钮显示子组件中的el-dialog效果(0个评论)
    • 使用mock-server实现模拟接口对接流程步骤(0个评论)
    • vue项目打包程序实现把项目打包成一个exe可执行程序(0个评论)
    • 近期文章
    • 智能合约Solidity学习CryptoZombie第三课:组建僵尸军队(高级Solidity理论)(0个评论)
    • 智能合约Solidity学习CryptoZombie第二课:让你的僵尸猎食(0个评论)
    • 智能合约Solidity学习CryptoZombie第一课:生成一只你的僵尸(0个评论)
    • 在go中实现一个常用的先进先出的缓存淘汰算法示例代码(0个评论)
    • 在go+gin中使用"github.com/skip2/go-qrcode"实现url转二维码功能(0个评论)
    • 在go语言中使用api.geonames.org接口实现根据国际邮政编码获取地址信息功能(1个评论)
    • 在go语言中使用github.com/signintech/gopdf实现生成pdf分页文件功能(0个评论)
    • gmail发邮件报错:534 5.7.9 Application-specific password required...解决方案(0个评论)
    • 欧盟关于强迫劳动的规定的官方举报渠道及官方举报网站(0个评论)
    • 在go语言中使用github.com/signintech/gopdf实现生成pdf文件功能(0个评论)
    • 近期评论
    • 122 在

      学历:一种延缓就业设计,生活需求下的权衡之选中评论 工作几年后,报名考研了,到现在还没认真学习备考,迷茫中。作为一名北漂互联网打工人..
    • 123 在

      Clash for Windows作者删库跑路了,github已404中评论 按理说只要你在国内,所有的流量进出都在监控范围内,不管你怎么隐藏也没用,想搞你分..
    • 原梓番博客 在

      在Laravel框架中使用模型Model分表最简单的方法中评论 好久好久都没看友情链接申请了,今天刚看,已经添加。..
    • 博主 在

      佛跳墙vpn软件不会用?上不了网?佛跳墙vpn常见问题以及解决办法中评论 @1111老铁这个不行了,可以看看近期评论的其他文章..
    • 1111 在

      佛跳墙vpn软件不会用?上不了网?佛跳墙vpn常见问题以及解决办法中评论 网站不能打开,博主百忙中能否发个APP下载链接,佛跳墙或极光..
    • 2016-10
    • 2016-11
    • 2017-06
    • 2017-07
    • 2017-08
    • 2017-09
    • 2017-10
    • 2017-11
    • 2018-03
    • 2018-04
    • 2018-05
    • 2018-06
    • 2018-09
    • 2018-11
    • 2018-12
    • 2019-02
    • 2020-03
    • 2020-04
    • 2020-05
    • 2020-06
    • 2021-04
    • 2021-05
    • 2021-07
    • 2021-08
    • 2021-09
    • 2021-10
    • 2021-11
    • 2022-08
    • 2022-09
    • 2022-10
    • 2022-11
    • 2022-12
    • 2023-01
    • 2023-02
    • 2023-03
    • 2023-04
    • 2023-05
    • 2023-06
    • 2023-07
    • 2023-09
    • 2023-10
    • 2023-11
    • 2023-12
    • 2024-01
    • 2024-02
    • 2024-03
    • 2024-04
    Top

    Copyright·© 2019 侯体宗版权所有· 粤ICP备20027696号 PHP交流群

    侯体宗的博客