MS Teams Bot SSO Dialog点击“继续”无响应问题排查求助

问题背景 #

参考Teams Toolkit的sso-bot示例开发，使用示例代码时功能正常。自行实现后：

• 授予管理员同意时，命令可正常执行；
• 撤销管理员同意后，Bot会请求额外权限，但点击“继续”按钮无任何反应；
• 调试发现SSODialog已执行beginDialog和sendOAuthCardAsync，Activity发送正常，但Waterfall Dialog停留在ssoStep步骤，无法进入后续环节；
• Web端Teams开发者工具显示调用Bot的请求失败。

核心代码片段 #

export class SSODialog extends ComponentDialog {
  private requiredScopes: string[] = ["User.Read"];
  private dedupStorage: Storage;
  private dedupStorageKeys: string[];
  private SSOCommandMap: Map<string, any>;

  // Developer controlls the lifecycle of credential provider, as well as the cache in it.
  // In this sample the provider is shared in all conversations
  constructor(dedupStorage: Storage) {
    super(DIALOG_NAME);

    const initialLoginEndpoint = `https://${config.botDomain}/auth-start.html`;

    // moved this part here to be able to have the command ready upon membersAdded
    this.SSOCommandMap = new Map(
      SSOCommands.map((command) => [command.commandMessage, command.operationWithSSOToken])
    );
    
    const dialog = new TeamsBotSsoPrompt(
      oboAuthConfig,
      initialLoginEndpoint,
      TEAMS_SSO_PROMPT_ID,
      {
        scopes: this.requiredScopes,
        endOnInvalidMessage: true,
      }
    );
    this.addDialog(dialog);
    this.addDialog(
      new WaterfallDialog(MAIN_WATERFALL_DIALOG, [
        this.ssoStep.bind(this),
        this.dedupStep.bind(this),
        this.executeOperationWithSSO.bind(this),
      ])
    );

    this.initialDialogId = MAIN_WATERFALL_DIALOG;
    this.dedupStorage = dedupStorage;
    this.dedupStorageKeys = [];
    
     async ssoStep(stepContext: any) {
        const turnContext = stepContext.context as TurnContext;
        stepContext.options.commandMessage = 
        this.getActivityText(turnContext.activity);
        return await stepContext.beginDialog(TEAMS_SSO_PROMPT_ID); // 流程卡在此处
     }
  }

排查调试方向 #

• 检查OAuth回调配置的正确性
  确认oboAuthConfig中的客户端ID、租户ID、客户端密钥是否与Azure AD应用注册一致，尤其是权限撤销后，回调URL是否仍能正确接收Teams的授权响应。确保auth-start.html路径可公开访问，且CORS配置允许Teams域名请求。
• 验证去重存储（dedupStorage）的逻辑
  检查dedupStorage的初始化和读写是否正常，权限请求的去重key是否正确生成并存储。如果去重逻辑异常，可能导致TeamsBotSsoPrompt无法正确识别授权回调的请求，进而阻塞Waterflow流程。
• 排查TeamsBotSsoPrompt的配置细节
  确认scopes参数是否准确，撤销管理员同意后，是否需要重新申请的权限范围与requiredScopes匹配。检查endOnInvalidMessage设为true后，是否有非法消息拦截了正常的授权回调，可临时改为false测试是否能继续流程。
• 查看Bot服务的错误日志
  重点关注授权回调阶段的请求日志，检查是否有4xx/5xx错误。比如：
  • 是否存在签名验证失败（Teams请求的签名未通过Bot Framework的验证）；
  • 是否有令牌交换（OBO流程）失败的报错，比如权限不足、令牌过期；
• 检查对话状态管理
  确认Bot的ConversationState和UserState是否正确初始化并绑定到Adapter，Waterfall Dialog的状态是否能被正确持久化。如果状态丢失，会导致流程无法从ssoStep推进到后续步骤。
• 模拟授权回调请求
  使用Postman等工具直接调用Bot的授权回调端点，传入模拟的Teams授权响应参数，验证Bot是否能正确处理并返回预期结果，排除Teams客户端到Bot的网络问题。

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