用户身份验证：Cookies vs Sessions vs Tokens

确保网站和应用程序的安全访问至关重要，但如何设置访问权限则取决于你如何存储待验证的数据。这反过来又实现了用户授权。Cookie、会话（Session）和令牌（Token）是三种常用的验证方式。

对于任何使用互联网的人来说，无论是出于休闲浏览还是专业用途，了解Cookie、Session和Token之间的差异都是必要的。

 

什么是Cookie?

Cookie是网页服务器发送至浏览器的小型文本文件，浏览器随后将其存储在用户的设备上。Cookie记录了诸如用户姓名、偏好设置或登录状态等信息。每当浏览器请求新页面时，它都会发送这些Cookies给服务器，以便服务器能够识别用户并提供个性化服务。

Cookie易于实现，并得到了浏览器和开发框架的广泛支持。

点击此处了解6款cookie工具。

 

Cookie的优势

支持跨子域的无缝体验

你可以将Cookie设置为在主站点及其所有子域中有效。只需指定一个域，比如"yoursite.com"，就能确保用户在访问主站点及其子域时，都能拥有一致的会话体验。

 

增强安全性能，防止脚本攻击

利用HttpOnly属性设置Cookie，可以限制它们被客户端JavaScript访问的程度。这是保护网站不受跨站脚本（XSS）攻击的关键措施，这类攻击通常涉及恶意JavaScript代码。

 

存储需求小

Cookie是轻量级的，只需要大约6KB的存储空间来存储诸如用户ID之类的基本信息。这意味着每次请求只传输少量数据，保持效率。

 

浏览器自动管理

Cookie由网页浏览器自动处理，无需你投入额外精力进行管理。

 

Cookie的缺点

容易遭受跨站请求伪造（CSRF）攻击

CSRF是一种网络安全攻击，允许攻击者在用户不知情的情况下，以登录用户的身份执行未经授权的操作。这种攻击在使用Cookie的会话中尤为常见。

SameSite允许你设置Cookie是否在严格或宽松模式下与外部应用程序共同使用。虽然严格模式可以阻止这些攻击，但它也可能影响网站的用户体验。

 

隐私问题

Cookie能够追踪用户在不同网站上的行为和偏好，这可能引发隐私问题。

 

不适合API认证

API为认证的最终用户提供一次性资源，不需要跟踪用户会话。在这种情况下，Cookie并不理想，因为它们用于追踪和验证活跃会话。

 

什么是Session?

Session（会话）是一种存储用户与服务器交互信息的方式。它允许网站保持状态信息，比如用户的登录状态、购物车内容或网站偏好设置。会话信息可以存储在服务器上，也可以以某种形式（如会话ID）存储在用户的浏览器中。

当用户首次访问网站时，服务器会创建一个会话，并生成一个独一无二的会话ID。这个ID通常存储在用户浏览器的一个Cookie中。用户的浏览器会将这个会话ID连同每个后续请求一起发送回服务器，使服务器能识别用户并检索存储在服务器上的会话信息，从而在多个页面请求中维持状态的连续性。

 

Session的优势

• 格式灵活，理论上拥有无限的存储空间。数据更难被访问、修改或丢失。

• 使用时无需声明，也不必担心稍后释放空间。

 

Session的缺点

• 缺乏可扩展性：在没有分布式架构的情况下，会话无法支持横向扩展。如果你使用单一服务器，这不是问题。但在服务器集群或面向服务的架构中，你需要一个统一的会话数据库来在不同服务器之间共享会话数据。

• 存储形式不便捷：会话数据存储的多种形式可能带来不便。

• 可能导致代码质量下降：过度依赖会话可能使代码变得难以阅读和维护。

 

什么是Token?

在网页开发中，Token（令牌）是一种用于认证和信息交换的加密字符串。现代网络应用中常见的一种类型是JSON Web Token（JWT）。

Token通常在用户登录时生成。它们包含了用于识别用户的信息及其他数据。

用户请求服务器时会发送Token。然后，服务器检查Token的有效性，以批准用户的请求。

Token的一个优点是它们可以在不同的服务之间共享，这意味着你不需要为每个服务保留会话信息，从而支持了无状态架构。

 

Token的优势

易于使用

JWT非常便于使用。它们包含了所有必要的信息来验证用户身份，因此无需每次查询数据库。这使得它们非常适合APIs，其中不需要跟踪用户的登录状态。

 

跨平台能力

由于其无状态特性，Token可以在移动平台和物联网（IoT）应用中无缝使用。

 

多种存储方式

Token可以通过多种方式在浏览器或前端应用中存储。

 

Token的缺点

无法撤销

一旦发出，JWT就无法被撤销。即便JWT被泄露，它在有效期内仍然有效，这可能导致严重的安全风险。为了解决这个问题，你可能需要设置一个更复杂的系统来阻止某些Token的使用。

 

占用更多空间

一个JWT可能需要超过300字节来存储一个简单的用户ID，因为它们还包含了其他用于认证的数据。

 

Cookie vs Session vs Token

下面是Cookie、Session和Token之间差异的总结对比表：

特性	Cookie	Session	Token
存储位置	客户端（用户浏览器）	服务器	客户端或服务器
状态管理	有状态（需要服务器存储状态）	有状态（需要服务器存储状态）	无状态（不需要服务器存储状态）
性能	数据量大时可能变慢	数据量大时可能变慢	通常更快，无需服务器端会话查询
安全性	易受CSRF攻击	易受会话劫持；需安全处理标识符	通常更安全，可通过HTTPS传输，不易受CSRF攻击
可扩展性	在负载均衡中可能有挑战	在负载均衡中可能有挑战	无状态特性使其更具可扩展性，分布式系统中更易处理
跨域访问	受限于设置Cookie的域，除非指定子域	通常限于设置会话的域	可用于不同域和服务间
存储容量	大小有限（如每个Cookie 4KB）	不在客户端存储，无同样大小限制	不受Cookie大小限制，但大令牌可能影响传输大小
跨平台使用	受浏览器限制	限于Web应用	适用于移动和物联网设备

 

结论

虽然基于Cookie的认证一直是传统方法，但基于Token的认证提供了更强的安全性和灵活性，使其成为某些场景下的首选方案。

BrowserScan的Cookie转换工具可以将Cookie转换为JSON格式，帮助开发者更加轻松地过渡到基于Token的认证方式。