使用Auth0授权时通过azp关联自有用户库的注册流程是否合理

你当前的方案不可行，核心错误是选错了跨系统用户关联的字段。

azp（Authorized Party，授权方）字段存储的是发起授权请求的OAuth客户端ID，也就是你自己的应用在Auth0后台配置后生成的固定Client ID。所有从你这个应用发起登录的用户，拿到的Access Token里的azp值完全相同，根本不具备用户维度的区分度，用这个字段查库会出现所有用户匹配到同一条记录、完全无法区分身份的严重问题。

1. 选对关联字段 #

你应该用OIDC规范定义的标准用户标识字段sub（Subject，主体）作为自建库和Auth0用户的关联键：

• 这个字段是Auth0为每个用户生成的全局唯一ID，格式类似auth0|654321abcdef、google-oauth2|123456789，同一个Auth0用户实体的sub值永久固定，不会随用户修改昵称、邮箱等信息变动
• 这也是Auth0官方明确推荐的跨系统用户关联字段，不存在歧义。

2. 表结构调整 #

在你的users表中新增auth0_sub字段，类型设为字符串，加唯一索引，专门用来存储Auth0返回的用户sub值，不要和其他字段混用。

3. 流程实现 #

注册/用户记录创建 #

两种实现方式选一个就行，新手推荐第二种：

• 方式一：配置Auth0的注册后钩子（Post Registration Action），用户在Auth0侧完成注册的瞬间，钩子会拿到新用户的sub等基础信息，自动调用你的后端服务接口，在users表插入对应用户记录，同时把sub值存入auth0_sub字段
• 方式二：不做提前同步，用户每次登录后，你的后端验证完Token拿到sub值，先查库判断是否存在auth0_sub匹配的记录，不存在就自动初始化一条对应用户记录，存在就直接返回用户数据，逻辑更简单，不需要额外配置钩子。

登录后用户数据查询 #

• 前端拿到Auth0颁发的Access Token后，请求你的业务API时把Token放在请求头里
• 你的后端收到请求后，必须先按规范验证Token的签名、过期时间、签发方、受众合法性，绝对不能直接解析未经验证的Token payload就用
• 验证通过后，从Token payload中取出sub字段值，用这个值作为查询条件：SELECT * FROM users WHERE auth0_sub = ?，就能准确匹配到对应用户的自有数据。

• 不要用邮箱、手机号作为和Auth0的关联键：用户可以修改Auth0绑定的邮箱/手机号，第三方社交登录返回的邮箱也可能存在变动、重复的问题，会导致关联错乱
• 不要信任前端传过来的用户ID：所有用户身份标识必须从后端自己验证通过的Token里提取，否则会出现越权访问漏洞
• 不要随便自定义关联字段，就用标准的sub字段，兼容性最好，后续如果加社交登录、企业身份源也不需要改逻辑。

内容的提问来源于stack exchange，提问作者Michael P.