Cookie、Token及会话ID的区别

图片来自于网络搜索

在做网络安全业务系统合规检查的过程中，会涉及一些Cookie相关的测评项。但是我们往往会发现，Cookie里的东西长得稀奇古怪的，也看不太明白。有时候被测系统用的又是Token,一会儿又冒出个会话ID，初入行的工程师就懵圈了。

于是，今天把这些概念和场景说说，希望我们都能搞明白点。

Cookie、Token和会话ID都是用于管理用户会话和身份验证的机制，但它们在实现方式和使用场景上有所不同。

以下是它们的主要区别：

1. Cookie

• 定义：Cookie 是由服务器生成并存储在用户浏览器中的小型文本文件（说白了，Cookie的功能就是主打一个可存储在浏览器测）它们用于在用户浏览器和服务器之间存储和传递信息。一般来说呢，Cookie中可以包含会话ID和Token。

• 特点：

• 自动发送：每次浏览器向服务器发送请求时，会自动附带Cookie。

• 存储：可存储在浏览器中，包括用户的会话信息、偏好设置等。

• 属性：

• 可以设置过期时间。

• 可以设置HttpOnly（防止通过JavaScript访问）和Secure（仅通过HTTPS传输）标志。

• 可以指定域名和路径。

• 适用场景：适用于传统的Web应用，尤其是用于保持用户的登录状态和存储用户偏好设置。

2. Token

• 定义：Token 是由服务器生成的字符串，用于身份验证和授权。Token 通常包含编码的用户信息和有效期等。

• 特点：

• 手动发送：Token 通常需要在请求中手动附加，例如在HTTP头部或请求参数中。

• 自包含：如JSON Web Token (JWT)，Token 可以自包含用户信息、权限等。

• 灵活性：不依赖于浏览器机制，可以用于API认证、移动应用等。

• 适用场景：适用于现代API认证和授权，特别是无状态的RESTful API，以及跨域请求和移动应用。

3. 会话ID (Session ID)

• 定义：会话ID 是一个唯一的标识符，用于跟踪用户的会话。会话ID 通常存储在服务器端，客户端通过Cookie或其他机制来引用这个ID。

• 特点：

• 存储：会话ID 本身通常存储在客户端的Cookie中，但实际的会话数据（如用户信息、权限等）保存在服务器端。

• 生命周期：会话ID 通常与会话的生命周期相关联。会话可以有超时时间，超时后会话将失效。

• 安全性：由于实际数据存储在服务器端，减少了数据泄露的风险，但会话ID 仍需保护以防止会话劫持攻击。

• 适用场景：适用于需要在服务器端管理会话状态的传统Web应用中。用于保持用户的登录状态、跟踪用户行为等。

总结

• Cookie：存储在浏览器中的信息，自动随每个请求发送。常用于存储会话ID或简单的用户信息。

• Token：通常用于API认证，自包含用户信息和权限，需要在请求中手动附加。适用于现代API和无状态认证。

• 会话ID：唯一标识符，用于在服务器端跟踪用户会话，通常与Cookie配合使用。会话数据保存在服务器端，提供了一种更安全的会话管理方式。

这些机制可以根据具体需求结合使用，例如在Web应用中使用Cookie存储会话ID，使用Token进行API认证等。

看了这些还是懵圈吧。我们把这三个东东拉出来溜溜，再观察一下它们的长相。

Cookie长这样：

name=value; Expires=Wed, 21 Aug 2024 07:28:00 GMT; Path=/; Domain=example.com; Secure; HttpOnly

解释：

• name=value：Cookie的名称和值，例如session_id=abc123。

• Expires：Cookie的过期时间，格式为Day, DD Mon YYYY HH:MM:SS GMT，例如Expires=Wed, 21 Aug 2024 07:28:00 GMT。

• Path：指定Cookie的适用路径，例如Path=/表示整个网站都可以访问这个Cookie。

• Domain：指定Cookie的适用域名，例如Domain=example.com表示只有在example.com及其子域名下的页面可以访问这个Cookie。

• Secure：表示Cookie只能通过HTTPS传输，增加安全性。

• HttpOnly：表示Cookie不能通过JavaScript访问，减少XSS攻击的风险。

这些信息通常是由服务器在响应头中设置，然后浏览器会存储这些Cookie并在后续请求中自动发送。

Token长这样：

Token 通常是一个长字符串，格式可以因使用的标准不同而有所不同。以下是常见Token格式的几个例子：

1. JWT (JSON Web Token)

JWT 是一种常用的Token格式，它由三个部分组成，用点（.）分隔：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTk0Njc5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header：包含Token类型和加密算法。

• Payload：包含用户信息和声明。

• Signature：用于验证Token的完整性。

2. OAuth 2.0 Access Token

OAuth 2.0的Access Token格式可能是一个简短的随机字符串：

d6f1e89d63a549d8b648e7d1c82d67d3


3. Bearer Token
Bearer Token 是一种常见的OAuth 2.0 Token，通常用作HTTP头部字段：
Bearer d6f1e89d63a549d8b648e7d1c82d67d3


4. API Key
虽然API Key不总是被称为Token，但它们的形式类似，也是一个长字符串：
1234567890abcdef1234567890abcdef


Token通常是一个长字符串，包含或不包含某些结构化信息（如JWT中的Header、Payload和Signature），用于身份验证和授权。
会话ID长这样：
会话ID通常是一个随机生成的长字符串，用于唯一标识一个用户的会话。它的具体格式可能因实现而异，但一般来说，它看起来像这样：
a3f5d1d2b9c3a4e8f9d8d7b6e5a9c0b1

或
1234567890abcdef1234567890abcdef


解释：


随机字符串：会话ID通常是随机生成的，确保其唯一性。


长度：长度可以不同，通常为32到64个字符，包含字母和数字。


会话ID常保存在浏览器的Cookie中，并在用户与服务器之间的每个请求中自动发送，以便服务器能够识别和管理用户的会话状态。
再举个例子
假设你在一个在线客服系统中与客服代表进行对话：


会话开始：



你访问客服网站并登录。系统生成一个唯一的会话ID session12345 和一个身份验证 Token authToken123。


会话ID 和 Token 被存储在你的浏览器 Cookie 中。



交互过程：



每次你发送消息，浏览器会自动将 Cookie 中的会话ID 和 Token 发送给服务器。


服务器使用会话ID 查找你的对话历史，并使用 Token 验证你的身份和授权。



保持会话状态：



即使你在对话过程中重新加载页面或在网站上导航，Cookie 中的会话ID 和 Token 仍然保留，确保你的对话状态不会丢失。


如果你退出并重新登录，系统可以根据 Cookie 中的信息恢复你的会话状态，继续之前的对话。



总结


会话ID 唯一标识用户的对话会话，帮助系统跟踪和管理对话状态。


Token 用于身份验证和授权，确保每次请求都是合法的并保持用户的认证状态。


Cookie 用于在用户的浏览器中存储会话ID 和 Token，使得用户在多次交互中能够保持会话状态和身份认证。


这三者协同工作，确保了用户体验的连贯性、安全性和系统的有效管理。
THE END
参考：


                    



暂时无法播放，可回源网站播放




原文始发于微信公众号（透明魔方）：Cookie、Token及会话ID的区别