前后端身份认证 -------session机制，JWT机制（jsonwebtoken）

godlike-icy

已于 2023-10-26 16:59:09 修改

阅读量667

点赞数 1

分类专栏： web前端文章标签： node.js

于 2022-03-28 21:32:05 首次发布

本文链接：https://blog.csdn.net/qq_43682422/article/details/123806830

版权

web前端专栏收录该内容

72 篇文章 3 订阅

订阅专栏

1. 前后端身份认证

1.1 Web开发模式

目前主流的Web开发模式有两种，分别是：
1）基于服务端渲染的传统web开发模式
2）基于前后端分离的新型web开发模式

服务端渲染web开发模式

服务端渲染的概念：
服务器发送给客户端的HTML页面是在服务器通过字符串的拼接动态生成的，因此客户端不需要使用Ajax这样的技术额外请求页面的数据。代码示例如下:

app.get('/index.html',(req,res)=>{
  //1.要渲染的数据
  const user = {name:'zs',age:20}
  //2.服务器通过字符串的拼接，动态生成HTML内容
  const html = `<h1>姓名:${user.name},年龄：${use.age}</h1>`
  //3.把生成好的页面内容响应给客户端，因此，客户端拿到的是带有真实数据的HTML页面
  res.send(html)
})

服务器端渲染的优缺点
优点：
1）前端耗时少。因为服务器负责动态生成HTML内容，浏览器只需要直接渲染页面即可，尤其是移动端，更省电。
2）有利于SEO。因为服务器端响应的是完整的HTML页面内容，所以爬虫更容易获得信息，更有利于SEO
缺点：
1）占用服务器端资源。即服务器完成HTML内容的拼接，如果请求较多，会对服务器造成一定的访问压力
2）不利于前后端分离，开发效率低。使用服务器端渲染则无法进行分工合作，尤其对前端复杂度高的项目，不利于项目高效开发

前后端分离web开发模式

前后端分离的概念：
前后端分离的开发模式依赖于Ajax技术的广泛应用。简而言之，前后端分离的Web开发模式就是后端只负责提供API接口，前端使用Ajax调用接口的开发模式。
前后端分离的优缺点
优点：
1）开发体验好，前端专注于UI页面的开发，后端专注于API的开发，且前端有更多的选择性
2）用户体验好，Ajax技术的广泛应用极大的提高了用户的体验，可以轻松实现页面的局部刷新
3）减轻了服务器的渲染压力，因为页面最终是在每个用户的浏览器中生成的
缺点：
1）不利于SEO，因为完整的HTML页面需要客户端动态拼接完成，所以爬虫队无法爬取页面的有效信息。（解决方案使用Vue、React等前端框架的SSR（server side render)技术能够很好的解决SEO问题)

如何选择Web开发模式

根据业务场景选择开发模式

企业级网站，主要功能是展示没有复杂的交互，并且需要良好的SEO，则这时我们就需要使用服务器端渲染。
而类似后台管理项目，交互性比较强，不需要考虑SEO，那么就可以使用前后端分离的开发模式。

另外，具体使用何种开发模式并不是绝对的，为了同时兼顾首页的渲染速度和前后端分离的开发效率，一些网站采用了首屏服务器渲染+其他页面前后端分离的开发模式。

1.2 Web身份认证

1.什么是身份认证？

身份认证(Authentication)又称’身份验证’,‘鉴权’,是指通过一定的手段,完成对用户身份的确认。

日常生活中，身份认证随处可见，例如高铁的验票乘车，手机密码或指纹解锁，支付宝或微信的支付密码等
在Web开发中也涉及到用户身份的认证，例如各大网站的手机验证码登录，邮箱密码登录，二维码登录等

2.为什么需要身份认证

身份认证的目的是为了确认当前所声称为某种身份的用户，确实是所声称的用户。例如你去找快递员取快递，你要怎么证明这份快递是你的。

