如何使用新GSI Web API获取Google Identity Refresh Token避免用户每小时重登

核心逻辑：新版GSI API仍保留离线授权能力，仅配置项和旧版API存在差异，只要首次授权时成功拿到Refresh Token，后续即可通过自动刷新Access Token实现免重复登录。

前端配置步骤 #

• 若使用JS API初始化授权客户端，调用google.accounts.oauth2.initCodeClient方法时，必须添加access_type: 'offline'参数，这是触发离线授权、返回可交换Refresh Token的授权码的核心配置
• 若使用GSI内置的HTML登录按钮组件，给按钮添加data-access_type="offline"属性即可
• 如需强制重新获取Refresh Token，可额外添加prompt: 'consent'配置，触发用户重新确认授权，避免因用户已完成过授权拿不到新Refresh Token的问题
• 申请的OAuth权限范围需匹配业务实际需求，过度申请权限会提升授权被拒概率

注意：仅用户首次完成授权时接口会返回Refresh Token，后续重复授权且用户未取消过授权的场景下不会再返回新的Refresh Token，首次获取后需妥善存储在服务端，严禁下发到前端暴露。

服务端令牌交换逻辑 #

• 前端拿到GSI返回的授权码（code）后，10分钟内传递到你的后端服务，超过有效期的授权码无法使用
• 后端调用Google OAuth令牌接口，传入授权码、客户端ID、客户端密钥、和前端配置完全一致的重定向URI，同时指定grant_type: 'authorization_code'，即可在返回结果中拿到refresh_token、有效期1小时的access_token以及过期时间戳
• 所有和密钥、Refresh Token相关的操作必须全部在服务端完成，禁止在前端处理

后续免登录刷新逻辑 #

• 当Access Token距离过期不足5分钟时，后端直接调用Google OAuth令牌接口，传入存储的Refresh Token、客户端ID、客户端密钥，指定grant_type: 'refresh_token'即可换取新的Access Token，全程不需要用户参与
• 仅当Refresh Token本身失效（如用户主动取消账号授权、超过6个月未使用、用户修改账号密码等特殊场景）时，才需要引导用户重新完成授权流程

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