如何让OAuth2适配现有Asp.Net Identity用户表并正常运行？

关于授权码流程被自动处理的问题 #

这个是ASP.NET Core身份认证封装的正常表现，你不需要手动处理授权码交换逻辑：你调用的AddGoogle()扩展方法已经完整封装了OAuth2.0授权码流程的所有中间步骤，它内部自动完成了以下操作：

• 接收Google回调返回的授权码
• 用授权码向Google接口换取access_token、id_token
• 用token请求Google用户信息接口拉取用户公开信息
• 把所有返回的信息组装成Claims身份标识，最终写入认证Cookie
  你在回调路径拿到的已经是封装处理完的结果，不是流程出了问题。

关联存量ASP.NET Identity用户的方案 #

你提到的邮箱匹配思路可用，但存在用户修改Google邮箱后匹配失效的风险，更稳妥的方案是结合ASP.NET Identity自带的第三方登录关联表AspNetUserLogins实现，具体逻辑如下：

• 优先用Google返回的用户唯一标识（对应Claims里的ClaimTypes.NameIdentifier）做关联依据，这个ID是Google侧用户的永久唯一标识，不会变更
• 首次Google登录的用户处理逻辑：
  1. 先查AspNetUserLogins表，是否存在LoginProvider为Google、ProviderKey为当前Google用户唯一ID的记录
  2. 如果存在，直接取出关联的用户ID，完成登录即可
  3. 如果不存在，再用邮箱查询你的存量用户表：
     • 有匹配的存量用户：给该用户新增一条Google登录关联记录存入AspNetUserLogins表，再完成登录
     • 无匹配的存量用户：创建一个无密码的新用户（PasswordHash字段设为null即可），同时新增对应的Google登录关联记录，再完成登录
• 后续用户用Google登录时，直接通过唯一ID匹配关联记录，不需要再校验邮箱，稳定性更高

你可以通过自定义AddGoogle配置里的OnCreatingTicket事件，插入上面的用户关联逻辑。

关于是否需要使用OpenID Connect的问题 #

你现在的用法已经用到了OpenID Connect（OIDC），不需要额外做适配。Google的登录服务本身就是基于OIDC标准实现的，AddGoogle扩展方法本质上是对通用OIDC认证的专属封装，帮你省略了配置OIDC端点、作用域等通用参数的步骤，你拿到的id_token就是OIDC协议的标准身份凭证，用来证明用户身份的合法性，完全符合你的使用场景。

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