互联网项目开发中如何对用户的身份进行认证是一个值得深入探讨的问题。例如如何才能保证网站不会错误的将马云的存款数据显示到马化腾的账户上。

1.3 不同开发模式下的身份认证

对于服务端渲染和前后端分离这两种开发模式来说，分别有着不同的身份认证方案

1）服务端渲染推荐使用Session认证机制
2）前后端分离推荐使用JWT认证机制

Session认证机制

HTTP协议的无状态性
了解HTTP协议的无状态性是进一步学习session认证机制的必要前提。

HTTP协议是无状态的，指的是服务器不会在不同的请求之间保留任何关于客户端的信息。每个HTTP请求都是独立的，服务器不会确保每个请求都来自同一个客户端。

这意味着服务器无法识别两个不同的请求是否来自同一个用户。例如，当一个用户发送多个请求给服务器时，服务器无法知道这些请求是来自同一个用户还是不同的用户。

为了保持会话的持续性，服务器需要使用一些机制来跟踪用户的状态，如使用cookie、session和其他技术来存储和检索用户相关的信息。这些机制可以使服务器在不同的请求之间保持用户状态，并提供个性化的服务

如何突破HTTP无状态的限制？
对于超市来说，为了方便收银员在进行结账时给VIP用户打折，超市可以为每个VIP用户发放会员卡

注意:现实生活中的会员卡身份认证方式在web开发的专业术语中叫做Cookie

什么是Cookie

Cookie是存储在用户浏览器中的一段不超过4KB的字符串。它由一个名称（name），一个值（value）和其他几个用于控制cookie有效期、安全性、使用范围的可选属性组成。

注意：不同域名下的cookie各自独立，每当客户端发起请求时，会自动把当前域名下所有未过期的cookie一同发送到服务器。

Cookie的极大特性：
1）自动发送
2）域名独立
3）过期时限
4） 4KB限制

Cookie在身份认证中的作用

客户端第一次请求服务器的时候，服务器通过响应头的形式向客户端发送一个身份认证的cookie，客户端会自动将cookie保存在浏览器中。
随后，当客户端浏览器每次请求服务器的时候，浏览器会自动将身份认证相关的cookie通过请求头的形式发送给服务器，服务器即可验明客户端的身份。

Cookie不具有安全性
由于cookie是存储在浏览器中的，而且浏览器提供了读写cookie的API，因此cookie很容易被伪造，不具有安全性，因此不建议服务器将重要的隐私数据通过cookie的形式发送给浏览器。
在HTTP协议中，cookie是一种用于在客户端和服务器之间传递数据的机制。它可以用来存储有关用户的信息，但并不适合存储隐私信息。

主要原因是cookie存储在客户端的浏览器中，可以被用户轻松地查看和修改。虽然可以对cookie进行加密和签名以增加安全性，但仍然存在被恶意用户篡改的风险。

另外，cookie还会被发送到服务器端，在每个请求中都会包含cookie数据。这可能导致隐私信息在网络中传输时被拦截或窃取。

为了保护用户的隐私和数据安全，应该避免在cookie中存储敏感隐私信息，例如密码、信用卡号码等。对于这些敏感信息，应该使用其他更安全的方式进行存储和传输，例如使用HTTPS协议进行加密的安全通道。

如果应用程序确实需要存储某些用户相关的信息，可以使用服务器端的session机制或其他安全的存储方案，以确保数据的隐私和安全。

注意：千万不要使用cookie存储重要且隐私的数据！比如用户的身份信息、密码等。

提高身份认证的安全性

举个例子：为了防止客户伪造会员卡，收银员在拿到客户出示的会员卡之后，可以在收银机上进行刷卡认证，只有收银机确认存在的会员卡才能被正常使用。

这种会员卡+刷卡认证的设计理念就是Session认证机制的精髓。

Session的工作原理

1.4 在Express中使用Session认证

安装express-session中间件，即可在项目中使用Session认证:

npm install express-session

配置 express-session 中间件
express-session 中间件安装成功以后，需要通过app.use()来注册session中间件，示例代码如下:

