如何识别Firebase Auth登录用户并关联应用TODO数据？

核心结论先给 #

你选择用Firebase UID做用户和业务数据的关联是完全正确的选择——这个UID是Firebase生成的全局唯一、稳定、不含任何用户隐私的字符串，完全满足你不想存储用户邮箱的要求，也是官方推荐的跨系统关联用户的标准方案，不存在隐私合规问题。
下面分两种场景给出可直接落地的实现，优先匹配你不想改动现有CRUD架构的需求。

优先方案：保留现有Spring Boot + H2 CRUD架构 #

这个方案只需要在现有代码基础上做增量改造，不需要推翻重写，迁移成本最低：

1. 前端改造请求传递逻辑
   用户在Firebase Auth登录后，每次向后端发起TODO的增删改查请求时，必须从Firebase Auth实例中获取当前用户的有效ID Token，把Token放到请求头中传递：
   Authorization: Bearer <firebase-id-token>
   注意：绝对不要直接把前端拿到的UID当成请求参数传给后端，否则攻击者可以直接篡改参数里的UID，越权访问或修改其他用户的数据。
2. Spring Boot后端增加鉴权拦截能力
   直接引入Firebase Admin SDK实现统一的Token校验拦截，不需要自己手写验签逻辑：
   • 拦截所有业务接口的请求，校验请求头里的ID Token是否有效、是否过期
   • 从校验通过的Token中解析出对应的真实Firebase UID，存到当前请求的ThreadLocal上下文里，供后续业务逻辑使用
   • 校验不通过的请求直接返回401状态码，不允许访问任何业务接口
3. H2数据库表结构调整
   在原有TODO表中新增一个非空字段：firebase_uid varchar(128) not null，给这个字段加上普通索引，用来快速筛选对应用户的TODO数据。
   不需要额外建独立的用户表，所有用户的基础信息已经由Firebase Auth托管，你只需要在业务表中存这个UID即可。
4. 改造所有CRUD接口的逻辑
   从根源上杜绝越权问题，所有数据库操作必须强制绑定当前上下文的UID：
   • 写操作（新增/编辑TODO）：写入或更新TODO记录时，直接从请求上下文取UID填充到firebase_uid字段，完全不接受前端传来的用户标识参数
   • 读操作（拉取TODO列表）：所有查询SQL必须加上过滤条件：where firebase_uid = <当前请求的UID>，永远不返回不属于当前用户的数据
   • 删操作：删除TODO记录时，SQL必须同时带上TODO主键和UID两个过滤条件，不能只靠TODO主键删除，避免用户删除他人数据

关键原则：所有和用户身份相关的判断，必须基于服务端校验Token后解析出的UID，绝对不能信任前端传来的任何用户身份字段，否则越权风险完全不可控。

备选方案：切换为Firebase NoSQL数据库实现 #

如果后续你不想维护Spring Boot后端服务，可以基于已经配置好的Firebase Auth快速搭建完整应用，完全不用自己写鉴权和权限控制逻辑：

1. 直接使用Firestore（Firebase提供的NoSQL数据库），新建todos集合，每个TODO文档中新增owner_uid字段，存当前用户的Firebase UID
2. 配置Firestore的安全规则，从平台层强制约束所有操作：只有当request.auth.uid == resource.data.owner_uid时，才允许对对应文档进行读、写、删除操作，不满足条件的请求直接拒绝
3. 前端通过Firebase SDK直接连接数据库操作TODO数据，不需要自己写后端接口，天生就带用户数据隔离能力
   这种方案适合轻量的TODO类应用，完全省去了后端服务维护、接口安全校验、数据库运维的成本。

两种方案的取舍参考 #

• 保留现有CRUD架构：适合后续需要扩展复杂业务逻辑（比如批量数据统计、多权限角色、复杂SQL查询）的场景，前期已经写好的业务逻辑不需要推翻，只需要增量加鉴权能力即可上线
• 切换Firebase NoSQL：适合追求最快开发速度、不需要复杂业务逻辑的轻量应用，全程不需要管服务器、证书、接口安全这些维护性工作

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