使用Firebase认证的SpringBoot API是否需额外要求请求传UserID

直接以请求头JWT Token解码得到的UserID作为当前登录用户身份的唯一可信来源，完全不需要额外在请求体/请求参数中要求传入当前用户的UserID，核心原因如下：

• 安全层面：请求携带的UserID属于用户可篡改的输入，即使你设计了和JWT解码结果的校验逻辑，只要出现逻辑遗漏就会产生越权漏洞，比如用户传入他人的UserID请求不属于自己的敏感数据。JWT本身由Firebase签发，无法篡改，解码后的身份信息天然可信。
• 开发效率层面：你计划用SpringBoot过滤器统一解码JWT生成全局可用的User对象的方案非常合理，业务层直接从请求上下文拿用户信息即可，不需要每个接口都重复定义UserID参数、做重复校验，大幅减少冗余代码。
• 维护层面：额外要求传UserID会增加前后端联调成本，前端所有需要登录态的接口都要多传一个参数，一旦出现参数名、格式不统一的情况还会产生不必要的线上bug。

如果你是希望通过参数来体现「该接口业务逻辑依赖当前用户UserID」的文档作用，也完全不需要靠传参实现，有两种更合理的替代方案：

• 在接口文档的权限说明板块标注该接口需要登录态、会读取当前登录用户身份即可，不需要把UserID定义为请求参数。
• 代码层面可以在业务方法上加注释说明，或者直接从上下文读取User对象的代码本身就已经能体现逻辑依赖当前登录用户的信息。

特殊场景例外 #

只有一种场景需要额外传入UserID：当业务逻辑是操作其他用户的资源，比如管理员修改指定用户的信息，这时候传入的UserID是操作对象的ID，而非当前登录用户的ID，和你问的「当前请求用户的身份来源」不属于同一类场景。

SpringBoot落地建议 #

建议直接用Spring Security整合Firebase Auth的适配方案，解码后的认证信息默认存储在SecurityContextHolder中，整个请求链路随时可以调用获取，不需要自己封装用户上下文，避免出现线程安全问题。

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