Cookie、Session、Token、JWT区别和关系

本文探讨了Cookie、Session、Token和JWT在用户身份验证中的角色,强调了Cookie的安全隐患、Session和Token在移动应用中的使用以及JWT在分布式服务器中的解决方案,同时指出JWT虽看似加密但不适合保存敏感信息。

Cookie、Session、Token、JWT区别和关系

Cookie

  • 浏览器登录时,会将用户名和密码发送给服务器。服务器验证用户名和密码判断是哪个用户的请求
  • 但是之后的请求需要一直带上用户名和密码,缺少安全性
  • Cookie由此而生,Cookie是服务器验证完用户名和密码后返回给客户端的用户凭证,一般是用户ID和用户名的组合
  • 但是用户ID+用户名很容易给不怀好意的人猜到,从而获取到用户权限。
  • 所以一般会在cookie中放置数据签名(例如,把cookie中所有的数据连起来,拼接上存在服务器中的密令,取Hash值作为签名)
  • 签名随同数据一并发给浏览器作为Cookie,用户不知道服务器密令,所以无法伪造cookie

Session

  • 如果不想浏览器cookie保存太多信息,则可以将用户信息保存在服务器中,并生成一个足够长的key作为session_id传回浏览器作为cookie
  • 后续cookie传回可以通过session_id判断用户,查找出用户数据
  • 这个过程就是Session,session本质上还是一种cookie,不同点在于只传回session_id作为唯一标识,会话数据全都保存在服务器中,由服务器自行管理

Token

  • 移动互联网中,除了网页还有APP和小程序,这种客户端接口默认没有Cookie机制的
  • 将服务器保存的key传输回客户端,但是不再命名为session_id,而是直接作为Token,代替Cookie+serssion_id的组合
  • session和token本质是一样,只是少了浏览器的cookie机制,需要自己维护
  • 而因为缺少了cookie机制,所以客户端请求的时候不再使用cookie字段,而是转用Authorization字段代替

以上是单一服务器的情况,在分布式服务器中,容易导致一个服务器没有会话而导致鉴权失败

分布式服务器

  • 通常解决上述问题,需要在服务端再架设一个中心化的存储服务,例如,Redis专门存储会话数据
  • 但是中心化的方式容易造成服务端的性能瓶颈,Redis中心化的崩溃会导致所有服务器连带崩溃
  • 项目中更多的是希望用户鉴权数据保存在客户端,接口尽可能是无状态的。
  • 所以可以将Cookie的数据作为Token保存在客户端中,这样服务器不需要保存用户的鉴权数据。可以更大的提升服务器的性能。
  • 但是Cookie的加密方式是我们自己想,很可能存在漏洞。每个人的算法也不一样,这样不方便协作

JWT

  • JWT是Token生成的一个标准
  • 这样生成的Token由三部分组成
  • 第一部分,头部包含Hash算法和Token类型
  • 第二部分,载体携带会话数据
  • 第三部分,是签名,原理与我们生成的Cookie签名相类似
  • 但是虽然JWT生成的Token像是加密的,其实谁都可以解开。所以敏感信息,像是密码之类的不要保存在Token中
### Java 中 CookieSessionToken JWT区别及使用场景 #### 一、概念概述 - **Cookie** 是一种小型文本文件,存储在客户端浏览器中。当用户访问网站时,服务器可以设置 Cookies 来保存一些数据,这些数据会在后续请求中被自动发送给服务器[^1]。 - **Session** 是指服务器端的一种会话技术,用来跟踪用户的交互过程。通常情况下,Session ID 存储于 Cookie 或 URL 参数中,以便识别特定用户的会话信息[^3]。 - **Token** 表示令牌,广泛应用于无状态的应用程序架构下作为临时凭证来验证用户身份并授予相应权限。它可以是一个简单的字符串或者加密后的 JSON 对象(如 JWT),由服务端签发并在每次 HTTP 请求头携带传递给资源提供者进行校验[^4]。 - **JSON Web Token (JWT)** 属于 token 类型之一,遵循 RFC 7519 标准定义了一种紧凑且自包含的方式用于在网络应用程序之间安全地传输信息。该信息经过编码形成一段可读性强但又难以篡改的数据串,既可用于认证也可承载其他业务逻辑所需参数[^5]。 #### 二、特点对比 | 特征 | Cookie | Session | Token | JWT | |------------|----------------------------------|----------------------------------|-----------------------------------|------------------------------------| | 数据位置 | 客户端 | 服务器端 | 可选(取决于实现方式) | 客户端 | | 生命周期 | 浏览器关闭或设定过期时间 | 用户登出或超时时限 | 自定义有效期 | 声明中的 exp 字段指定有效期限 | | 安全性 | 易受 XSS 攻击 | 较高 | 需要妥善保管私钥 | 数字签名防止伪造 | | 跨域支持 | 不友好 | 同源策略限制 | 方便 | 天然跨域兼容 | #### 三、应用场景分析 对于传统的基于表单提交的 web 应用而言,`Cookie + Session` 组合能够很好地满足需求: - `Cookie` 将 session id 发送给服务器; - `Session` 在服务器上记录着当前登录者的相关信息直到其失效为止。 然而,在 RESTful API 设计以及微服务体系结构,则更多倾向于采用 `Token/JWT` 进行鉴权操作: - `Token` 提供了更好的灵活性扩展能力,尤其是在前后端分离项目或是移动设备开发环境下显得尤为重要[^2]。 ```java // 创建一个带有签名算法 HS256 的 JWT 实例 JWTCreator.Builder builder = JWT.create(); builder.withSubject("user"); builder.withClaim("id", userId); String token = builder.sign(Algorithm.HMAC256(secret)); // 解析接收到的 JWT 并验证其合法性 DecodedJWT jwt = JWT.require(Algorithm.HMAC256(secret)).build().verify(token); System.out.println(jwt.getClaim("id").asString()); ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值