登录鉴权方案怎么设计提示词（Session 与 JWT 怎么选、刷新令牌、退出登录与强制下线、令牌存储位置）
新项目要做登录鉴权，或者现有方案出了问题（退出登录后令牌仍然有效、改密码后旧设备还能用、令牌被盗用）时用：AI 根据客户端类型和安全要求在会话与 JWT 之间做选择，设计令牌有效期、刷新与轮换、吊销和存储方式，并给出关键代码和安全检查清单。
通用大模型 对话模型通用
你是一名身份认证与安全方面的后端架构师。请为我的项目设计登录鉴权方案。 - 客户端类型：[客户端类型]（例：同域 Web、App、小程序、第三方调用） - 用户规模与部署：[规模与部署]（例：10 万用户，多实例部署） - 安全要求：[安全要求]（例：改密码后所有设备下线，后台可强制下线） - 登录方式：[登录方式]（例：账号密码、短信验证码、第三方登录） - 技术栈：[技术栈] - 现有方案（如果有）： [现有方案说明] 请输出： 1. 方案选择：服务端会话与 JWT 各自的优缺点（吊销难易、横向扩展、跨域与移动端、性能），结合我的客户端类型和安全要求给出推荐。说明「JWT 天然无状态」这一说法在需要吊销时的局限。 2. 令牌设计（如果使用令牌）： - 访问令牌短期有效，刷新令牌较长期有效；刷新令牌每次使用后轮换，并检测旧刷新令牌被重复使用（可能被盗）的情况； - 令牌中只放必要的标识，不放敏感信息； - 签名算法与密钥管理，校验时固定允许的算法。 3. 存储位置： - Web 端：使用带安全属性的 Cookie（仅 HTTP 访问、仅 HTTPS、同站策略）与放在浏览器本地存储的风险对比，以及对应的跨站请求伪造防护； - App 端：使用系统提供的安全存储。 4. 吊销与下线：退出登录、修改密码、后台强制下线、可疑登录时，如何让已发出的令牌或会话失效（例如令牌版本号、黑名单、删除会话）。 5. 登录接口的防护：限制失败次数与频率、统一的错误提示（不暴露「用户不存在」）、密码使用专门的慢哈希算法存储。 6. 给出关键代码：登录、刷新、校验中间件、退出登录。 7. 安全检查清单。
高亮处换成你自己的内容：[客户端类型]、[规模与部署]、[安全要求]、[登录方式]、[技术栈]、[现有方案说明]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[客户端类型] 是选型的关键：同域的 Web 应用使用服务端会话加 Cookie 往往最简单也最安全；有 App、小程序或第三方调用时，令牌方案更合适。[安全要求] 写清楚是否需要「改密码后所有设备下线」「后台强制下线」，这直接决定了是否需要服务端保存状态。
常见坑：
- 选择 JWT 后才发现退出登录、改密码都无法让旧令牌失效，只能等它自然过期。需要吊销能力时，必须在服务端保存一些状态。
- 把令牌放在浏览器本地存储，一旦页面存在跨站脚本漏洞，令牌就会被直接读走。
- 刷新令牌有效期很长又不轮换，被盗后攻击者可以长期冒充用户。
追问技巧：追问「加上第三方登录（如微信、Apple）后，账号绑定和合并怎么设计」，或「设计异地登录提醒和设备管理页面」。
示例输出
示例，仅供参考（同域 Web + App，节选）
推荐：Web 端使用服务端会话加安全 Cookie；App 端使用短期访问令牌（15 分钟）加可轮换的刷新令牌（30 天）。两端共用一张会话表，用于吊销。
| 场景 | 处理方式 |
|---|---|
| 退出登录 | 删除当前会话记录；App 端同时作废该会话的刷新令牌 |
| 修改密码 | 用户表中的令牌版本号加 1，所有旧令牌校验失败 |
| 刷新令牌被重复使用 | 判定为可能被盗，作废该用户的整个令牌家族并要求重新登录 |
js
// 校验中间件（节选）：校验签名后，再比对令牌中的版本号
const payload = jwt.verify(token, PUBLIC_KEY, { algorithms: ['RS256'] }) // 固定允许的算法
const user = await users.findById(payload.sub)
if (!user || user.tokenVersion !== payload.ver) throw new Unauthorized()同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～