Office加载项SSO跨Azure租户来宾登录报13004错误

返回的13004错误属于误导性报错，并非清单中<WebApplicationInfo>节点配置错误，核心原因是Office SSO的令牌请求逻辑与手动用Postman测试的隐式OAuth2流存在本质差异：

• Office客户端发起SSO请求时，会默认跟随用户当前登录Office的活动租户上下文，向对应租户的AAD端点发起令牌请求，不会自动识别资源应用所属的主租户、主动跳转请求端点。
• 测试中登录失败的开发租户用户，登录Office时默认处于自身家租户（@ourcompanydev.onmicrosoft.com）的上下文下，SSO请求会直接发往开发租户的AAD端点；但你仅在主租户完成了加载项的应用注册，开发租户内不存在该应用对应的服务主体，AAD无法识别请求中传入的资源URL，因此抛出「无效资源URL」的错误。
• 该故障与Microsoft 365许可无关联，主租户下无M365许可的用户可成功完成SSO登录，已经可以排除许可因素。

根据使用场景选择对应方案即可：

• 临时测试方案：无需修改租户配置，让开发租户的来宾用户登录Office客户端时手动切换到主租户上下文即可。操作路径：打开任意Office应用，点击右上角账户入口，输入开发租户的来宾账号后，在租户选择页面选择主租户@ourcompany.com的目录登录，不要停留在开发租户的默认目录下，即可正常走完SSO流程。
• 长期通用方案（推荐）：在开发租户中预配加载项应用的服务主体，从根源解决跨租户上下文识别问题，步骤如下：
  1. 进入主租户的AAD应用注册页面，找到Office加载项对应的应用注册，将支持的账户类型修改为「任何组织目录中的账户」，保存配置。
  2. 使用开发租户的全局管理员账号，对该应用完成租户范围的管理员同意，操作完成后开发租户目录下会自动生成该应用对应的服务主体。
  3. 不需要修改加载项清单中的任何配置，配置生效后，开发租户用户无论处于自身家租户上下文还是来宾访问主租户的上下文，Office SSO请求都能正常识别资源URL，不会再抛出13004错误。

补充说明：之前用Postman测试所有用户都能正常认证，是因为测试时手动指定了主租户AAD端点或者公共端点发起请求，绕过了Office SSO自动跟随用户租户上下文发请求的逻辑，才会出现手动测试全通、SSO跨租户失败的现象。

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