如何支持社交登录并始终返回自有API的访问令牌？

一、方案推荐：优先扩展自有OAuth2/OIDC服务器 #

对于需要统一返回自有API访问令牌的场景，扩展自有OAuth2/OIDC服务器以支持多登录方式是更主流、更推荐的方案，原因如下：

• 完全掌控用户身份生命周期：所有用户（本地账号/社交账号）的身份数据都在自有系统中管理，包括账号关联、权限配置、数据同步等，无需依赖第三方代理的稳定性。
• 统一令牌体系：用户无论通过哪种方式登录，最终拿到的都是自有系统颁发的access token，前端无需区分令牌类型，直接用于调用自有API，体验更流畅。
• 实现逻辑清晰：在自有授权服务器中新增社交登录的身份验证模块即可，流程大致为：
  1. 用户选择Facebook登录，前端跳转至自有授权服务器的社交登录入口；
  2. 自有服务器向Facebook发起OIDC认证请求，完成用户身份校验；
  3. 自有服务器根据Facebook返回的用户信息，创建新的本地用户或关联已有本地账号；
  4. 自有服务器颁发自有API的access token、refresh token给前端。

身份代理（identity broker）更适合已有多套独立身份系统、无法大规模改造现有授权架构的场景。它作为中间层转接不同身份提供商的认证请求，再转换为自有系统的令牌，但会增加系统复杂度和依赖点，用户登录流程可能存在额外跳转，体验不如前者。

二、先社交登录再获取自有令牌：完全可行 #

这种分步实现的方式是完全可行的，也是很多系统的实际落地方案，具体流程如下：

1. 第一步：完成社交平台的标准OIDC/OAuth登录
   用户通过前端发起Facebook的OIDC认证流程，拿到Facebook颁发的id_token（包含用户身份信息）和access_token（用于调用Facebook API）。
2. 第二步：换取自有API的访问令牌
   前端将Facebook的id_token发送至自有后端的令牌兑换接口；
   自有后端严格验证id_token的合法性（包括签名校验、issuer匹配、过期时间检查等）；
   验证通过后，后端为该用户创建本地账号（首次登录）或关联已有本地账号，然后颁发自有API的access_token给前端。

需要注意的细节：

• 必须严格验证社交平台令牌的合法性，避免伪造身份请求；
• 首次登录时可引导用户补充必要的本地账号信息（如自定义用户名），或直接用社交平台的昵称、头像初始化本地账号；
• 可将社交账号的唯一标识（如Facebook的user ID）存储在本地用户表中，用于后续自动关联登录。

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