【前端理论】前端身份认证session与jwt

一、常见认证机制

1、基于Cookie+Seesion传统的认证机制

用户登录成功后，服务器开辟空间存储当前用户信息（session），并响应给浏览器一个 cookie：[自定义键名:用于获取session的唯一标识]，如：sessionId:"absd"；后续请求带上这个cookie，服务器根据cookie去找到对应的 session，获取到当前用户的信息；

• cookie特性：自动发送、域名独立、过期时限、4KB 限制；
• 用服务器存储Session的空间花费，换取认证的时间的缩短（用空间换时间）
• cookie 方式不安全，在浏览器可以被伪造，不能存储隐私数据；
• 在 express框架中使用 seesion 认证：

// 使用第三方中间件
npm i express-session
npm i connect-mongo // 做session持久化

const express = require('express')
const app = express()
// 使用session
const session = require('express-session')
// 持久化session
const MongoStore = require('connect-mongo')(session)
app.use(
  session({
    name: 'sessionID', // 空间编号的键名，也就是前端收到的cookie的名
    secret: 'zakopus', // 签名，用于给空间编号加密
    saveUninitialized: true, // 是否在存储内容之前创建session空间，默认true
    resave: false, // 是否在每次请求时，强制重新保存session
    store: new MongoStore({
      url: 'mongodb://localhost:27017/sessions_container', //存到这个数据库
      touchAfter: 24 * 3600, // 24小时存储一次
    }),
    cookie: {
      maxAge: 1000 * 60 * 30,
    },
  })
)
------
// 登录成功后将[_id键名：值]保存到session
req.session._id = data._id.toString()
// 访问个人中心时，取
const { _id } = req.session

2、基于Redis+Token的认证机制

1、客户端登录，输入用户名和密码登录成功后返给浏览器 token ，并将该 token 与用户信息存入redis（缓存数据库）；
2、前端手动将 token 设置在请求头中；不在借助 cookie 自动发送；

3、基于JWT（JSON WEB TOKEN）的认证机制

也是，用户登录成功返给浏览器一个token，不同的是此 token 中包含该用户的唯一标识信息（不是敏感信息），也是前端手动设置到请求头，服务器拿到后校验，通过后直接从token中获取当前用户信息；

• 解密jwt耗时，用时间换空间

二、总结

服务端渲染：推荐使用传统session认证；
前后端分离：推荐使用jwt认证；