token、cookie和session

在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来确定用户的身份和权限。