Google Profile API停用后，登录方式的OpenID兼容性与用户迁移问询

1. 能否将Google+ OpenID请求替换为标准Google请求？ #

完全可以，而且这是Google官方明确推荐的做法——毕竟Google+相关的OpenID端点早就进入弃用流程了。具体操作要注意这几点：

• 把原来指向Google+的OpenID请求地址，替换为Google标准的OpenID Connect端点。你可以先通过https://accounts.google.com/.well-known/openid-configuration获取完整的配置信息，或者直接使用授权端点https://accounts.google.com/o/oauth2/v2/auth。
• 确保你的应用在Google Cloud控制台里已经启用了Google Sign-in相关的配置（比如OAuth 2.0客户端ID），回调地址要和原来保持一致，避免用户跳转时出现错误。
• 同步更新请求的scope，比如用openid email profile这些标准OpenID Connect的scope，替代原来Google+专属的scope。

2. Google Sign-in与Google Profile登录的用户标识一致性及迁移问题 #

这部分要拆成细节说清楚，避免踩坑：

• 两种登录的用户标识并不完全一致：
  • 旧的Google Profile OpenID（基于OpenID 2.0）返回的是类似https://www.google.com/accounts/o8/id?id=xxxxxx的标识符，或者通过Profile API获取的明文数字用户ID。
  • 现在的Google Sign-in（基于OpenID Connect）返回的sub字段，是一个基于用户ID和你的应用客户端ID生成的唯一哈希值，不会暴露明文的用户ID。
• 能否对应同一账户？要看你之前的存储方式：
  • 如果你的旧应用是把Google Profile API返回的id（明文数字ID）作为用户的唯一标识，那在新的Sign-in流程中请求profile scope后，依然可以拿到这个id字段（虽然官方更推荐用sub），这样就能直接匹配到旧账户。
  • 如果你之前存的是OpenID 2.0的URL格式标识符，那需要做映射：Google提供了工具可以把旧的OpenID 2.0标识符转换为对应的sub值，或者你也可以通过用户的邮箱来匹配（前提是你的数据库里存了用户邮箱且邮箱唯一）。
• 不能只移除旧登录方式，必须做用户迁移：
  • 要是直接删掉Google Profile登录，没做标识映射的话，老用户用新方式登录时会被创建新账户，导致他们的原有数据无法访问。
  • 正确的迁移步骤：
    • 先同时支持旧的Google Profile登录和新的Google Sign-in，给用户一个过渡周期。
    • 当老用户用旧方式登录时，把他们的旧标识（或邮箱、用户ID）和新Sign-in返回的sub做关联，存入你的用户数据库。
    • 等大部分用户完成关联后，再移除旧的登录方式。
    • 对于长期没登录的用户，可以通过邮箱主动匹配，或者提供客服渠道让用户申请合并账户。

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