iOS Swift应用上架App Store后无法登录同步Outlook日历问题

以下是开发环境正常、正式发布后登录失效的必查配置项，按出现概率从高到低排序：

• 补全Azure AD端的重定向URI配置
  开发环境登录正常通常是因为你仅配置了调试签名对应的回调规则，正式版使用App Store分发证书签名后，MSAL（微软身份认证库）校验的回调地址会和调试版有差异。进入Azure AD应用注册的「身份验证」页，在重定向URI列表中新增正式版条目：格式为msauth.[你的应用正式Bundle ID]://auth，同时确认「支持的账户类型」选项和调试时配置完全一致，不要出现调试时选了多租户+个人微软账户、正式配置误选为单租户的情况。
• 检查发布构建变体的Info.plist与权限配置
  很多开发者会把MSAL相关配置仅加在Debug构建配置下，Release构建（即App Store上架用的构建版本）会缺失必要项：
  • 确认Release配置下的Info.plist中LSApplicationQueriesSchemes数组包含msauthv2、msauthv3两个值
  • 确认URL Types中完整配置了正式Bundle ID对应的MSAL回调scheme
  • 确认Apple开发者后台对应正式App ID开启了Keychain Sharing能力，且Release构建的Entitlements文件中配置的钥匙串访问组，和MSAL初始化代码中传入的访问组参数完全匹配——调试阶段Xcode自动生成的本地签名权限不会同步到发布构建，钥匙串访问失败会直接导致MSAL无法存取认证令牌，表现为登录流程卡住或回调失败。
• 修正中介认证与发布构建的安全配置
  如果你的应用接入了Microsoft Authenticator中介认证、或通过SFAuthenticationSession/ASWebAuthenticationSession拉起系统浏览器登录，需要在Azure AD重定向URI列表中补全正式版对应的中介回调地址；同时移除Release构建中开启的MSAL调试选项，比如允许不受信任证书、跳过 broker 校验这类调试用开关，这类配置在正式构建中会触发MSAL的安全拦截，直接阻断登录流程。
• 确认Outlook日历权限的生效状态
  登录后同步日历失败常被误判为登录失败，需要进入Azure AD「API权限」页，确认你申请的Calendars.Read、Calendars.ReadWrite等委派权限已经完成管理员同意（多租户应用需要在发布前完成所有目标租户的权限授予，仅测试账号单独同意权限无法覆盖所有正式用户）。

快速定位技巧：将正式构建的ipa包用调试证书重签名后安装到测试机，触发登录流程抓取MSAL返回的具体错误码即可快速定位问题：MSALErrorRedirectSchemeNotRegistered对应重定向配置错误，MSALErrorKeychainAccessFailure对应钥匙串权限问题，AADSTS65001对应API权限未授予同意。

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