跨Azure AD租户登录遇AADSTS54005错误，同租户正常，求排查原因

这个问题我之前帮团队排查过类似的，结合你的场景（内部用户正常、外部用户触发授权码已兑换错误），大概率是授权码重复使用或者OAuth2流程里的state校验缺失导致的，具体可以从这几个方向逐一排查：

1. 先补上State参数校验（多租户场景必加） #

Azure AD的OAuth2流程里，state参数是用来防止重放攻击、确保请求一致性的关键。虽然Passport的AzureAD策略默认可能带这个，但很多自定义场景下会被忽略，尤其是多租户环境下，外部用户的请求链路更长，更容易出现重复请求的情况。

你需要在初始化AzureAdOAuth2Strategy时显式开启state校验：

passport.use( new AzureAdOAuth2Strategy( { 
    clientID: process.env.AZURE_CLIENT_ID, 
    clientSecret: process.env.AZURE_CLIENT_SECRET, 
    callbackURL: `${getBaseUrl()}/api/login/callback`, 
    tenant: 'common', 
    useCommonEndpoint: true,
    state: true // 加上这行，启用自动state生成与校验
  }, async (accessToken, refresh_token, params, profile, done) => {
    // 你的业务逻辑
  })
);

这一步能直接避免大部分因为请求重放、会话不一致导致的授权码重复兑换问题。

2. 检查授权码的调用逻辑是否重复 #

AADSTS54005的核心原因就是同一个授权码被调用了两次token接口。你需要排查：

• 回调路由/api/login/callback是否被多次触发？比如前端有没有重复跳转，或者后端中间件有没有重复处理请求？
• getBaseUrl()生成的回调地址是否正确？外部用户访问时，这个函数会不会生成内网地址，导致Azure把授权码发送到错误的端点提前兑换了？可以打印一下callbackURL的实际值，确认和Azure AD应用里配置的回复URL完全一致。

3. 确认Azure AD应用的回复URL配置 #

虽然你开了多租户，但要确保：

• 外部用户访问用的公网域名已经加到Azure AD应用的**回复URL(redirect URI)**列表里，而且是完全匹配的（包括HTTP/HTTPS、路径、端口，不能有多余的斜杠）。
• 不要用通配符（比如https://*.yourdomain.com），Azure AD对多租户应用的回复URL限制更严格，必须是精确地址。

4. 排查会话存储的一致性问题 #

如果你的应用是多实例部署的，外部用户的请求可能会打到不同的实例上。如果会话存在内存里（比如express-session默认的内存存储），不同实例的会话数据不共享，会导致state校验失败，进而触发重复请求授权码的情况。

建议换成分布式会话存储（比如Redis），确保所有实例能共享会话状态，这在多租户、多实例场景下是刚需。

5. 手动测试OAuth2流程定位问题 #

如果上面的步骤都没解决，可以手动走一遍流程确认问题：

1. 构造授权URL：

   https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=你的客户端ID&response_type=code&redirect_uri=你的回调URL&scope=openid
   

2. 用外部用户登录，拿到地址栏里的code参数
3. 用Postman调用token接口：

   POST https://login.microsoftonline.com/common/oauth2/v2.0/token
   

   参数：
   • grant_type: authorization_code
   • client_id: 你的客户端ID
   • client_secret: 你的客户端密钥
   • code: 刚才拿到的授权码
   • redirect_uri: 你的回调URL
4. 如果第一次调用成功，第二次用同一个code调用就会返回AADSTS54005（正常现象）。如果你的应用里出现这个错误，说明代码里有两次调用token接口的逻辑，需要排查业务代码里的重复触发。

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