在Web安全和会话管理中，token、cookie和session都是用于在客户端和服务器之间维护会话状态的机制
一. Token
1.1 简述
Token通常是一个经过加密的字符串，作为客户端进行请求的一个令牌，它包含了用户身份验证和授权所需的信息。
1.2 特性
1、安全性：Token具有较高的安全性，因为是经过加密的，并且通常包含有效期和签名等信息，可以防止被篡改和重复使用。
2、存储位置：Token通常存储在客户端的本地存储（如LocalStorage）或会话存储（如SessionStorage）中，也可以在浏览器的HTTP请求头中作为Authorization字段发送
3、支持跨域，无需依赖Cookie
4、可设置过期时间，刷新令牌可延长有效期
5、数据类型通常为字符串，包含用户身份信息
6、存储容量是可变的，取决于令牌长度
7、Token是唯一的，每个客户端在登录后都会获得一个独特的Token
8、Token通常具有时效性，过期后需要重新获取
1.3 工作原理
1、生成阶段
生成Token的过程通常涉及到加密算法，可以使用对称加密算法（如AES、DES）或非对称加密算法（如RSA、DSA），以确保Token的安全性和不可预测性。
当用户成功登录或者完成某种认证流程后，服务器会根据用户的信息和系统设置的规则生成一个Token。这个Token是一个包含用户相关信息的加密字符串，通常包含用户的身份信息、权限信息以及用于验证的签名信息。
2、分发阶段
一旦Token生成，服务器会将其发给客户端。客户端可以将这个Token保存在本地（如浏览器的LocalStorage、SessionStorage或者Cookie中），以便在后续的请求中使用。
服务器也可能在用户的Session域中保存这个Token，用于后续验证。
3、验证阶段
当客户端再次向服务器发送请求时，它会将Token附带到请求中（通常是通过HTTP请求头的Authorization字段或者请求参数），服务器接收到请求后，会取出Token并进行验证。
验证过程包括检查Token的签名是否有效、Token是否过期以及Token中的用户信息是否与服务器记录的信息一致等。
4、使用阶段
如果Token验证成功，服务器就会根据Token中的用户信息和权限信息来处理客户端的请求。例如，根据用户的角色来决定是否允许访问某个资源或者执行某个操作。
如果Token验证失败（如Token无效、过期或者被篡改），服务器会拒绝处理客户端的请求，并可能要求客户端重新进行身份验证
1.5 Token生成后的存储形式
Token加密前是明文信息，在服务器端生成后立即进行加密处理。
Token加密后，可以存储在客户端的多个位置，包括localStorage、cookie或sessionStorage中。
1、存储在localStorage中
localStorage是HTML5提供的一种客户端存储机制，可以将数据保存在用户的本地浏览器中。
将加密后的Token存储在localStorage中，可以提高数据的安全性
每次调用接口时，可以将Token作为一个字段传给后台进行验证
2、存储在sessionStorage中
sessionStorage与localStorage类似，也是HTML5提供的一种客户端存储机制，但它用于存储会话数据，数据在页面会话结束时会被清除。
3、存储在cookie中
cookie是另一种在客户端存储数据的方式，它可以自动在每次请求时发送到服务器。
存储在cookie中的Token有一个缺点，即不能跨域使用。
由于cookie在每次请求时都会自动发送，需要注意其安全性，避免被恶意获取或篡改
二、Cookie
2.1 简述
Cookie是一种小型文本文件，由网站发送到用户的浏览器并存储在用户的计算机或移动设备上，用于追踪用户身份和会话信息。
2.2 特性
1、Cookie通常存储在客户端浏览器的Cookie存储区域中
2、Cookie可配置的有效期。服务器在发送Cookie时，可以指定一个过期时间（Expires）或一个最大存活时间（Max-Age）。
3、如果既没有设置过期时间也没有设置最大存活时间，那么Cookie将成为一个会话Cookie，它只在当前会话期间有效，浏览器关闭后就会失效
4、Cookie的安全性不足，可以使用HTTPS增强安全性；也可以将Cookie的HttpOnly属性设置为true防止JavaScript脚本访问Cookie，从而减少跨站脚本攻击（XSS）的风险。
2.3 工作原理
1、生成Cookie
当用户第一次访问某个网站时，服务器会生成一个唯一的识别码（Cookie ID），并创建一个Cookie对象。
2、添加到HTTP响应头
服务器将这个Cookie对象通过HTTP响应报文中的Set-Cookie头部发送给客户端浏览器。Set-Cookie字段的值是一个字符串，可以包含多个cookie，每个cookie之间使用分号进行分隔。
3、客户端保存Cookie
浏览器接收到这个Cookie后，会将其保存在本地（可能是内存或硬盘中），具体取决于Cookie的设置（如会话级别或持久级别）
4、在后续的HTTP请求中，客户端会自动在请求头中添加Cookie字段，并将之前保存的cookie信息一起发送给服务器。
2.4 示例
Cookie是客户端保存并在后续请求中携带给服务器的数据，而Set-Cookie是服务器端用来设置和管理Cookie的机制
HTTP响应头中Set-Cookie字段的格式如下：
header("Set-Cookie: name=value; expires=Sat, 31 Dec 2022 23:59:59 GMT; path=/; secure; HttpOnly");
name=value：这是Cookie的名称和值
expires=Sat, 31 Dec 2022 23:59:59 GMT：这是Cookie的过期时间。
path=/：这是Cookie的路径。它决定了哪个URL可以访问这个Cookie。路径设置为"/"，意味着网站的所有页面都可以访问这个Cookie。
domain：这是Cookie的域名。它决定了哪个域名可以访问这个Cookie。如果不设置域名，默认为设置Cookie的域名。
secure：这表示Cookie只有在使用HTTPS协议时才会被发送。这增加了安全性，防止Cookie在非加密连接中被窃取。
HttpOnly：这表示Cookie不能被JavaScript访问，这有助于防止跨站脚本攻击（XSS）
三、Session
3.1 简述
Session是一种在服务器端存储用户会话数据的机制
3.2 特性
1、Session存储在服务器端的内存中或数据库中，因此具有较高的安全性
2、Session具有一个可配置的有效期
3、由于Session ID在客户端和服务器之间传输，因此它容易被截获或篡改。为了增强Session的安全性，可以采取：
HTTPS协议传输Session ID；
如果Session ID是通过Cookie传输的，可以设置Cookie的HttpOnly和Secure属性；
定期更换Session ID；
4、不支持跨域
3.3 工作原理
1、当用户首次访问网站时，服务器会创建一个新的Session对象，并生成一个唯一的Session ID。服务器会将这个Session ID通过某种方式（如Cookie、URL参数等）发送给客户端。
2、客户端在接收到Session ID后，会将其存储在本地（如浏览器的Cookie存储区域中）。
3、在后续的请求中，客户端会自动将存储的Session ID包含在请求头中发送给服务器。服务器通过解析请求头中的Session ID来识别用户的会话状态，并从Session对象中获取用户的会话信息。
四、使用场景
Cookie：
1、登录状态：Cookie可以用来存储用户的登录状态，如用户名、加密的令牌(token)或会话ID。当用户访问受保护的资源时，服务器可以检查Cookie来确定用户是否已经登录。
2、个性化设置：网站可以使用Cookie来存储用户的个性化偏好，如语言偏好、主题设置、字体大小等。
3、电商网站：在电商网站上，Cookie可以用来存储用户的购物车信息。即使用户关闭了浏览器，当再次访问网站时，购物车里的商品仍然会保留。
适用于客户端保存少量数据的场景
Session：
1、用户认证和授权：Session对象可以用来存储用户的认证信息，如用户名、密码等。在用户登录后，可以将认证信息存储在Session中，以便在整个会话期间进行身份验证和授权操作。
2、缓存数据：Session对象可以被用来缓存一些临时的数据。例如，可以将数据库查询结果存储在Session中，以便在后续的请求中直接使用，避免重复查询。
3、多语言支持：Session对象可以用来存储用户的语言偏好设置，以便在整个会话期间提供相应的多语言支持。
适用于需要在服务器端管理用户状态的场景：特别是需要保持用户登录状态、购物车等需要长期管理的应用。
Token：
1、用户认证：在用户输入密码和帐号后，系统进行验证后，生成一个Token，分配给用户。后续服务使用者就无需每次都输入密码和验证密码了，只需把对应的帐户和Token带上即可。
2、单点登录(SSO)：Token在无状态认证中非常流行，如OAuth、单点登录(SSO)等。
3、适用于分布式系统和无状态应用：可以减轻服务器的负担，并且可扩展性好。
一起使用的场景：
1、在一个Web应用中，当用户首次登录时，服务器可以生成一个SessionID，并通过设置Cookie的方式将其返回给客户端。同时，服务器也可以生成一个Token，并将其发送给客户端（通常是通过HTTP响应头或响应体）。
2、客户端在后续的请求中，既可以携带SessionCookie来保持会话状态，也可以携带Token来进行认证和授权。
3、服务器在接收到请求后，可以先检查SessionCookie来确定用户的会话状态，然后再验证Token来确定用户的身份和权限。