Web应用用户身份认证：为何用Token而非Session？

你提到的Session认证方式确实简单直接，但在很多现代Web场景下，Token认证能解决Session无法覆盖的问题，具体优势如下：

• 跨域与分布式系统适配
  Session依赖Cookie，而Cookie受同源策略约束，前后端分离、微服务架构中，前端往往需要和多个不同域名的后端服务交互，Session的Cookie没法跨域传递。但Token可以放在请求头里（比如Authorization: Bearer <token>），轻松跨域，完美适配多服务的身份校验需求。

• 服务器无状态，易扩展
  Session需要服务器存储会话数据，用户量上来后，服务器内存或存储压力会越来越大，集群部署时还得做Session同步（比如用Redis共享）。Token本身包含加密后的用户身份信息，服务器不用存会话数据，只需要验证Token的签名有效性就行，实现无状态，不仅降低存储开销，还能轻松做水平扩展。

• 多终端兼容
  Session依赖Cookie，像小程序、原生APP、IoT设备这类终端，要么不支持Cookie，要么对Cookie使用有严格限制。Token则可以通过请求头、请求体等多种方式传递，能适配几乎所有终端的身份认证需求。

• 权限控制更高效精细
  生成Token时可以嵌入用户角色、可访问资源范围、过期时间等权限信息，服务器验证Token时直接读取这些信息，不用额外查数据库，既提升校验效率，也能实现更细粒度的权限控制。而Session要获取这类信息，通常得额外查询数据库或从Session存储中读取。

• 安全机制更灵活

  • Token可以设置灵活的过期策略，比如用短有效期的Access Token搭配长有效期的Refresh Token，Access Token过期后用Refresh Token重新获取，既保证Token泄露后的风险可控，又不用频繁让用户重新登录。
  • Token支持签名和加密，能有效防止篡改。虽然Session也能通过配置Cookie的HttpOnly、Secure等属性提升安全性，但Token的安全机制更灵活，能适配不同场景的安全需求。

示例：Session认证流程 #

用户首次登录

# 登录处理逻辑
start_session()

if request_method == 'POST':
    username = request_parameters['username']
    password = request_parameters['password']

    if validate_credentials(username, password):
        set_session_variable('user', username)
        redirect_to('protected_page')
    else:
        redirect_to('login_page?error=invalid_credentials')

处理后续请求

# 受保护页面处理逻辑
start_session()

if session_variable_exists('user'):
    # 用户已认证，展示受保护内容
    display_protected_content(user)
else:
    # 用户未认证，重定向到登录页
    redirect_to('login_page')

内容的提问来源于stack exchange，提问作者Mostafa Aourik