Cookie、Session、Token之间的区别到底在哪？

目录 

1.HTTP协议的无状态性

2.Cookie

2.1Cookie的安全性

3.Session

3.1基于Nodejs的Session用户认证的实现 

4.JWT(JSON Web Token)

4.1JWT的组成 

​4.2基于Nodejs的Token用户认证的实现 

在了解三者之间的区别之前，我们首先得清楚什么是HTTP协议的无状态性。

1.HTTP协议的无状态性

HTTP协议的无状态性就是指客户端每次的HTTP请求都是独立的，连续多个请求没有直接联系，服务器并不会保留客户端每次HTTP请求的状态。直白点来说，就是当你这次访问了服务器，然后关闭了客户端网页，再一次去访问服务器的时候，服务器是不知道又是你来访问的。那么问题来了，服务器都不知道是你访问，我们平时所浏览的网页为什么只需要登陆一次就可以在一段时间内一直保持登陆状态呢？所以我们就有了Cookie、Session、Token的产生，它们三的实现核心方式其实就是“存储”。

2.Cookie

Cookie是存储在用户浏览器中一段不超过4KB的字符串。它由一个名称(Name)、一个值(Value)和其他几个用于控制Cookie有效期、安全性、使用范围的可选属性组成。Cookie是不可以跨域加载的，这一点尤为重要，不同域名下的Cookie各自独立，每当客户端发起请求时，会自动把当前域名下未过期的Cookie同时全部发送给服务器,有效的防止了跨站请求伪造CSRF所产生的后果。

我们总结一下，Cookie有如下四大特性：

1. 自动发送
2. 域名独立
3. 过期时限
4. 4KB限制

下边详细讲解一下Cookie在身份认证中的流程：

• 当客户端第一次请求服务器时，服务器会通过响应头的形式，向客户端发送一个身份认证的Cookie
• 客户端收到服务器发送来的Cookie后，将Cookie保存在浏览器中
• 以后每次客户端浏览器请求服务器时，浏览器会自动将身份认证相关的Cookie,通过请求头的形式发送给服务器
• 服务器收到客户端请求时携带的Cookie后，服务器进行验证即可得到客户端身份

 2.1Cookie的安全性

Cookie真的是具有安全性的吗？我们首先举个例子：

小王在开放式阅览室上网，登录了某网站并且无意间勾选了七天免密登录，随后查阅完信息王明直接关闭了浏览器，没有清除浏览器Cookie缓存。随后，程序员小杜又使用了阅览室的这台电脑，而且翻看了浏览器历史记录，找到了小王之前登录过的网站，同时发现了当前登录用户是小王，此时小杜根据自己的专业知识熟练地打开浏览器的Cookie窗口，找到了Cookie中有类似于username和password的身份认证信息，并且经过一系列操作得到了明文的用户名和密码。此时，小王的身份认证信息就由于自己不良的上网习惯所泄露了。

所以Cookie不安全的根本原因是将用户身份认证信息保存在了客户端主机上，而客户端主机没有像服务器主机一样的防护级别，虽然浏Cookie的禁止跨域加载有效保障了Cookie不会被跨站请求伪造CSRF利用，但是却不能保证每个用户都能进行安全规范的操作。 

而且Cookie身份认证机制中，服务器端并没有记录生成Cookie的有效期，浏览器对Cookie有效期进行管理，浏览器中的Cookie又可以人为的进行修改，但是浏览器请求服务器时只会发送Cookie内容，不会发送Cookie有效期属性，这导致了服务器无法验证Cookie的有效期。

那么既然Cookie是不安全的，浏览器的身份认证应该如何实现呢？ 这里就产生了一种基于Cookie的改进的验证方式Session身份认证方式。

3.Session

Session身份认证方式是基于Cookie认证方式的改进 ：

1. 服务器不将用户名和密码等敏感信息作为Cookie发送给浏览器保存
2. 服务器会生成Cookie的有效期，不完全依赖浏览器对Cookie有效期进行管理

Session在身份认证中的流程如下：

