如何安全使用Google Sign-In及返回数据的后续处理方案

你当前已经完成了前端的Google Sign-In集成，接下来的实现逻辑和安全要求如下：

核心结论 #

你提出的通过sub字段作为用户唯一标识的方案是完全可行的：sub是谷歌为每个谷歌账号在你的应用下分配的永久唯一值，不会随用户账号信息修改发生变化，可以作为你系统用户表和谷歌账号的绑定主键。

具体实现步骤（必须严格遵循安全要求） #

• 前端不要将自行解析的JWT内容发送到后端，直接把谷歌返回的完整credential字段（即原始JWT字符串）提交给你的服务端接口。
• 服务端收到JWT后，必须完成以下校验，所有校验不通过的请求直接拒绝：
  • 使用谷歌官方公钥校验JWT的签名合法性，避免内容被篡改，建议直接使用对应开发语言的Google Identity Services服务端SDK或者成熟的JWT校验库完成，不要自行实现签名校验逻辑。
  • 校验iss字段值必须为https://accounts.google.com，确认凭证为谷歌官方签发。
  • 校验aud字段值必须和你申请的Google client_id完全一致，避免其他应用的合法凭证被恶意用于你的系统。
  • 校验exp字段值，确认凭证未过期。
  • 校验email_verified字段值为true，确认当前使用的谷歌邮箱已经过谷歌官方验证。
• 校验全部通过后，从JWT的payload中取出sub字段，查询你的用户表中是否存在绑定了该sub的用户：
  • 存在匹配用户：直接为该用户生成你系统的登录态（如session、自定义服务端JWT、登录态cookie等），返回给前端即可完成登录流程。
  • 不存在匹配用户：可直接创建新用户，将sub、邮箱、用户名、头像等从JWT中获取的字段存入用户表，再生成登录态返回；如果你的业务需要额外的用户信息，也可以先返回补全信息的指引，待用户提交额外信息后再完成账号创建和登录操作。

注意事项 #

• 禁止仅通过前端解析JWT的结果判定用户登录成功，前端的解析逻辑仅可用于展示用户名、头像等非敏感场景，所有权限判定必须依赖服务端的校验结果。
• 不要使用邮箱作为谷歌账号和你系统用户的绑定主键，谷歌账号的邮箱允许用户自行修改，只有sub是永久唯一的绑定标识。
• 该认证逻辑无需为用户设置密码，谷歌的身份校验已经替代了密码校验的环节，你系统只需要维护用户和sub的绑定关系即可，也可以根据业务需要后续支持用户绑定其他登录方式。

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