Session 和 Token 这两种身份验证方法，旨在帮助服务器信任经过身份认证的用户通过互联网发送的请求。这样一来，用户便无需在每次操作时反复输入凭据，即可与其账户进行交互。通常情况下，我们会根据不同的应用场景来选择使用这两种方法。
例如，在传统的 Web 网站应用中，Session 非常普遍；而在服务器与服务器之间的连接中，Token 则是更优的选择。
!image身份验证
Session 身份验证
Session（会话） 是一个小型文件，最常见的是 JSON 格式，用于存储用户信息（例如唯一的 ID、登录时间、过期时间等）。它由服务器生成并存储在服务器端，以便服务器能够追踪用户的请求。用户会接收到部分详细信息（特别是 ID），这些信息以 Cookie 的形式存储，并会随每个新请求一起发送到服务器，从而使服务器能够识别 ID 并授权用户的请求。
工作原理
- 用户向服务器发送登录请求。
- 服务器验证登录请求，将 Session 写入数据库，并向用户返回包含 Session ID 的 Cookie。
- 现在，用户发送新的请求（携带 Cookie）。
- 服务器在数据库中查找 Cookie 中包含的 ID，如果找到该 ID，则将请求的页面发送给用户。
!Session AuthenticationSession 身份验证流程
优缺点分析
由于 Session 是存储在服务器端的，其管理者对它们拥有完全的控制权。例如，如果安全团队怀疑某个账户被盗用，他们可以立即使 Session ID 失效，从而强制用户立即下线。但另一方面，正因为 Session 存储在服务器上，服务器需要负责查找用户发送的 Session ID，这在流量巨大时可能会导致可扩展性问题。
此外，Cookie 可能会面临跨站请求伪造（CSRF）攻击的风险。攻击者可能会诱导用户访问恶意网站，利用其中的 JavaScript 脚本窃取 Cookie 并向服务器发送恶意请求。另一个潜在的安全隐患是中间人攻击，攻击者可能会截获 Session ID 并向服务器发送有害请求。
基于 Token 的身份验证
Token（令牌） 是一种不可篡改的授权文件。它由服务器使用密钥生成，并发送给用户，存储在用户的本地存储中。与 Cookie 类似，用户会在每个新请求中将此 Token 发送到服务器，以便服务器验证其签名并授权请求。
工作原理
- 用户向服务器发送登录请求。
- 服务器授权登录并向用户发送一个 Token。
- 现在，用户发送新的请求（携带 Token）。
- 服务器检查 Token 是否有效，如果有效，则将请求的页面发送给用户。
! Token Authentication Token 身份验证流程
注意- 这些不是身份认证文件，它们是授权文件。在接收 Token 时，服务器不会去查询用户是谁，它只是根据 Token 的有效性来授权用户的请求。
优缺点分析
当用户希望减少发送凭据的次数时，Token 会非常有用。在服务器到服务器的连接场景中，使用凭据往往比较困难，而 Token 可以很好地解决这个问题。此外，使用 Token 的服务器可以提高性能，因为它们不需要为了授权用户的请求而持续查询所有的 Session 详细信息。
然而，由于身份验证详细信息存储在客户端，服务器无法像使用 Session 方法那样执行某些特定的安全操作。如前所述，服务器不进行用户身份认证，因此将 Token 与特定用户关联可能会更加困难。如果假设攻击者设法获取了一个有效的 Token，他们可能会获得对服务器数据库的无限制访问权限。此外，如果服务器使用旧算法生成密钥，这些密钥可能会被破解。
Session 与 Token 身份验证方法的区别
标准
基于 Token 的身份验证方法
—
—
连接的哪一方存储身份验证详细信息
用户
用户向服务器发送什么以获得请求授权
Token 本身
服务器做什么来授权用户的请求在其数据库中查找，根据用户通过 Cookie 发送的 ID 定位正确的 Session