基于NestJS+NextJS的JWT认证架构：是否可行且过度设计？

你的核心需求是避免JWT暴露给客户端，通过Next.js API路由作为中间层处理令牌流转，在Next.js+NestJS的架构下是完全合理的设计，甚至是实现“令牌服务端托管”的最优路径之一。

为什么这个方案合理？ #

• 直接命中安全需求：如果让客户端直接和NestJS交互，JWT必然会出现在客户端的存储（localStorage、内存）或请求中，存在XSS窃取风险。用Next.js API路由中转后，令牌完全在服务端流转，客户端仅能拿到一个无敏感信息的会话标识，根本接触不到JWT，完美解决你的核心顾虑。
• 架构分层清晰：Next.js API路由本身就是服务端运行的代码，天然适合做反向代理、权限校验这类中间层工作，和NestJS的业务认证逻辑分工明确，不属于冗余设计。

具体实现思路 #

1. 登录流程 #

• 客户端（Next.js前端）向/api/auth/login发起登录请求，传递用户名密码
• Next.js API路由将请求转发给NestJS的登录接口
• NestJS验证通过后生成JWT，返回给Next.js API路由
• Next.js API路由将JWT存入Redis等分布式会话存储，同时给客户端返回一个sessionId，存在HttpOnly、Secure属性的Cookie中（禁止客户端脚本访问）

2. 业务请求流程 #

• 客户端向/api/xxx（Next.js API路由）发起业务请求
• Next.js API路由从Cookie中取出sessionId，到Redis中匹配对应的JWT
• 携带Authorization: Bearer <JWT>请求头，将请求转发给NestJS的对应接口
• NestJS验证JWT有效性后处理请求，结果由Next.js API路由转发回客户端

3. 关键注意事项 #

• 必须用Redis这类分布式存储存放JWT，避免Next.js多实例部署时会话丢失
• 在Next.js API路由中处理异常：比如sessionId无效、JWT过期时，返回401状态码触发客户端重新登录
• NestJS的JWT设置合理过期时间，同时在Next.js层实现Refresh Token逻辑（同样存储在服务端），避免频繁登录

简化方案参考 #

如果项目规模极小、安全要求不极端，也可以让NestJS直接设置HttpOnly、Secure的Cookie存储JWT，客户端直接请求NestJS接口，无需Next.js中转。但这种方式会让前端和后端耦合度更高，后续加缓存、日志等通用逻辑不如中间层灵活。

内容的提问来源于stack exchange，提问作者notVansh