Refresh Token接口异常(AADSTS90033):故障恢复后仍无法获取令牌
排查Refresh Token获取失败(AADSTS90033 503错误)的思路
先看你提供的错误返回详情:
{ "response": { "statusCode": 503, "body": { "error": "temporarily_unavailable", "error_description": "AADSTS90033: A transient error has occurred. Please try again.\nTrace ID: 988f6bab-9fde-44c7-b480-a2dd07fd4900\nCorrelation ID: 031c9c04-389f-4b45-9b45-a1f4ee1b5d75\nTimestamp: 2020-09-28 22:41:10Z", "error_codes": [90033], "timestamp": "2020-09-28 22:41:10Z", "trace_id": "988f6bab-9fde-44c7-b480-a2dd07fd4900", "correlation_id": "031c9c04-389f-4b45-9b45-a1f4ee1b5d75" }, "headers": { "cache-control": "no-store, no-cache", "pragma": "no-cache", "content-type": "application/json; charset=utf-8", "expires": "-1", "strict-transport-security": "max-age=31536000; includeSubDomains", "x-content-type-options": "nosniff", "p3p": "CP=\"DSP CUR OTPi IND OTRi ONL FIN\"", "x-ms-request-id": "988f6bab-9fde-44c7-b480-a2dd07fd4900", "x-ms-ests-server": "2.1.11063.14 - WEULR2 ProdSlices", "set-cookie": ["fpc=...; expires=Wed, 28-Oct-2020 22:41:10 GMT; path=/; secure; HttpOnly; SameSite=None", "x-ms-gateway-slice=estsfd; path=/; secure; httponly", "stsservicecookie=estsfd; path=/; secure; httponly"], "date": "Mon, 28 Sep 2020 22:41:10 GMT", "connection": "close", "content-length": "424" }, "request": { "uri": { "protocol": "https:", "slashes": true, "auth": null, "host": "login.microsoftonline.com", "port": 443, "hostname": "login.microsoftonline.com", "hash": null, "search": null, "query": null, "pathname": "/common/oauth2/v2.0/token", "path": "/common/oauth2/v2.0/token", "href": "https://login.microsoftonline.com/common/oauth2/v2.0/token" }, "method": "POST", "headers": { "Content-Type": "application/x-www-form-urlencoded", "accept": "application/json", "content-length": 1607 } } } }
结合你提到的「Access Token获取正常,仅Refresh Token失效」的情况,我整理了几个可能的原因和对应的排查步骤:
可能的原因
- 服务切片恢复不一致:从响应头的
x-ms-ests-server可以看到,你的请求路由到了WEULR2 ProdSlices的某个服务实例。Azure AD的不同功能(比如获取Access Token vs 刷新Refresh Token)可能由不同的服务切片处理,服务中断后,处理Refresh Token的切片可能还未完全恢复,而Access Token相关的切片已经正常工作。 - Refresh Token相关缓存/存储异常:服务中断可能导致后端存储Refresh Token状态的缓存或数据库出现数据不同步、脏数据的情况,当系统尝试验证旧的Refresh Token时,无法正常读取数据,从而抛出临时错误。
- Refresh Token端点触发速率限制:服务恢复后,可能有大量重试请求集中打到Refresh Token的端点,触发了Azure AD的临时速率限制。毕竟Access Token和Refresh Token的请求场景不同,速率限制阈值可能不一样,或者Refresh Token的请求量突然飙升。
- Refresh Token本身失效但返回错误提示:虽然错误提示是临时不可用,但也有可能你的Refresh Token已经过期、被用户吊销或者因账户密码变更失效——只是服务异常时返回了错误的提示码。正常情况下,这种情况应该返回AADSTS70008之类的错误,但服务不稳定时可能出现混淆。
排查和解决步骤
- 按提示重试请求:这是
transient error的标准处理方式,建议用指数退避的方式重试(比如间隔1s、2s、4s),大概率能绕过临时异常的服务实例。 - 验证Refresh Token的有效性:先确认你的Refresh Token是否在有效期内(Azure AD默认90天),有没有被用户撤销或者因账户变更失效。可以直接走授权流程重新获取一个新的Refresh Token,再测试刷新功能,如果新的能正常使用,那旧的大概率是真的失效了。
- 用Trace ID查询详细日志:登录Azure门户,进入Azure Active Directory > 诊断和解决问题,输入你拿到的Trace ID(
988f6bab-9fde-44c7-b480-a2dd07fd4900)和Correlation ID,能看到更详细的服务端错误细节,确认是不是后端的问题。 - 切换端点尝试:如果你用的是多租户的
/common端点,可以换成具体租户ID的端点(比如/your-tenant-id/oauth2/v2.0/token),可能会路由到正常的服务切片。 - 联系Azure支持:如果重试和排查后问题还存在,把Trace ID、Correlation ID和请求详情发给Azure支持,让他们帮你排查服务端的具体异常情况。
内容的提问来源于stack exchange,提问作者mnkypete




