如果您经常查看在线教程来构建项目,您会注意到其中许多使用 JWT。
但是,这真的安全吗?为什么这么多人建议不要使用它?本文将为您提供对 JWT 及其优缺点的全面了解。
什么是 JWT?
这里是官方网站:JSON Web Tokens — jwt.io
这是 JWT 是什么。
JWT 代表 JSON Web Token
。
如果您不熟悉 JWT,别担心!它们并不那么复杂!
您可以将 JWT 视为一块可以验证的 JSON 数据,以确认数据来自您信任的人。
当然,我们不会在这里详细介绍其实现方式,但如果您感兴趣,您可以自己查看。
现在,让我们来谈谈其过程:
- 当你登录网站时,网站生成 JWT 并发送给您。
- JWT 类似于一个包含您一些身份信息的包,例如您的用户名、角色、权限等。
- 然后,每次与网站通信时,你都带着这个 JWT。
- 每次您访问需要身份验证的页面时,您都向网站提供此 JWT。
- 当网站接收到 JWT 时,它会验证其签名以确保是由网站签发的,并检查其中的信息以确认您的身份和权限。
- 如果一切检查无误,您将被允许继续访问受保护的页面。
为什么 JWT 被认为不好?
首先,当我们使用 JWT 时,通常用于以下任务:
- 网站用户注册
- 网站用户登录
- 用户点击并执行操作
- 网站使用用户的个人信息来创建、更新或删除数据
这些任务通常涉及以下数据库操作:
- 记录用户执行的操作
- 向数据库添加一些用户数据
- 检查用户权限以查看他们是否可以执行某些操作
现在,让我们一步一步地讨论它的缺点。
尺寸
这是一个不可否认的问题。
例如,如果我们需要存储一个用户 ID,如“xiaou”:
- 如果存储在 cookie 中,总大小仅为 5 字节。
- 如果我们把 ID 存储在 JWT 中,其大小会增加约 51 倍。
这无疑增加了我们的带宽负担。
冗余签名
JWT 的主要卖点之一是其加密签名。
JWTs 签名后,接收者可以验证 JWT 是否有效且可信。
然而,在过去 20 年中,几乎每个 Web 框架在使用常规会话 cookie 的同时,都提供了加密签名的优势。
实际上,大多数 Web 框架会自动为您签名(甚至加密!)您的 cookies。
这意味着您可以获得与 JWT 签名相同的利益,而无需使用 JWT 本身。
实际上,在大多数 Web 身份验证案例中,JWT 数据存储在会话 cookie 中,这意味着你现在有两层签名:一层在 cookie 本身上,另一层在 JWT 上。
令牌撤销问题
由于令牌在过期前始终有效,服务器没有简单的方法来撤销它们。
以下是一些可能导致危险的使用场景。
注销实际上并没有注销您!
想象你在 Twitter 上发了一条推文然后登出。你可能认为你已经从服务器登出,但事实并非如此。
JWTs 是自包含的,它们在过期之前始终有效,这可能是在令牌中设置的 5 分钟、30 分钟或任何持续时间。
因此,如果有人在那时获得此令牌,他们可以继续访问您的账户,直到它过期。
陈旧数据
想象一个用户原本是管理员,但被降级为拥有较少权限的普通用户。再次强调,这不会立即生效,用户将继续拥有管理员权限,直到令牌过期。
JWTs 通常不加密
这意味着任何能够执行中间人攻击并嗅探 JWT 的人都将拥有您的认证凭据。这变得更容易,因为攻击只需要拦截服务器和客户端之间的连接。
安全问题
关于 JWT 是否安全,我们可以参考这篇文章:
JWT (JSON Web Token) (在)安全性 — research.securitum.com
结论
总结来说,JWTs 适合作为在两个实体之间传输声明的单次授权令牌。
然而,JWT 不适合作为长期持久数据存储机制,尤其是用于管理用户会话。
使用 JWT 进行会话管理可能会引入一系列严重的安全和实现问题。
相反,传统的会话机制,如会话 cookie 及其成熟的实现,更适合存储长期持久数据。
尽管如此,如果您仅出于开发和学习目的使用 JWT,不考虑安全性和性能,那么这完全没问题。
然而,一旦你开始处理生产环境,你需要避免这些潜在问题。
没有回复内容