1. 在基于会话的身份验证中，服务器在服务器端完成所有繁重的工作。从广义上讲，客户端使用其凭据进行身份验证并接收一个session_id（可以存储在 cookie 中）并将其附加到每个后续传出请求。所以这可以被认为是一个“令牌”，因为它相当于一组凭据。然而，这并没有什么特别之处session_id细绳。它只是一个标识符，服务器会执行其他所有操作。它是有状态的。它将标识符与用户帐户相关联（例如在内存中或在数据库中）。它可以将此会话限制或限制为某些操作或某个时间段，如果存在安全问题，它可以使其无效。更重要的是，它可以即时完成并改变所有这些。此外，它可以记录用户在网站上的一举一动。可能的缺点是可扩展性差（尤其是在多个服务器场上）和大量内存使用。

2. 在基于令牌的身份验证中，没有会话在服务器端（无状态）持久化。初始步骤相同。凭证与令牌交换，然后附加到每个后续请求（它也可以存储在 cookie 中）。然而，为了减少内存使用、易于扩展和总体灵活性（令牌可以与另一个客户端交换），会发出一个包含所有必要信息的字符串（令牌），在客户端向客户端发出每个请求后都会检查该字符串服务器。有多种使用/创建令牌的方法：

   1. 使用哈希机制，例如 HMAC-SHA1

      token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
      

      whereuser_id和expiry_date以明文形式发送，并附上生成的散列（k只有服务器知道）。

   2. 对称加密令牌，例如使用 AES

      token = AES(user_id|expiry_date, x)
      

      其中x表示加密/解密密钥。

   3. 非对称加密，例如使用 RSA

      token = RSA(user_id|expiry_date, private key)
      

生产系统通常比这两种原型更复杂。例如，亚马逊在其网站上使用这两种机制。混合型也可用于发行令牌，如 2 中所述，还可以将用户会话与其关联以进行用户跟踪或可能的撤销，并且仍然保留经典令牌的客户端灵活性。OAuth 2.0 还使用短期和特定的不记名令牌和长期刷新令牌，例如获取不记名令牌。

资料来源：

• https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
• https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
• https://web.archive.org/web/20170913233103/https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
• 揭秘 Web 身份验证（无状态会话 Cookie）
• https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication

HTTP 是无状态的，为了获得经过身份验证的状态，您需要某种令牌来引用有关用户的信息。此会话 id 通常采用作为 cookie 值发送的随机令牌的形式。OAuth访问令牌用于识别用户以及scope用户有权访问的资源。在使用 OAuth 单点登录的应用程序中，通常将 OAuth 访问令牌交换为会话 ID，该会话 ID 可以跟踪更广泛的用户状态。

从攻击者的角度来看，劫持会话 id 或 OAuth 访问令牌与用户名和密码一样好，有时甚至更好。 会话 ID 必须具有保护用户帐户免受损害的安全属性。

从开发人员的角度来看， 永远不要重新发明轮子。使用您的平台提供的会话管理器，并确保其配置符合OWASP 会话管理指南。

因此，在基于会话的身份验证中，为了提高访问资源的安全性，需要哪一个：

• 它应该用作用户凭证的替代品
• 它应该始终使用持久性 cookie
• 它应该识别返回到网站的用户
• 它应该使用两因素身份验证