当前位置: 首页 > news >正文

【HTTP服务端】Cookie?Session?Token?

文章目录

  • cookie与session
  • token
    • 什么是JWT?
    • JWT的组成结构
      • 1. Header(头部)
      • 2. Payload(负载)
      • 3. Signature(签名)
    • JWT工作原理
    • JWT的特点
    • 安全注意事项

cookie与session

cookie有哪些属性

  1. 键值对(必需)
  • name=value:Cookie 的核心内容,如 session_id=12345
  1. 作用域控制
  • Domain:指定 Cookie 可被发送到的域名(如 Domain=example.com),子域名默认继承。
  • Path:指定 Cookie 可被发送到的路径(如 Path=/api),子路径默认继承。
  1. 有效期
  • Expires:指定 Cookie 的具体过期时间(如 Expires=Wed, 21 Oct 2025 07:28:00 GMT)。
  • Max-Age:指定 Cookie 的有效秒数(如 Max-Age=3600 表示 1 小时后过期)。
  1. 安全属性
  • Secure:仅在 HTTPS 连接下发送 Cookie。
  • HttpOnly:禁止 JavaScript 访问 Cookie(防 XSS 攻击)。
  • SameSite:控制跨站请求时 Cookie 的发送策略:
    • Strict:仅允许同源请求携带 Cookie。
    • Lax:允许部分安全的跨站请求(如链接跳转)。
    • None:允许所有跨站请求(需配合 Secure 属性)。
  1. 其他
  • Priority(Chrome 特有):指定 Cookie 的优先级(Low/Medium/High)。
  • Partitioned(实验性):隔离不同站点的 Cookie 存储(防跨站追踪)。

示例

Set-Cookie: session_id=12345; Domain=example.com; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly; SameSite=Lax

cookie原理

http客户端向服务端发请求,服务端通过http响应返回给客户端如usrname=xxx pswd=xxx,客户端在后续请求中携带该字段,从而让服务端识别。

从安全性等角度演变为session

http客户端向服务端发请求,服务端针对该客户端生成一个唯一标识,通过http响应返回给客户端,客户端在后续请求中携带该字段,从而让服务端识别。【该唯一标识sessionid通常是一个“数据”的标识,该“数据”存储了该用户的信息,该sessionid通常存在redis集群,不同服务器在负载均衡时去redis查】

该唯一标识的内容设成什么?

服务端可以根据用户名和密码和一些环境信息基于某种算法生成

该值保存在哪

保存在客户端,分为内存级【会话关闭cookie消失】和磁盘级【cookie过期后消失】

如何实现会话管理?服务端需要存储哪些信息?

  1. 服务端对于客户端发来cookie的value,将value和用户的唯一标识如user_id建立映射,从而可以获取该用户相关信息如用户登录状态,用户权限信息,用户登陆ip,用户使用设备,用户临时上下文(浏览部分,购物车临时数据)
  2. 其他信息:会话创建,过期,活跃时间;

token

为防止客户端发送的session id被伪造,需对其合法性进行验证。可采用令牌(token)机制,在用户登录后发放包含其user id的token,用户后续请求时通过Http header携带该token。为避免伪造,用HMAC-SHA256算法结合仅服务端知晓的密钥对数据签名,将签名与数据一同作为token,因密钥保密,他人无法伪造。服务端不保存token,接收后用相同算法和密钥重新计算签名并与token中的签名比对,相同则确认用户合法登录并获取user id,不同则判定数据被篡改。需注意,token数据经Base64编码(非加密),明文可见,不可包含密码等敏感信息,且token被盗与session id被盗风险类似。这种不保存session id仅生成和验证token的无状态机制,能减轻服务器存储负担,便于机器集群水平扩展。【token解决了服务端需要存储大量的sessionid造成的空间成本,通过token中的user_id直接去数据库查询用户相关信息】

什么是JWT?

JWT(JSON Web Token)是一种开放标准(RFC 7519),用于在网络应用环境间安全地传输声明(claims)作为JSON对象。它通常用于身份验证和信息交换。

JWT的组成结构

一个JWT由三部分组成,用点号(.)分隔:

Header.Payload.Signature

1. Header(头部)

包含令牌类型(typ)和签名算法(alg),例如:

{"alg": "HS256","typ": "JWT"
}

2. Payload(负载)

包含声明(claims),声明是关于实体(通常是用户)和其他数据的语句。有三种类型的声明:

  • 注册声明(预定义):如iss(签发者)、exp(过期时间)、sub(主题)等
  • 公共声明:可以自定义,但应避免与已注册声明冲突
  • 私有声明:用于在同意使用它们的各方之间共享信息

示例:

{"sub": "1234567890","name": "John Doe","admin": true,"iat": 1516239022
}

3. Signature(签名)

使用编码后的header、payload、一个密钥和header中指定的算法生成。例如使用HMAC SHA256算法:

HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

JWT工作原理

  1. 认证流程

    • 用户登录,服务器验证凭证
    • 服务器创建JWT并返回给客户端
    • 客户端存储JWT(通常在localStorage或cookie中)
    • 客户端在后续请求的Authorization头中携带JWT
    • 服务器验证JWT并处理请求
  2. 验证过程

    • 服务器收到JWT后,会重新计算签名
    • 比较计算的签名与JWT中的签名是否一致
    • 验证过期时间等声明

JWT的特点

  • 无状态:服务器不需要存储会话信息
  • 可验证:签名确保令牌未被篡改
  • 包含信息:payload可以包含用户基本信息
  • 跨域友好:适合单点登录和分布式系统

安全注意事项

  • 不要将敏感信息放入JWT(除非加密)
  • 使用HTTPS传输
  • 设置合理的过期时间
  • 考虑使用刷新令牌机制
  • 防范CSRF攻击(如果存储在cookie中)

JWT是现代Web应用和API中广泛使用的身份验证机制,特别适合RESTful API和无状态服务架构。

http://www.dtcms.com/a/273169.html

相关文章:

  • React 自定义Hook——页面或元素滚动到底部监听 Hook
  • Java+Vue开发的资产设备全周期管理系统,移动端+后台管理,涵盖采购至报废全程,实现高效管理、成本可控与资源优化
  • Shell脚本一键部署KubeSphere前置环境
  • 04-ES6
  • 多线程 JAVA
  • Java :Optional容器类
  • python的保险业务管理与数据分析系统
  • AI 智能体:从辅助工具到自主决策者
  • 【YOLO脚本】对模型yaml文件测试
  • ZYNQ MPSOC PL端DDR4读写--仿真(3)
  • JDK的Closure闭包详解
  • 发现和发明浅谈
  • 2025年最新Dubbo-admin 部署
  • HTML初学者第四天
  • Android 应用常见安全问题
  • JavaScript基础(三)
  • 一文讲清楚React Hooks
  • 解决问题的“测地线”:关于第一性原理与其他系统思考框架
  • RocksDB 与 ZenFS:原理、特性及在科研与工程中的应用初步探索
  • 使用Arthas监听Spring代理对象
  • 从UI设计到数字孪生实战部署:构建智慧教育的在线学习分析平台
  • Java观察者模式实现方式与测试方法
  • Constants
  • SSM 框架整合教程:从环境搭建到 CRUD 实现
  • html页面,一个控件,可以粘贴图片和样式,一直按enter键会将下面内容推下去
  • OrCAD 24.1补丁005中文界面切换指南
  • QT Android 如何打包大文件到目录下?
  • 【Pandas】pandas DataFrame from_records
  • Android开发中几种scope的对比
  • ClickHouse JSON 解析