• 客户端发送登录请求到服务器，服务器对登录请求中的用户名和密码进行身份认证，认证成功后，服务器将用户名和密码等信息以Session的名称保存在服务器本地内存或硬盘数据库中，并为其创造一个随机唯一串作为查询索引，我们将随机唯一串称为sessionid。
• 服务器将sessionid以及服务器中产生的Cookie有效期maxAge等作为响应头中Set-Cookie的值发送给浏览器保存
• 浏览器再次请求服务器，自动携带保存的未过期的Cookie(即sessionid和maxAge等）到HTTP请求头中
• 服务器收到请求，解析出请求头Cookie值（即sessionid和maxAge等），并基于sessionid到本地内存或硬盘数据库上查询对应的用户名和密码进行身份认证，认证成功，则继续业务处理。

这种认证方式中，服务端保存用户登录信息的数据称为Session,其索引值sessionid是经过加密产生的一段字符串，浏览器也只是保存的是这一串没有携带用户敏感信息的随机字符串，所以Session技术的安全性要比Cookie强。

sessionid的作用是，作为凭据交给浏览器端保存，解决了浏览器端cookie被破解后暴露出明文用户名密码的安全问题。sessionid还有一个作用就是，在服务器端，和session组成键值对，也可以理解为查找session的索引值。 

3.1基于Nodejs的Session用户认证的实现 

 首先，构建出最基本的前端登录界面login.html和登录成功界面index.html。

login.html：

  
  
  
  



  
  

    账号：
    密码：
    登录
  

  

index.html 

  
  
  
  



  首页

  退出登录

  

 服务端Nodejs代码：

这里我们一定要注意把静态页面使用中间件托管到服务器上，否则由于Cookie的禁止跨域访问（没有托管静态页面，本地打开的页面是基于file的本地传输协议，而基于Nodejs的服务端是HTTP协议，这样就已经算跨域了），浏览器会收不到服务端传回的sessionid的值；为了验证sessionid，我们引入了 “express-session”库辅助验证。

// 导入 express 模块
const express = require('express')
// 创建 express 的服务器实例
const app = express()
// 托管静态页面，防止跨域导致Sessionid传输失败
app.use(express.static('./pages'))
// 解析 POST 提交过来的表单数据
app.use(express.urlencoded({ extended: false }))

// TODO_01：请配置 Session 中间件
const session = require('express-session')
app.use(
  session({
    secret: 'Coding',        //服务端对Sessionid的签名
    name:"sessionID",    //浏览器端存储Sessionid的键名
    cookie:{maxAge:150000000},  //session有效期设置
    resave: false,
    saveUninitialized: true,
  })
)



// 登录的 API 接口
app.post('/api/login', (req, res) => {
  // 判断用户提交的登录信息是否正确
  //由于没有设置用户信息数据库，就简单设置两个变量作为登录验证值
  if (req.body.username == 'admin' && req.body.password == 'admin') {
      // TODO_02：请将登录成功后的用户信息，保存到 Session 中
  // 注意：只有成功配置了 express-session 这个中间件之后，才能够通过 req 点出来 session 这个属性
  req.session.user = req.body // 用户的信息
  req.session.islogin = true // 用户的登录状态
  console.log("服务端生成了新的Session对象：")
  console.log(req.session)
  console.log("当前的sessionid为：")
  console.log(req.sessionID)
  res.send({ status: 0, msg: '登录成功' })
  }
  else{
    return res.send({ status: 1, msg: '登录失败' })
  }


})

// 获取用户姓名的接口
app.get('/api/username', (req, res) => {
  // TODO_03：请从 Session 中获取用户的名称，响应给客户端
  if (!req.session.islogin) {
    return res.send({ status: 1, msg: 'fail' })
  }
  res.send({
    status: 0,
    msg: 'success',
    username: req.session.user.username,
  })
})

// 退出登录的接口
app.post('/api/logout', (req, res) => {
  // TODO_04：清空 Session 信息
  req.session.destroy()
  console.log(`当前服务器中保存的Session内容为: ${req.session}`)
  res.send({
    status: 0,
    msg: '退出登录成功',
  })
})

// 调用 app.listen 方法，指定端口号并启动web服务器
app.listen(80, function () {
  console.log('Express server running at http://127.0.0.1:80')
})

我们在登录页面，还未登录的时候，可以看到浏览器中没有保存服务器发送过来的sessionid的值：

当我们登录验证成功后，浏览器会保存服务端发送的sessionid值：

其中基于Nodejs的服务端输出为：

 在后续访问网页时，每次向服务器发送请求，都会在请求头自动携带上相应的Cookie值：

 在我们点击退出登录后，服务器的Session也会被清除掉，浏览器中的Cookie也会随着时间的流逝,按照其保存的Cookie有效期而自被删除：

4.JWT(JSON Web Token)

现在我们来思考这样一个问题，当一个web应用存在很多用户，且同一时间访问量如果暴增，一台服务器肯定支持不了这样繁忙的业务请求，所以就会有多台服务器将业务请求分摊到多个操作单元上进行执行，即我们熟知的负载均衡，但是Cookie又不支持跨域访问，Session认证机制又恰好需要配合Cookie才可以实现，当涉及前端跨域请求后端接口的时候，需要做非常多的额外配置才可以实现Session跨域认证，因此出现了一种最流行的跨域认证解决方案JWT(JSON Web Token)，一种Token的实现方式。

JWT的工作原理如下图所示：

 由上可知，用户的信息时通过Token字符串的形式保存在客户端浏览器中的，服务器中并没有保存信息，也从一方面缓解了负载均衡时需要不同服务器之间共享用户信息的麻烦。服务器是通过还原客户端请求时携带的Token字符串来认证用户身份的。

这里需要注意的是，客户端与服务器通信时，Token字符串放在HTTP请求头中的 Authorization 字段中格式如下所示：

//Token字符串前边一定要先加Bearer,否则服务器端无法解析Token字符串
Authorization: Bearer   

4.1JWT的组成 

 JWT通常是由三部分组成的，分别为Header(头部)、Payload(有效荷载)、Signature(签名)，三者之间是使用 “ . ”来进行分隔开的，即Header.Payload.Signature。

三部分包含信息如下：

• Header和Signature是安全性相关部分，代表加密算法和生成的签名部分
• Payload是保存用户信息部分，如用户名、有效期等，它是用户信息加密之和生成的字符串

4.2基于Nodejs的Token用户认证的实现 

 首先我们需要使用到如下两个包：

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

我们使用Postman模拟客户端访问，所以有如下为服务端代码：

// 导入 express 模块
const express = require('express')
// 创建 express 的服务器实例
const app = express()

// TODO_01：安装并导入 JWT 相关的两个包，分别是 jsonwebtoken 和 express-jwt
const jwt = require('jsonwebtoken')
const expressJWT = require('express-jwt')

// 允许跨域资源共享
const cors = require('cors')
app.use(cors())

// 解析 post 表单数据的中间件
const bodyParser = require('body-parser')
app.use(bodyParser.urlencoded({ extended: false }))

// TODO_02：定义 secret 密钥，建议将密钥命名为 secretKey
const secretKey = 'secret-111'

// TODO_04：注册将 JWT 字符串解析还原成 JSON 对象的中间件
// 注意：只要配置成功了 express-jwt 这个中间件，就可以把解析出来的用户信息，挂载到 req.user 属性上
// unless 表明某些某些路由不需要Token验证
app.use(expressJWT({ secret: secretKey }).unless({ path: [/^/api//] }))

// 登录接口
app.post('/api/login', function (req, res) {
  // 将 req.body 请求体中的数据，转存为 userinfo 常量
  const userinfo = req.body
  // 登录失败
  if (userinfo.username !== 'admin' || userinfo.password !== 'admin') {
    return res.send({
      status: 400,
      message: '登录失败！',
    })
  }
  // 登录成功
  // TODO_03：在登录成功之后，调用 jwt.sign() 方法生成 JWT 字符串。并通过 token 属性发送给客户端
  // 参数1：用户的信息对象
  // 参数2：加密的秘钥
  // 参数3：配置对象，可以配置当前 token 的有效期
  // 注意：千万不要把密码加密到 token 字符中，会有安全风险
  const tokenStr = jwt.sign({ username: userinfo.username }, secretKey, { expiresIn: '1h' })
  res.send({
    status: 200,
    message: '登录成功！',
    token: tokenStr, // 要发送给客户端的 token 字符串
  })
})

// 这是一个有权限的 API 接口
app.get('/admin/getinfo', function (req, res) {
  // TODO_05：使用 req.user 获取用户信息，并使用 data 属性将用户信息发送给客户端
  console.log(req.user)
  res.send({
    status: 200,
    message: '获取用户信息成功！',
    data: req.user, // 要发送给客户端的用户信息
  })
})

// 调用 app.listen 方法，指定端口号并启动web服务器
app.listen(3000, function () {
  console.log('Express server running at http://127.0.0.1:3000')
})

启动服务端监听后，使用Postman模拟浏览器登录发起POST请求，得到服务端登陆成功的返回信息,其中包含了Token字符串：

我们得到登录成功后返回的token字符串后，继续模拟浏览器发起GET请求访问其他接口，同时在请求头中的Authorization字段中携带得到的token字符串，并且服务器解析Token字符串得到用户身份信息：

那这样我们的Token用户认证就结束了吗？

我们设想，如果服务端在解析Token字符串时，发现客户端发送的Token字符串过期或者不合法，那么后端服务器代码会因此产生解析失败的错误，从而影响服务器的正常运行。我们此时就可以使用Express捕获错误的中间件，对这个错误进行捕获并处理，需要将如下代码段添加到所有路由之后即可防止以上错误发生时项目的运行奔溃：

// 使用全局错误处理中间件，捕获解析 JWT 失败后产生的错误
app.use((err, req, res, next) => {
  // 这次错误是由 token 解析失败导致的
  if (err.name === 'UnauthorizedError') {
    return res.send({
      status: 401,
      message: '无效的token',
    })
  }
  res.send({
    status: 500,
    message: '未知的错误',
  })
})

我们对刚刚获得的Token字符串进行部分修改，使用Postman模拟浏览器验证此段代码捕获Token解析失败错误的可行性，得到服务端正常捕获的错误信息：

以上就是本人对Cookie、Session、Token的理解，希望可以帮助到大家！！！

持续更新中......