//1.导入session中间件
var session = require('express-session')

//2.配置session中间件
app.use(session({
  secret:'keyboard cat', //secret 属性的值可以为任意字符串
  resave:false,            //固定写法
  saveUninitialized:true   //固定写法
}))

这是一个在Node.js应用中使用session中间件的示例代码。session中间件用于在无状态的HTTP协议中实现会话管理。

在这个示例中，app.use函数用于将session中间件添加到应用中。session函数的参数是一个配置对象，其中包括以下属性：

secret：用于对session数据进行加密的密钥。可以是任意字符串，用于保证session数据的安全性。
resave：表示是否允许session数据在每次请求结束后重新保存到session存储中。设置为false表示不重新保存，这样可以减少不必要的IO操作，默认值为false。
saveUninitialized：表示是否允许将未初始化的session数据保存到存储中。设置为true表示保存未初始化的session数据，默认值为true。
通过配置这些属性，可以根据需要进行会话管理，例如控制session数据的安全性、减少IO操作以提高性能等。
3. 向Session中存数据
当express-session中间件配置成功后，即可通过req.session来访问和使用session对象，从而存储用户的关键信息：

app.post('api/login',(req,res)=>{
  //判断用户提交的登陆信息是否正确
  if(req.body.usename!=='admin'||req.body.password!=='000000'){
    return res.send({
      status:1,
      msg:'登陆失败'
    })
  }

  req.session.user = req.body   //将用户的信息存储到session中
  req.session.islogin = true  //将用户的登陆状态存储到Session中

  res.send({status:0,msg:'登陆成功'})
})

从Session中取数据
可以直接从req.session对象上获取之前存储的数据，示例代码如下:

app.get('api/username',(req,res)=>{
  //判断用户是否登陆
  if(!req.session.islogin){
    return res.send({
      status:1,
      msg:'fail'
    })
  }

  res.send({status:0,msg:'success',username:req.sesion.username})
})

清空session
调用req.session.destroy() 函数，即可清空服务器保存的session信息。

app.post('api/logout',(req,res)=>{
  //清空当前客户端对应的session信息
  req.session.destroy()
  res.send({status:0,msg:'退出登录成功'})
})

JWT认证机制

了解Session认证的局限性

session认证机制需要配合cookie才能实现，由于cookie默认不支持跨域访问，所以当涉及到前端跨域请求后端接口时候，
需要做很多额外的配置才能实现跨域session认证。

Session认证机制需要配合cookie是因为cookie提供了一种在客户端存储和传递会话标识符的方式。

在使用session认证机制时，服务器会为每个会话生成一个唯一的会话标识符（session ID），用于标识该会话的身份和状态。这个会话标识符需要在客户端和服务器之间进行传递，并且在每个后续的请求中进行验证。

使用cookie作为存储和传递会话标识符的机制具有以下优点：

方便性：通过将会话标识符存储在cookie中，无需手动在每个请求中附加会话标识符，浏览器会自动在每个请求中将cookie发送给服务器。

安全性：由于cookie是存储在客户端的，可以通过设置cookie的HttpOnly属性将其限制为只能通过HTTP协议访问，防止恶意脚本窃取会话标识符。

可靠性：cookie在浏览器和服务器之间进行自动传递，并且会在每个请求中自动包含在HTTP头中。这确保了会话标识符的可靠性和一致性。

尽管可以使用其他方式来存储和传递会话标识符，如在URL参数中或使用HTTP头字段，但这些方式都存在一些限制和安全性风险。因此，使用cookie作为会话标识符的存储和传递机制是最常用和推荐的方式。

注意：当前端请求后端接口不存在跨域问题的时候，推荐使用session身份认证机制。

什么是JWT

JWT（英文全称：JSON Web Token）是目前最流行的跨域认证解决方案。

SON Web Token (JWT)认证和session认证是两种不同的身份验证机制，它们有以下区别：

