撤销Google OAuth访问/刷新令牌致不同权限令牌连带失效咨询

这是Google OAuth 2.0的长期既定机制，不是近期版本调整导致的异常：

• 同一个Google Cloud项目下的同一OAuth 2.0客户端，为同一用户颁发的所有access token、refresh token都绑定在**同一份用户授权许可（grant）**上，不会按对接的API服务、申请的权限scope拆分独立的许可实体。
• 调用https://oauth2.googleapis.com/revoke接口时，你撤销的不是某一个服务对应的单条令牌，而是直接作废该用户对当前OAuth客户端的整个授权关系，这份许可下关联的所有scope、所有有效令牌都会同步失效——不管你传入的token最初是申请Calendar还是Drive权限时获取的。

补充说明：Google的令牌本身不做服务维度的隔离标记，同客户端同用户的所有令牌共享完整的授权生命周期，平台原生不支持单独撤销某一个服务对应权限令牌的能力。

根据你的业务场景选对应方案即可：

方案1：拆分独立OAuth客户端（符合官方设计逻辑） #

• 为Google Calendar、Google Drive分别创建独立的OAuth 2.0客户端ID，两套服务走完全独立的授权申请、令牌存储、令牌撤销流程。
• 这种模式下两个服务的授权许可完全隔离，撤销其中一个服务的令牌完全不会影响另一个服务的授权状态，适合两个服务的授权流程独立、支持用户单独开通/关闭某一服务授权的场景。

方案2：本地逻辑层做服务权限管控 #

• 如果你不想拆分客户端，可以放弃调用Google原生的revoke接口，在自有业务侧维护用户的服务授权状态：比如标记用户Drive权限已关闭时，业务层不再发起Drive相关的API调用即可，底层存储的refresh token不做作废处理。
• 注意：该模式下用户在Google账号的第三方应用授权管理页中，仍会看到你的应用同时申请了Calendar和Drive的所有权限，无法感知你业务层做的服务维度权限关闭，更适合内部业务系统、不需要同步Google侧授权展示状态的场景。

方案3：增量授权覆盖原有许可范围 #

• 如果你需要保持单客户端架构，同时要在Google侧同步权限状态，可以在需要撤销某一服务权限时，重新触发OAuth授权流程，在授权请求的scope参数中仅保留需要留存的服务权限（比如撤销Drive权限时，scope只传Calendar对应的权限值），引导用户重新确认授权，覆盖之前的授权许可范围。
• 该方案会弹出新的授权确认页，用户体验有一定折损，仅适合授权操作频次极低的场景。

• 不要尝试给revoke接口传scope参数实现单服务撤销，该接口不识别scope参数，传入后不会产生任何权限范围过滤效果。
• 撤销操作触发后，对应授权下的所有剩余access token会在1分钟内全部失效，refresh token会立即失效，不存在可利用的延迟窗口。

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