Node.js分离认证服务与Express应用部署交互问题

访问失败核心是混淆了双服务的角色与端口映射规则：

• 两个服务的端口与角色对应关系可直接从启动配置读取：
  • users目录下的认证服务：启动脚本固定配置PORT=5858，属于后端内部服务，不直接面向终端浏览器提供页面访问能力
  • notes目录下的业务服务：是唯一面向用户提供页面访问的入口服务，执行默认npm start启动时Express默认监听3000端口；执行start-server1脚本时监听3000端口；执行start-server2脚本时监听3002端口
• 此前尝试的地址全部存在错误：
  • 配置中从未映射5000端口，访问该端口自然无响应
  • Node服务启动后直接通过监听端口响应HTTP请求，和项目在服务器上的物理目录路径（my_application、users这类目录名）不存在URL映射关系，将目录名写入URL路径的写法完全不成立
• 正确访问规则：
  本地开发环境直接访问http://localhost:3000（默认/start-server1启动）或http://localhost:3002（start-server2启动）即可；如果服务部署在域名为www.domain.com的公网服务器上，对应访问http://www.domain.com:3000或http://www.domain.com:3002，前提是服务器防火墙已开放notes服务对应的监听端口。

基础交互逻辑 #

两个服务为服务端内部调用关系，notes服务配置项中的USER_SERVICE_URL=http://localhost:5858是notes服务调用users服务的内部地址，该地址不需要暴露给公网，只要notes服务所在运行环境可正常访问即可。

Session+Passport认证完整流程 #

1. 用户首次访问notes服务的受限页面时，notes服务检测到请求未携带有效会话信息，直接返回登录页面
2. 用户在登录页提交账号密码后，notes服务不自行处理账号校验逻辑，而是在服务端发起内部HTTP请求，将用户提交的认证信息转发给5858端口的users服务
3. users服务收到校验请求后查询自身存储的用户数据：如果对应用户不存在则自动创建新用户，校验密码等凭证是否匹配，最终将校验结果（含用户ID、用户名、权限范围等基础信息）返回给notes服务
4. notes服务收到users服务返回的认证成功响应后，通过express-session生成唯一会话标识（Session ID），通过Set-Cookie响应头将Session ID写入用户浏览器的Cookie存储，后续用户发起的所有请求都会自动携带该Cookie
5. 用户后续访问notes服务时，notes服务首先从请求Cookie中解析出Session ID，从自身会话存储中匹配到对应用户信息，确认登录状态有效后再处理笔记增删改查等业务请求；如果需要二次校验用户合法性，notes服务会携带用户标识再次请求users服务做核验。

架构安全原理 #

• 收缩攻击面：负责敏感认证逻辑的users服务不直接暴露给公网，仅允许内部服务调用，大幅降低被恶意扫描、攻击的概率
• 敏感数据隔离：用户账号、密码哈希等核心认证数据全部存储在users服务侧，notes服务仅保存会话信息不存储用户敏感凭证，就算笔记业务被攻破，也不会直接泄露全量用户的认证数据
• 凭证访问控制：存储在浏览器Cookie里的Session ID默认开启HttpOnly属性，前端页面脚本无法读取，可有效避免XSS攻击窃取用户登录凭证
• 传输链路安全：两个服务之间的认证请求走服务端内部网络，不需要经过公网传输，降低凭证在服务间调用时被窃听的风险

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