Phase 4 / Ep 17: OAuth 2.0 实现的安全审计

⏱ 预计阅读 3 分钟 更新于 2026/4/13

进入了我们要和 Google Calendar 做真实集成的深水阶段。在上一阶段，我们在本地完成了算法的 TDD 跑通。现在我们要建立连接。

第一张多米诺骨牌就是用户的登录鉴权（Google OAuth）。 如果你直接让普通大语言模型帮你写“Google OAuth 登录逻辑”，它大概率会在 30 秒内甩给你一段看起来很完整的代码。

但是别高兴太早！那段没有受限配置的代码绝对漏洞百出： 它可能不会加上 state 参数防护 CSRF 跨站请求伪造； 它存下的 access_token 很可能没有加上 httpOnly 和 Secure 的 Cookie 标识； 甚至它还会傻傻地把你本地的回调路由和生产的写在了一起。

1. 从“帮我写”变成“按安全表单执行”

在 Agentic 开发流管辖下，你必须杜绝这种“无防护生成”。我们要把我们在传统全栈开发里积淀的安全经验，前置为 Agent 的 CheckList。

我们将更新之前的 task_plan.md，在这个步骤的详情里，挂接强制要求：

“在执行 [对接 Google OAuth 鉴权回调层] 时，你强制需要对比行业最严格的安全审计基线。你写完代码后，必须通过以下内部自审 CheckList 并给我一份结果报告才能提交：

  • [ ] 是否启用了 state 参数进行会话校验？
  • [ ] 获取的 Access Token 和 Refresh Token 是否被严格设置在了 httpOnly 且跨域限制的 Cookie/Session 中？绝对禁止暴露给客户端 Window。
  • [ ] 接口发生错误时，是否向前端屏蔽了真实的栈追踪（Stack Trace）以防后端配置泄露？”

2. Agent 的内部对抗赛

当 Agent 接受到这样的指引后。原本它顺手准备写下的劣质代码块，会重新退回重写池中。 它将一边开发 Next.js 的服务端回调路由 app/api/auth/callback/route.ts，一边调用浏览器或分析器自我核实这三个 [ ]。

等到系统给你回复时，它不会只有轻飘飘的“写完了”三个字，而是附带一份： “安全自审完成。已注入 Crypto 随机字节生成并拦截 CSRF。存储方案选用 HTTPOnly Cookie。” 这样的硬核声明。

这就是质的飞跃。此时的 AI 已经不仅是一个无脑干活的 Junior（初级）员工，它开始具备了 Senior（高级程序员）审慎防守的安全防风衣。

登录打通，拿到权限，只是万里长征第一步。下一步是如何解决开发日历系统的千古难题：到底听谁家的日历？