为何NestJS认证示例结合使用passport-local与passport-jwt策略

核心结论 #

仅使用passport-jwt完成认证是完全可行的，但仅适用于特定场景，面向普通用户的公开服务场景下不属于最佳实践。 #

具体原因说明 #

• 首先要明确两个Passport策略的分工差异：
  • passport-local的作用是首次身份校验：仅在登录接口调用，校验用户提交的用户名、密码是否和数据库存储的一致，校验通过后才会签发JWT返回给客户端
  • passport-jwt的作用是后续请求鉴权：登录完成后，客户端的所有业务请求携带JWT，服务端只需要用JWT策略校验凭证有效性即可，不需要每次都验证账号密码
• 如果你要在面向普通用户的服务中仅使用passport-jwt，必须解决「首次JWT凭证如何发放」的问题：
  • 方案1：提前给所有用户预发长期有效的JWT，这种模式下无法支持用户自主登录、修改密码、主动登出等常规功能，还要额外维护JWT黑名单来处理凭证泄露问题，反而提升了系统复杂度
  • 方案2：每次请求都携带用户名密码，服务端校验通过后临时生成JWT再做鉴权，这种模式等于把高敏感的账号密码在每次请求中都传输，被中间人截获的风险远高于只传短期有效的JWT，安全等级极低

官方示例的逻辑说明 #

NestJS官方文档的示例采用两种策略结合的实现，本身就是面向普通用户服务的标准最佳实践，不存在不符合最佳实践的问题：两种策略分别负责不同的认证环节，同时兼顾了安全性和易用性。
仅在以下特定场景中，仅使用passport-jwt属于最佳实践：

• 纯内部服务，调用方都是预先授信的内部系统，不需要用户登录流程
• 所有调用方的JWT都可以提前安全分发，不需要通过账号密码申请凭证

内容的提问来源于stack exchange，提问作者Oscar Rénier