别让 AI 裸奔你的用户系统：vibe 项目登录与权限实战 5 件套

为什么 auth 是 AI 最容易翻车的地方

让 AI 写一个登录功能，它 30 秒给你整出全套：注册表单、登录接口、JWT 签发，看起来有模有样。但安全研究者早就发现，AI 生成的认证代码是漏洞重灾区：密码明文存数据库、JWT 设成永不过期、重置密码链接不设有效期、"记住我"做成前端 localStorage 里的明文 token。更隐蔽的是越权漏洞——A 用户把 URL 里的 /users/123 改成 /users/124，就看到了别人的订单。

问题的根子不在 AI 笨，而在认证是"看起来能跑"和"真的安全"差距最大的模块。CRUD 写错了，页面上立刻看得出来；auth 写错了，功能完全正常，只是门没锁——你要等到被脱库那天才知道。这篇指南把登录与权限拆成 5 件套，每一件都给出"让 AI 做"和"人必须亲自把关"的分界线。

第一件：选型——自研、托管服务，还是开源方案

第一决策永远是：不要自己写密码学，但"自己写 auth 流程"和"用托管服务"是两回事。决策表如下：

选托管服务（Clerk、Auth0、Supabase Auth）：当你的项目需要邮箱/手机/社交登录、MFA、组织（organization）/团队功能中的任意两项，直接上托管。vibe 项目的典型画像——一人团队、要快、上线后用户量不确定——托管服务是默认最优解。你付的是每月几十美元，买的是"半夜不用起来修登录 bug"的睡眠。Supabase 用户还有个天然优势：Supabase Auth 和数据库行级安全（RLS）是原生集成的，权限规则可以直接写在数据库层。

选开源自托管（Better Auth、Auth.js）：当你对数据主权敏感、用户量可预期、或者就是想把用户表攥在自己手里。Better Auth 这两年在 vibe 圈子里很火，因为它和主流全栈框架的集成是"AI 友好"的——文档里的代码片段直接能跑，AI 很少 hallucinate 它的 API。

选完全自研：只有一种情况成立——你的登录流程本身就是产品差异化（比如 Web3 钱包登录、硬件密钥强绑定的特殊场景）。否则，自研 auth 是经典的"重复造轮子 + 附赠漏洞"套餐。

一句话决策：先问"我需要几种登录方式"，超过一种就别自研；再问"用户数据能不能出境"，不能就自托管开源方案。把这个结论写进 README，让三个月后的你和 AI 都别再纠结。

第二件：会话机制——JWT 还是 session，一次讲透

这是 AI 最爱和稀泥的地方："用 JWT 吧，现代、去中心化。"别被忽悠，选型看场景：

浏览器 Web 应用：优先 session cookie（httpOnly + Secure + SameSite）。理由很硬：httpOnly 的 cookie JS 读不到，XSS 偷不走 token； SameSite=Lax 挡掉大部分 CSRF。JWT 放 localStorage 是 vibe 项目最高频的安全反模式——只要页面有一个 XSS 漏洞，你的用户 token 就是攻击者的提款机。AI 生成的代码十个有九个把 token 塞 localStorage，因为"这样前后端分离很优雅"——优雅和安全，这里只能二选一。

移动 App / 纯 API / 第三方集成：用短有效期 JWT + refresh token 轮换。access token 15 分钟过期，refresh token 存安全存储（iOS Keychain / Android Keystore），每次用 refresh 换新的 access token 时把旧 refresh 作废（rotation）。这样即使 access token 泄露，攻击窗口也只有 15 分钟。

token 生命周期是门手艺：access token 短（分钟级）、refresh token 中（天级，可撤销）、密码重置 token 一次性 + 1 小时过期、邮箱验证 token 24 小时过期。让 AI 生成 auth 代码时，把"每个 token 的有效期"写进需求里，否则它默认给你"永不过期"——这是 AI auth 代码里最常见的坑，没有之一。

第三件：密码与凭证——三条铁律

密码处理只有三条铁律，违反任何一条都是 P0 事故：

铁律一：密码只存哈希，用 argon2id 或 bcrypt，绝不自创算法。让 AI 写的时候明确指定算法和参数（比如 argon2id 内存 64MB、迭代 3 次），否则它可能给你整出 MD5 加盐——2026 年了，MD5 撞库是秒级的。顺带：注册时校验密码强度用 zxcvbn 这类库，别自己写"必须含大小写+数字+符号"的正则，那是 2010 年的做法，用户体验还差。

铁律二：所有 secret 只活在服务端环境变量里。JWT 签名密钥、OAuth client secret、数据库密码——出现在前端代码、Git 仓库、AI 对话记录里的 secret 都算泄露。给 AI 的铁律是：让它读 process.env，不许它把密钥写进任何文件。上线前跑一遍 git log -p | grep -i secret 级别的自查，或者直接上 gitleaks 这类工具扫一遍。

