再讲 Session 和 Token，彻底弄明白

 

 

前言

在构建用户身份管理系统时，选择会话（Session）还是令牌（Token）是一个关键决策，取决于系统的需求和特定的使用场景。本文将深入探讨何时适合使用会话，何时适合使用令牌，以帮助开发人员在实际应用中做出明智的选择。

什么是Session

众所周知，HTTP协议它是无状态的协议，浏览器多次请求服务器，服务器它无法感知是不是同一用户的请求，于是就有了Session机制。

Session机制是一种在Web开发中用于跟踪用户状态的机制。

• 它的基本工作流程是，当用户第一次请求Web服务器时，服务器会生成一个唯一的Session，并将其存储在服务器端（通常可以持久化到数据库中）。

• 然后，服务器通过响应头的方式将该Session的标识符（SessionID）返回给浏览器，并存储在浏览器的Cookie中。

• 随后的每一次请求，浏览器都会将携带该SessionID，服务器通过SessionID找到对应的Session，从而实现对用户状态的跟踪。

然而，Session机制在分布式部署下存在一定弊端，尤其是在负载均衡环境中容易导致会话验证失败。

什么是Token

为了解决Session机制的弊端，Token机制应运而生。

Token，也称为令牌，一般由密钥、公钥、时间戳等元素通过加密算法（如MD5、SHA）生成。

在Token机制中，用户在通过身份验证后，服务器会生成一个Token并返回给客户端。客户端在后续的每次请求中都携带这个Token，而服务器通过验证Token的合法性来判定请求是否有效。

Session与Token

相比Session，Token的优势在于它可以轻松应对分布式部署和负载均衡环境，因为Token是无状态的，每个请求都携带了足够的信息进行验证，不依赖于特定的服务器节点。

这使得Token成为一种更为灵活和可扩展的身份验证和授权机制。

相同点：

1. 身份验证手段： Session和Token都是用于用户身份验证的手段，用于标识用户并维持其登录状态。

2. 过期时间： 两者都可以设置过期时间，限制了它们的有效期，增加安全性。

不同点：

1. 存储位置：

   • Session： 存储在服务器端，可以保存在内存、数据库、NoSQL等持久化存储中。

   • Token： 存储在客户端，通常存储在浏览器的Cookie中或本地存储。

2. 数据持久性：

   • Session： 数据可以持久化到服务器端，但如果没有进行持久化，一旦服务器重启，Session数据可能丢失。

   • Token： 由于存储在客户端，Token本身是无状态的，不受服务器重启的影响。

3. 数据交互方式：

   • Session： 通过在请求头中传递SessionID进行数据交互。

   • Token： 通过在请求头或请求参数中携带Token进行数据交互。

4. 空间换时间 vs 时间换空间：

   • Session： 采用空间换时间的策略，因为需要在服务器端存储Session数据。

   • Token： 采用时间换空间的策略，因为Token存储在客户端，不占用服务器端空间，每次验证都需要解析Token。

应用场景

会话的应用场景：

• Web 应用中，通过 cookie 或服务器端存储实现用户登录状态的跟踪。

• 需要在用户访问期间保持状态信息的应用，例如购物车信息等。

令牌的应用场景：

• token主要用于 Restful API 等无状态应用程序中，例如分布式系统，通过 OAuth 进行身份验证和授权。

• 移动应用或小程序中，使用 JSON Web Token (JWT) 进行身份验证。

小结

session 和 token 本质上是没有区别的，都是对用户身份的认证机制。

在实际应用中，需要根据具体需求权衡两者之间的选择，并采取相应的安全措施来保障用户身份的安全性和隐私。在不同的业务场景中合理选型，才能达到事半功倍的效果。