会话状态的存储位置：在session认证中，服务器会在服务器端存储会话状态，并为每个会话生成唯一的会话ID，通常将会话ID与服务器端的存储（如内存或数据库）关联起来。而在JWT认证中，会话状态是通过在客户端生成和签名的JWT令牌来存储，服务器不需要在服务器端存储会话状态。
扩展性和可伸缩性：由于session认证需要在服务器端存储会话状态，对于大型应用程序而言，需要处理大量的会话状态和存储，这可能会对服务器的性能和可扩展性产生负面影响。而JWT认证不需要在服务器端存储会话状态，仅需要进行签名验证，因此具有更好的扩展性和可伸缩性。
跨域支持：session认证通常需要依赖浏览器的cookie机制来存储和传递会话ID，这限制了会话认证在跨域请求时的使用。而JWT认证可以将令牌作为请求的一部分（如HTTP头或URL参数）进行传递，更容易实现跨域身份验证。
跨平台和分布式支持：JWT是一种基于标准的、可互操作的令牌格式，可以在不同的平台和系统之间进行传递和验证。这使得JWT认证在分布式系统和跨平台应用程序中更具可行性和灵活性。

综上所述，JWT认证适用于分布式、跨平台和可伸缩的应用程序，而session认证更适合于传统的、单一服务器的应用程序。选择使用哪种认证机制应根据具体的应用场景和需求来决定。

JWT工作原理

总结：用户的信息通过token字符串的形式保存在客户端浏览器中，服务器通过还原token字符串的形式来认证用户的身份。

JWT的组成部分
JWT 通常由三部分组成，分别是Header（头部）、Payload（有效荷载）、Signature（签名）。
三者之间使用英文的 ’ . '号分隔，格式如下：

Header.Payload.Signature

下面是JWT字符串的示例：

//差不多是下面这个样子，我乱输的
afrgrehsgfegdhdfgd.fesbefGDJNGKDNHDH.GASNJDKGMDNGGRDGKKffffffffggdfffffffffffffffsgsgs

JWT的三个部分各种代表的含义
JWT三个组成部分，从前到后分别是Header、Payload、Signature
其中：

Payload 部分才是真正的用户信息，它是用户信息经过加密之后生成的字符串。
Header 和 Signature 是安全相关的部分，只是为了保证Token的安全性。

JWT的使用方式
客户端接收到服务器返回的JWT之后，通常会将它存储在localStorage和sessionStorage中。
此后客户端每次与服务器通信都要带上这个JWT的字符串，从而进行身份认证，推荐的做法是把JWT放在在HTTP请求头的
Authorization字段中，格式如下：

Authorization : Bearer <token>

在Express中使用JWT

安装JWT相关的包
运行如下命令，安装如下两个JWT相关的包：

npm install jsonwebtoken express-jwt

其中：

jsonwebtoken 用于生成JWT字符串
express-jwt 用于将字符串解析还原生JSON对象

导入JWT相关的包

//1.导入用于生成JWT字符串的包
const jwt = require('jsonwebtoken')
//2.导入用于将客户端发送过来的JWT字符串解析还原成json对象的包
const expressJWT = require('express-jwt')

定义secret密钥

为了保证JWT字符的安全性，防止JWT字符串在网络传输过程中被别人破解，我们需要专门定义一个用于加密和解密的secret密钥：
建议将密钥命名位secretKey
1）当生成JWT字符串的时候，需要使用secret密钥对用户信息进行加密，最终得到加密好的JWT字符串
2）当把JWT字符串解析还原成JSON对象的时候，需要时候secret密钥进行解密

//3.secret 密钥的本质：就是一个字符串
const secretKey = 'itheima icy ^_^'

在登录成功后生成JWT字符串
调用 jsonwebtoken 包提供的sign() 方法，将用户的信息加密成JWT字符串，响应给客户端：

