OAuth登录后反复授权、第三方登录刷新令牌失败如何分诊？先区分SaaS会话与平台API，再按Google、Microsoft和GitHub应用身份、实际令牌与错误来源核查。
登录成功后，授权框却再次弹出。对线上SaaS集成团队而言，用户已经完成登录，后续访问又中断，最容易误判为“刷新令牌过期”。但弹窗只是现象：失败的是本产品的会话请求，还是调用第三方平台API的请求？两条路径的证据不能混放。
先给框架：OAuth登录后反复授权、第三方登录刷新令牌失败须先确认登录发生在此前，再标注失败请求对象、应用身份、实际令牌及错误来源；没有刷新令牌就不预设可刷新。平台官方条件仅解释其覆盖的分支，自有会话另查。
登录之后再出问题，别倒查首次回调
设想值班人员看到“请重新授权”，记录里确有先前成功登录；此时值得保留的是成功与失败的先后关系，而不是先把回调配置重新做一遍。若授权阶段就未成功、生产回调地址不匹配，那是另一道题。当前页面只讨论成功登录之后的中断；Webhook事件投递与业务落库也不纳入登录状态判断。
如何确认故障其实发生在首次授权？沿着这个问题，应转向下面的生产回调排障入口，而不是将本页的令牌分诊套在尚未登录成功的请求上。
排查动作：只登记“此前登录成功／后续哪个动作失败”的时间顺序与界面提示类别；用户标识采用内部脱敏标记。切勿把原始响应、浏览器存储内容或凭据贴进工单。这个次序并非根因证明，却能阻止两个不同阶段的故障混线。
OAuth登录后反复授权、第三方登录刷新令牌失败：先找失败对象
反共识的关键不在于更快续期，而在于先问：谁拒绝了谁？若失败请求发往SaaS自己的服务，应把自有会话状态列为待核假设；若失败发生在平台API调用，应核其应用身份、使用的令牌类别及平台返回的错误类别。HTTP 401只能作为定位线索，不能单凭状态码指定是哪种令牌出错，更不能据此要求所有用户重新授权。
授权框是结果，不是令牌类型的诊断报告。
区分“登录所用身份”和“后续调用身份”同样重要。面向用户的访问与面向安装身份的访问，可能分别对应不同核对入口；还须核对系统实际有没有拿到刷新令牌。没有证据证明它存在时，“尝试刷新”不是分诊动作。若多处请求共同异常，也要先分别标注错误来源，再讨论自有会话或刷新竞态等假设，不将猜测写成定因。
动作清单：①标记出错请求是自有服务还是平台API，避免把两种错误合并；②记录配置登记的应用类型及令牌类别名称，避免跨身份套规则；③按当前平台官方适用条件比对，无法对应则保留待核。若需要跳出局部认证问题，转向哪一层架构背景？
OAuth登录后反复授权、第三方登录刷新令牌失败：无敏感值分诊图
先让日志说清“哪里失败”，别让日志暴露“拿什么访问”。可交接请求目标类别、所用平台及应用身份、配置中的重定向URI登记类型、是否实际颁发刷新令牌、错误所属环节与成功登录前后关系；令牌存在性只填“已确认有／未确认／确认无”，不填写其内容。下图是条件分类，不是平台通用刷新流程。
请求对象 | 应用身份 | 实际令牌 | 错误源 | 判断依据 | 安全分流 自有服务 | 登录会话 | 未确认刷新令牌 | 自有接口 | 平台时限不适用 | 核自有会话假设 Google API | 客户端类型待核 | 有或未确认 | 平台端 | 外部+测试+范围例外仅条件适用 | 核官方条件 Microsoft API | spa URI待核 | 有或未确认 | 平台端 | 仅spa URI令牌有已证时限 | 核登记类型 GitHub API | App用户/OAuth App/安装待核 | 有或未确认 | 平台端 | 仅App用户轮换有已证规则 | 分身份核官方 来源不明 | 身份未明 | 未确认 | 前端提示 | 无法据提示指认错误方 | 先定位请求
每行的“判断依据”要与同一行的身份相配；图中“待核”不是平台已确认能力。动作清单：①先在已有无敏感值记录中区分请求去向与错误源，无法区分就标记未知；②再按应用登记资料核对身份、是否存在刷新令牌；③最后打开下文给出的官方页面比条件。任何一步需要展示原始响应或真实凭据时，停止在字段类别层面交接。
中途FAQ：先拆两个误读
没有刷新令牌，能否刷新访问令牌？ 先问系统保留的是“未见颁发证据”还是“明确确认未颁发”：两种记录不能合并成令牌丢失。前一种应核发放条件与既有脱敏记录；后一种不能沿用预设的刷新路径，也不要通过共享凭据补证。
同一界面有HTTP 401，就能判定第三方登录刷新令牌失败吗？ 另一个判断角度是界面是否汇总了多个请求结果。例如某个自有接口返回失败，而平台API并未被调用；应先标注发出该状态的请求目标，不能让页面提示替代来源证据。
Google invalid_grant：先核项目条件和令牌是否存在
Google路径先区分Web服务端、浏览器与服务账号等身份类别，但本页不推定这些类别共享任何刷新行为。动作清单：①在项目登记资料里确认实际客户端类别及授权范围类别；②在无敏感值记录里核实是否实际颁发刷新令牌；③只有对应上官方条件，再分析该条件是否可能解释中断。若只有登录成功而无颁发记录，就不要谈如何刷新。
Google官方《使用 OAuth 2.0 访问 Google API》https://developers.google.com/identity/protocols/oauth2?hl=zh-cn 给出的限定是：项目OAuth权限请求页面配置为外部用户类型、发布状态为“测试”时，系统发放有效期为7天的刷新令牌；但请求的唯一OAuth范围仅为名称、电子邮件地址和用户个人资料的子集时除外。要逐项确认这些前提，不能把7天写成全部Google登录或SaaS自有会话的到期日。
若记录的错误类别是Google invalid_grant，也只把它作为前往Google官方条件核对的线索。排障时区分错误发生在登录流程、平台API续期相关环节，还是自有服务的另一请求；对不上上述限定时，保留“当前官方规则待核”，不要凭错误字样反推用户一定要重新授权。
Microsoft SPA refresh token：看重定向URI的登记类型
这里的关键变量不是“用了Microsoft登录”这么宽泛，而是刷新令牌是否发送到注册为spa的重定向URI。Microsoft官方《Microsoft 标识平台中的刷新令牌》https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens 写明：发送到已注册为spa的重定向URI的刷新令牌将在24小时后过期；使用初始刷新令牌获取的其他刷新令牌承袭该过期时间。这是特定URI及令牌条件，非SPA类型、SaaS自有会话不沿用这一时限。
动作清单：①核对应用登记中的URI类型与实际请求采用的身份类别，不展示URI中可能含有的敏感参数；②从脱敏记录确认初始刷新令牌是否曾颁发，仅记有无与类别；③若条件确实匹配，检查团队是否错误地把后续刷新视为到期时间重新起算。若条件不匹配，回到错误来源分流，不要拿SPA规则解释一切重新授权。
GitHub OAuth App刷新令牌：把三种身份分开
“GitHub令牌要刷新”指的是哪种身份？先把GitHub OAuth App、GitHub App用户令牌、安装身份分别列为核对分支；实际属于哪一种，要看登记的应用身份和调用对象，而不是连接器的提示文案。某产品连接器的局部“不刷新”经验，不足以证明整个平台都不提供相关机制；反过来，摘要中提到OAuth App可选到期令牌，本安全包缺少可复核官方正文，不能把它写成当前默认开关。
已确认的窄规则来自GitHub官方《刷新用户访问令牌》https://docs.github.com/zh/apps/creating-github-apps/authenticating-with-a-github-app/refreshing-user-access-tokens ：对GitHub App用户令牌，一旦使用刷新令牌，该刷新令牌和旧用户访问令牌就不再有效。这个轮换条件不解释OAuth App具体发放配置，也不说明安装身份如何续发；更不能照搬Microsoft的旧令牌时限继承来推断GitHub行为。
动作清单：①先以应用登记类别分流；②只登记所用令牌的类别与是否实际颁发刷新令牌，别交换其值；③若确为GitHub App用户令牌，对照官方轮换条件核查是否将旧令牌误当可用；④若为OAuth App或安装身份，把适用条件和续发规则列作当前官方待核项，不提供绕过授权或凭据重放方案。对连接器局部结论与官方身份条件的范围差异，要写在交接记录里。
安全恢复取决于证据，不取决于弹窗次数
若来源指向自有会话，交由负责自有会话的团队核验状态与页面表现；若指向平台API，则按相应应用身份、实际令牌与当期官方规则继续定位。刷新竞态只能列作待验证假设，不能从“重复弹窗”直接确认。恢复动作应由有权限的团队在自身规范内评估：不能为消除提示收集令牌、转发原始响应，或承诺此后无需授权。
当问题跨越认证与发布观察，需要什么背景？全局监控与灰度背景另有入口，本页不把它当令牌机制说明。
FAQ：恢复前再问两件事
什么情况下应退回首次授权排障？ 新视角是先查有无可确认的成功登录边界：如果从未走到成功登录，后续令牌续期表缺少前提；应转到首次授权与回调问题，而不是用后续访问中断解释最初失败。
安装身份出错，能套GitHub App用户令牌的轮换规则吗？ 即使错误提示也写“令牌”，仍须看发起调用的是用户身份还是安装身份；本包只证实前者的特定轮换条件。安装身份续发条件应向当期官方文档核对，交接单标注“待核”，不要借用户令牌规则补出步骤。
若仍无法区分平台API和自有会话，先完成脱敏证据交接再评估支持。针对OAuth登录后反复授权、第三方登录刷新令牌失败，交接给Win Gaming（WG）或本团队时，可以围绕SaaS第三方登录故障排查整理：①请求对象与错误所属环节；②平台及登记应用身份；③实际令牌类别与有无刷新令牌的确认状态；④已匹配的官方条件或待核分支。仅提交字段类别、判断结果与脱敏时间顺序，不提交真实令牌、密钥或原始响应；WG的业务背景不能视为提供OAuth修复产品或保证恢复。