如何在Supabase外做认证并对接RLS及处理刷新令牌

问题1：RLS生效应选择app_metadata还是user_metadata？ #

核心看字段的用途和可控性：

• app_metadata：属于应用级元数据，由后台管理，用户无法自行修改，适合存放权限、角色、应用逻辑相关的字段（比如用户所属组织ID、权限等级）。RLS规则中如果需要基于应用层面的权限控制，优先用这个字段，安全性更高。
• user_metadata：属于用户自定义元数据，通常存放用户个人属性（比如昵称、头像URL），用户可通过接口修改。如果RLS规则是基于用户自身可编辑属性（比如根据地区过滤数据），可以用这个字段。

结合你的外部用户管理场景，推荐把RLS需要的控制字段放在app_metadata中，避免用户篡改元数据影响RLS规则的有效性。

问题2：手动生成JWT时处理Supabase ORM的刷新令牌 #

因为用户管理完全在Supabase外部，无法复用其内置刷新令牌机制，需要自行实现一套刷新逻辑：

1. 在Express侧维护会话

   • 用MongoDB存储用户会话记录，包含：用户ID、自定义生成的刷新令牌（建议用UUIDv4这类长随机字符串）、刷新令牌过期时间、关联的访问令牌信息。
   • 生成访问令牌时，同步生成对应的刷新令牌，返回给前端（前端建议用HttpOnly Cookie存储）。

2. 实现刷新接口

   • 在Express中编写刷新令牌接口，接收前端传入的刷新令牌。
   • 验证令牌有效性：检查MongoDB中是否存在该令牌、是否未过期、关联用户状态是否正常。
   • 验证通过后，用现有JWT生成逻辑生成新的访问令牌，返回给前端。

3. Supabase ORM客户端适配

   • 监听Supabase客户端的令牌过期事件，或者在每次请求前主动检查令牌过期时间。
   • 检测到令牌过期时，调用Express的刷新接口获取新令牌。
   • 调用supabaseServerClient.auth.setAuth(newAccessToken)更新客户端认证令牌，后续ORM请求将自动使用新令牌。

额外注意：

• 自定义刷新令牌要设置合理过期时间（比如7天），并支持主动失效（比如用户登出时从MongoDB删除对应会话记录）。
• 刷新接口要做好安全防护，比如限制请求频率、验证请求来源。

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