//登录接口
app.post('api/login',(req,res)=>{
  //...省略登录失败的代码
  //用户登陆成功之后，生成JWT字符串，荣国token属性响应给客户端
  res.send({
    status:200,
    message:'登陆成功',
    //调用jwt.sign()生成jwt字符串，三个参数分别是：用户信息对象，加密密钥，配置对象(可以配置token的有效期)
    token: jwt.sign({username:userinfo.username},secretKey,{expiresIn:'1h'})
  })
})

将jWT字符串还原为JSON对象
客户端每次在访问那些有权限接口的时候，都需要主动通过请求头中的Authorization字段，将Token字符串发送到服务器进行身份认证。
此时，服务器可以通过exprss-jwt这个中间件，自动将客户端发送过来的Token解析还原成json对象:

//使用 app.use() 注册中间件
//express.JWT({secret:secretKey})就是用来解析token的中间件
//.unless({path:[/^\/api]\//]}) 用来指定哪些接口不需要访问权限
//注意： 只要配置成功了 express-jwt 这个中间件，就可以把解析出来的用户信息，挂载到req.user属性上
//记住： 千万必要把密码加密到token字符串中
app.use(express.JWT({secret:secretKey}).unless({path:[/^\/api\//]}))

使用req.user 获取用户信息
当express-jwt 这个中间件配置成功之后，即可在那些有权限的接口中，使用req.user对象，来访问JWT字符串中解析出来的用户信息了，示例代码如下：

//这是一个有权限的API接口
app.get('/admin/getinfo'.function(req,res){
  console.log(req.user)
  res.send({
    status: 200,
    message:'获取用户信息成功'
    data: req.user
  })
})

捕获解析JWT失败后产生的错误

当使用express-jwt解析Token字符串时，如果客户端发送过来的token字符串过期或者不合法，会产生一个解析失败的错误，影响项目的正常
运行。我们可以通过Express的错误中间件，捕获这个错误并运行相关的处理，示例代码如下：

//全局的错误中间件，放在路由之后
app.use((err,req,res,next)=>{
  //token 解析失败的错误
  if(err.name === 'UnauthorizedError'){
    return res.send({status:401,message:'无效的token'})
  }
  //其他原因导致的错误
  res.send({status:500,message:'未知错误'})
})

不建议在JWT机制中存储用户密码。

JWT是用于身份验证和授权的令牌，它是基于JSON格式的，通常用于在客户端和服务器之间传递信息。然而，JWT令牌是经过签名的，而不是加密的，签名后的令牌可以被解码，但无法修改。

由于JWT令牌可以被解码，如果将用户密码存储在JWT令牌中，那么这些密码信息将对任何能够访问JWT令牌的人可见。这严重违反了安全性原则，因为密码应该始终保持机密，只能在需要时进行加密传输到服务器，并且应该在服务器端进行验证和存储。

对于JWT身份验证机制，应该将仅存储必要的用户信息（如用户ID、角色、权限等）在JWT令牌中，而不是存储敏感信息如密码。当需要进行身份验证时，服务器应该使用传输回来的JWT令牌进行验证，并从服务器的安全存储中获取与用户相关的信息进行比对。

总之，不要将用户密码存储在JWT令牌中。密码应该始终被视为敏感信息，并使用适当的加密和安全措施进行处理、传输和存储。
大事件项目
http://escook.cn:8088/#/
头条项目
http://doc.toutiao.liulongbin.top/

godlike-icy

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
前后端身份认证 -------session机制，JWT机制（jsonwebtoken）

1. 前后端身份认证1.1 Web开发模式目前主流的Web开发模式有两种，分别是：1）基于服务端渲染的传统web开发模式2）基于前后端分离的新型web开发模式服务端渲染web开发模式服务端渲染的概念：服务器发送给客户端的HTML页面是在服务器通过字符串的拼接动态生成的，因此客户端不需要使用Ajax这样的技术额外请求页面的数据。代码示例如下:app.get('/index.html',(req,res)=>{ //1.要渲染的数据 const user = {name
复制链接

扫一扫