铁律三：重置密码流程用"一次性 token + 短有效期 + 用后即焚"。AI 生成的重置流程常犯三个错：重置链接永久有效、token 和用户 id 可预测（比如 /reset?userId=123）、重置成功后旧 token 还能用。正确做法：加密随机 token（至少 32 字节）、1 小时过期、使用后立即失效、重置成功后让该用户所有会话失效（防止攻击者用旧会话继续赖着）。

第四件：授权模型——认证是"你是谁"，授权是"你能干什么"

很多 vibe 项目死在把"登录了"当成"有权限"。授权模型从 RBAC（基于角色）起步就够了，但有三处 AI 一定会漏：

第一处：资源级检查——"只能看自己的数据"。这是越权漏洞（IDOR）的重灾区。AI 写的 GET /api/orders/:id 通常是"查出订单就返回"，不会加"且订单属于当前用户"。修复方法是每个查资源的接口都带上 owner 检查，或者更彻底一点：用数据库 RLS（Supabase/Postgres）把规则下沉到数据层，这样即使 API 层漏了，数据库也不放行。让 AI 写接口时，在需求里加一句"所有资源接口必须校验资源归属"，能挡掉 90% 的 IDOR。

第二处：管理后台别硬编码。AI 最爱写 if (user.email === 'admin@xxx.com') 就放行。正确做法是 role 字段 + 中间件：requireRole('admin')。管理后台单独部署、单独域名、加 IP 允许名单或 VPN，是加分项。

第三处：权限变更要审计日志。谁把谁设成了管理员、谁导出了全量用户数据——这些操作记一条不可删的审计日志。不是为了抓内鬼，是为了出事后能回答"影响面有多大"。vibe 项目可以轻量做：单独一张 audit_logs 表，只 insert 不 update，定期归档。

第五件：防护加固——登录接口是攻击者的第一站

登录、注册、重置密码这三个接口，是全站被扫描最频繁的入口，防护清单如下：

防暴破：登录接口加限流（比如同一 IP 1 分钟 5 次，同一账号 10 分钟 10 次），超限后加验证码而不是直接锁账号（锁账号会被用来恶意锁别人的号）。AI 写限流中间件时，提醒它用 Redis 计数 + 滑动窗口，别用内存 Map（多实例部署下内存计数各自为政）。

防用户枚举："该邮箱未注册"和"密码错误"要返回完全相同的错误信息和响应时间。"用户不存在"这种贴心提示，是攻击者批量验证邮箱库的免费 oracle。注册接口同理：已注册邮箱的提示要模糊处理（"如果该邮箱存在，验证邮件已发送"）。

OAuth 防 CSRF：state 参数必须随机生成、存 session、回调时校验。AI 接 GitHub/Google 登录时，十次有八次会把 state 写成固定字符串或干脆省略——这是 OAuth 流程里最高频的真实漏洞。

日志脱敏：登录日志记"谁、何时、从哪个 IP、成功与否"，永远不记密码、token、完整手机号。让 AI 写日志代码时加一条铁律：任何凭证类字段，日志里只留后四位或直接打码。

给 AI 的 prompt 模板 + 人的 10 问 review 清单

最后是可直接抄的两件工具。先是让 AI 写 auth 功能时的 prompt 模板（粘给任何 agent 都能用）：

实现邮箱+密码登录。要求：1）密码用 argon2id 哈希存储；2）会话用 httpOnly + Secure + SameSite=Lax 的 session cookie，不用 localStorage 存 token；3）access token 15 分钟过期；4）所有资源接口必须校验资源归属当前用户；5）登录接口加限流（IP 1 分钟 5 次）；6）登录失败返回统一错误信息，不区分用户不存在还是密码错误；7）secret 全部从环境变量读取，不许写进代码。先输出设计（表结构+接口列表+token 生命周期），我确认后再写代码。

关键在最后一句：让 AI 先输出设计再写代码。auth 这种模块，设计 review 的价值是代码 review 的十倍——表结构定错了，后面全是补丁。

人必须亲自过的 10 问清单：密码是哈希存的吗（看 migration，不看代码）？JWT/cookie 的有效期是几分钟不是几年？secret 在不在仓库里（跑 gitleaks）？改 URL 里的 id 能不能看到别人的数据（亲手试）？登录失败提示是不是统一的？OAuth 的 state 校验了吗？管理后台有独立的 role 检查吗？重置链接用一次就失效吗？日志里有没有明文凭证？删账号/改密码后旧会话失效了吗？

这 10 个问题，每个都是真实世界出过 P0 事故的坑。vibe coding 的速度优势不应该建立在"门没锁"的基础上——auth 是唯一一个"慢就是快"的模块：上线前多花两小时按清单走一遍，省的是凌晨三点的事故电话。