Google Action隐式授权流程及access_token变更问题咨询

我来帮你梳理清楚Actions on Google中隐式授权的完整流程，以及access_token变更的处理方案——毕竟我之前帮不少开发者搞定过这类账户链接的问题。

隐式授权是OAuth 2.0的简化模式，针对你的场景，完整流程是这样的：

• 触发登录请求：当你的Action需要访问用户需登录的网站资源时，返回actions.intent.SIGN_IN意图。Google Assistant会识别这个意图，引导用户完成账户链接（比如在Google Home上提示用户查看手机）。
• 跳转至你的授权页面：用户同意授权后，Assistant会打开你在Action控制台配置的授权URL，并且自动带上response_type=token、client_id、redirect_uri这些必要参数（隐式模式下必须指定response_type=token）。
• 网站生成并返回Token：你的网站验证用户身份（比如用户输入账号密码登录）后，生成access_token，还可以附加expires_in（有效期）、token_type等参数，然后通过URL哈希（#）的形式跳转到Google指定的回调URL（格式一般是https://oauth-redirect.googleusercontent.com/r/[你的项目ID]）。举个例子，跳转的URL可能长这样：https://oauth-redirect.googleusercontent.com/r/your-project-id#access_token=abc123&expires_in=3600&token_type=Bearer。
• Assistant接收并存储Token：Google Assistant会自动提取URL哈希中的access_token，把它存储在用户的关联账户信息里。之后你的Action就能通过conv.user.access.token（Dialogflow中）拿到这个Token，用来调用你的网站API。
• 后续会话复用Token：只要Token没失效，用户后续使用你的Action时，Assistant会自动带上这个Token，不需要用户重复登录。

这里要注意：隐式模式没有刷新Token（refresh_token），所以Token过期后必须让用户重新走一遍授权流程。另外，Token是通过客户端侧的URL哈希传递的，不会经过服务器，所以要把Token的有效期设得短一些（比如1小时），降低安全风险。

不管是Token过期，还是你网站主动作废旧Token（比如用户修改了密码），处理逻辑大同小异：

• 检测Token失效：你的Action在调用网站API时，要捕获401 Unauthorized这类表示Token失效的响应。或者你也可以在调用API前，先调用网站的Token验证接口，提前确认Token有效性。
• 重新触发登录流程：一旦发现Token失效，立即返回actions.intent.SIGN_IN意图，引导用户重新授权。用户完成授权后，Google Assistant会自动更新存储的access_token，后续会话就会使用新的Token。
• 主动作废Token后的同步：如果你的网站因为用户操作（比如改密码、注销设备）主动作废了旧Token，只要在API调用时返回401状态码，让Action触发重新登录即可。不需要额外通知Google Assistant，因为它只会在需要用Token的时候才会去获取最新的。

额外实践建议 #

• 如果你需要长期授权，不想让用户频繁登录，建议考虑切换到Authorization Code模式。虽然配置更复杂，但它支持refresh_token，你的Action可以用refresh_token自动获取新的access_token，不需要用户手动操作。
• 在网站端生成Token时，最好给每个Token绑定用户ID和设备信息，这样即使Token泄露，也能快速定位并作废。
• 在Action中添加容错逻辑：如果获取Token失败或者Token无效，给用户清晰的提示（比如“你的登录状态已过期，请重新登录”），不要让用户摸不着头脑。

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