嵌套应用身份验证和 Outlook 旧版令牌弃用常见问题解答

项目
12/18/2024

Exchange 用户标识令牌和回调令牌已弃用，将从 2025 年 2 月开始关闭。建议将使用旧版 Exchange 令牌的 Outlook 加载项移动到嵌套应用身份验证。

常规常见问题解答

什么是 NAA) (嵌套应用身份验证？

嵌套应用身份验证为嵌套在受支持的 Microsoft 应用程序（如 Outlook）中的应用程序启用单一登录 (SSO) 。与现有的完全信任身份验证模型和代理流相比，NAA 在应用体系结构中提供了更好的安全性和更大的灵活性，从而支持创建丰富的客户端驱动应用程序。有关详细信息，请参阅使用嵌套应用身份验证在 Office 外接程序中启用 SSO。

关闭旧版 Exchange 联机令牌时间线是什么？

Microsoft从 2025 年 2 月开始关闭旧版 Exchange 联机令牌。从现在到 2025 年 2 月，现有租户和新租户将不受影响。如果租户和外接程序尚未迁移到 NAA，我们将为管理员提供可重新启用 Exchange 令牌的工具。有关详细信息，请参阅是否可以重新打开旧版令牌？。

日期	旧令牌状态
2025 年 2 月	所有租户的旧令牌已关闭。管理员可以通过 PowerShell 重新启用旧令牌。
2025 年 6 月	所有租户的旧令牌已关闭。管理员无法再通过 PowerShell 重新启用旧令牌，必须联系 Microsoft 了解任何异常。
2025 年 10 月	所有租户的旧令牌已关闭。不再允许出现异常。

NAA 何时对我的频道正式发布？

NAA 的正式发布 (正式发布) 日期取决于你正在使用的频道。

日期	NAA 正式发布 (GA)
2024 年 10 月	NAA 在当前频道中正式发布。
2024 年 11 月	NAA 在每月企业频道中正式发布。
2025 年 1 月	NAA 将在 Semi-Annual 频道正式发布。
2025 年 6 月	NAA 将在 Semi-Annual 扩展频道中正式发布。

COM 加载项是否受到弃用旧Exchange Online令牌的影响？

弃用旧Exchange Online令牌不太可能影响任何 COM 加载项。 Outlook Web 加载项主要受到影响，因为它们可以使用依赖于 Exchange 令牌 Office.js API。有关详细信息，请参阅如何知道我的 Outlook 添加是否依赖于旧令牌。 Exchange 令牌用于访问 Exchange Web Services (EWS) 或 Outlook REST API，这两者也已弃用。如果怀疑 COM 加载项可能受到影响，可以在关闭 Exchange 令牌的租户上使用它来测试它。有关详细信息，请参阅打开或关闭旧Exchange Online令牌。

Microsoft 365 个管理员问题

是否可以重新打开Exchange Online旧版令牌？

是的，可以使用 PowerShell 命令在任何租户中打开或关闭旧令牌。有关如何打开或关闭旧版令牌的详细信息，请参阅打开或关闭旧Exchange Online令牌。如果使用命令启用旧版Exchange Online令牌，则它们不会在 2025 年 2 月关闭。它们将一直持续到 2025 年 6 月，或者直到使用工具将其关闭为止。

在 2025 年 6 月，旧版令牌将被关闭，如果没有Microsoft授予的特定例外，你将无法重新打开它们。在 2025 年 10 月，无法打开旧版令牌，并且将对所有租户禁用旧令牌。工具可用后，我们将用其他信息更新此常见问题解答。

独立软件供应商 (ISV) 正在更新其外接程序，以使用 Entra ID 令牌和Microsoft Graph 范围。当加载项请求访问令牌时，它必须获得管理员或用户同意。如果管理员同意，租户上的所有用户都可以将加载项用于外接程序所需的范围。否则，如果启用了用户同意，则会提示每个最终用户同意。完成管理员同意会提供更好的体验，因为不会提示用户。

一种许可选项是 ISV 提供管理员同意 URI。

外接程序开发人员提供管理员同意 URI。如果这不在他们提供的文档中，则需要与他们联系以获取详细信息。
管理员浏览到管理员同意 URI。
系统会提示管理员登录并同意加载项所需的范围列表。
完成后，浏览器将从 ISV 重定向到网页，这应显示同意已成功。

作为替代方法，ISV 可以提供更新的应用清单，该清单将提示管理员同意作为中央部署的一部分。在此方案中，部署更新的应用清单时，系统会提示你同意，然后才能完成部署。无需管理员同意 URI。

最后，如果加载项在 Microsoft 365 存储中发布，则会自动部署更新，并且系统会提示管理员同意范围。如果管理员不同意，用户将无法使用更新的加载项。

确保不禁用功能或撤销加载项所需的权限。有关示例，请参阅修改邮箱策略属性。加载项使用委托的权限，因此有权访问与登录用户相同的资源。但是，如果策略或设置阻止用户访问特定资源或操作，则也会阻止加载项。

如何实现从 ISV 部署加载项更新？

如果你有使用旧版 Exchange 令牌的外接程序，则应联系 ISV，了解有关其迁移加载项以使用 NAA 时间线的信息。 ISV 迁移其加载项后，他们很可能提供管理员同意 URL。有关详细信息，请参阅管理员同意流如何工作？。

ISV 还可以为你提供更新的应用清单，以便通过集中部署进行部署。在集中部署期间，这可能会提示你同意加载项要求的任何Microsoft Graph 范围。在此方案中，无需使用管理员同意 URI。

如果加载项是从 Microsoft AppSource 部署的，则当 ISV 向外接程序推出更新时，很可能系统会提示你同意Microsoft Graph 范围。除非你同意，否则租户上的用户将无法将新版本的外接程序与 NAA 一起使用。

我的组织中的哪些加载项受到影响？

我们发布了自 2024 年 10 月起发布到使用旧令牌的 Microsoft 存储的所有 Outlook 加载项的列表。有关如何使用列表和生成可能使用旧令牌的 Outlook 外接程序报表的详细信息，请参阅查找使用旧Exchange Online令牌的 Outlook 外接程序。此外，我们正在开发报表工具，以便更轻松地使用旧令牌跟踪加载项。我们希望在 2025 年初推出报告工具。

加载项可以使用旧令牌通过 EWS 或 Outlook REST API 从 Exchange 获取资源。有时，加载项需要 Exchange 资源用于某些用例，而不是其他用例，因此很难确定加载项是否需要更新。我们建议联系加载项开发人员和所有者，询问他们的外接程序代码是否引用了以下 API。

makeEwsRequestAsync
getUserIdentityTokenAsync
getCallbackTokenAsync

如果你的加载项依赖于 ISV，我们建议你尽快与他们联系，以确认他们有转移旧 Exchange 令牌的计划和时间线。 ISV 开发人员应直接与其Microsoft联系人联系，询问问题，以确保他们已准备好结束 Exchange 旧版令牌。如果你依赖于组织中的开发人员，他们应查看此常见问题解答和文章使用嵌套应用身份验证在 Office 外接程序中启用 SSO。应在 OfficeDev/office-js GitHub 问题网站上提出任何问题。

管理员或用户同意后，它将在Microsoft Entra 管理中心中列出。可以使用以下步骤查找应用注册。

转到 https://entra.microsoft.com/#home。
在左侧导航窗格中，选择“应用程序>应用注册”。
在“应用注册”页上，选择“所有应用程序”。
现在，可以按名称或 ID 搜索任何应用注册。

是否有更新了加载项的发布者列表？

一些广泛使用的 Outlook 外接程序发布者已更新其加载项，如下所示。

如果发布者更新了其清单，并且加载项是通过Microsoft存储部署的，系统会提示你以管理员身份升级和部署更新。如果发布者更新了其清单，并且加载项是通过集中部署部署的，则需要以管理员身份部署新清单。在某些情况下，发布者可能有管理员同意 URI，你需要使用来同意加载项的新范围。如果需要有关更新加载项的详细信息，请联系发布者。

Outlook 加载项迁移常见问题解答

为什么Microsoft使 Outlook 加载项迁移？

使用 Entra ID 令牌切换到 Microsoft Graph 是 Outlook 和 Exchange 客户安全性的一大改进。 Entra ID (以前为 Azure Active Directory) 是基于云的领先标识和访问管理服务。客户可以利用零信任功能，例如条件访问、MFA 要求、持续令牌监视、实时安全启发法，以及旧版 Exchange 令牌无法提供的更多功能。客户将重要的业务数据存储在 Exchange 中，因此我们必须确保此数据受到保护。迁移整个 Outlook 生态系统以将 Entra ID 令牌与 Microsoft Graph 结合使用可极大地提高客户数据的安全性。

我的 Outlook 加载项是否必须迁移到 NAA？

不正确。尽管 NAA 为用户提供了最佳的身份验证体验和组织的最佳安全状况，但 Outlook 加载项不必使用 NAA。如果加载项未使用旧版 Exchange 令牌，则它们不会受到弃用 Exchange 令牌的影响。使用 MSAL.js 或其他依赖于 Entra ID 的 SSO 方法的加载项将继续工作。

如何实现知道我的 Outlook 外接程序是否依赖于旧版令牌？

若要了解外接程序是否使用旧版 Exchange 用户标识令牌和回调令牌，请在代码中搜索对以下 API 的调用。

makeEwsRequestAsync
getUserIdentityTokenAsync
getCallbackTokenAsync

如果外接程序调用这些 API 中的任何一个，则应采用 NAA 并迁移到使用 Entra ID 令牌来访问 Microsoft Graph。

哪些 Outlook 加载项在范围内？

许多主要加载项都在范围内。如果外接程序使用 EWS 或 Outlook REST 访问Exchange Online资源，则几乎可以肯定需要从旧版 Outlook 令牌迁移到 NAA。如果你的外接程序只用于 Exchange 本地 (例如 Exchange 2019) ，则不受此更改的影响。

如果我不迁移到 NAA，我的 Outlook 加载项会发生什么情况？

如果不将 Outlook 加载项迁移到 NAA，它们将在 Exchange Online 中停止按预期工作。关闭 Exchange 令牌后，Exchange Online将阻止旧令牌颁发。任何使用旧令牌的外接程序都无法访问 Exchange 联机资源。

如果外接程序仅在本地工作，或者外接程序位于弃用路径上，则可能不需要更新。但是，通过 EWS 或 Outlook REST 访问 Exchange 资源的大多数加载项必须迁移才能继续按预期运行。

如何实现将 Outlook 加载项迁移到 NAA？

若要在 Outlook 加载项中支持 NAA，请参阅以下文档和示例。

如何实现跟上最新指南？

我们将更新此常见问题解答，因为有新信息可用。我们将在 Office 加载项社区通话和 M365 开发人员博客上分享更多指导。最后，可以在 OfficeDev/office-js GitHub 问题网站上提出有关 NAA 和旧版Exchange Online令牌弃用的问题。请在标题中放入“NAA”，以便我们可以对问题进行分组和确定优先级。

如果提交问题，请提供以下信息。

Outlook 客户端版本。
适用于客户端) 的 Outlook 发布频道受众 (。
问题的屏幕截图。
(Windows、Outlook (新) 、Mac、iOS、Android) 出现问题的平台。
遇到问题的会话 ID。
正在使用的帐户类型。
msal-browser 的版本。
msal-browser 中的日志。

开发人员问题

如何实现从 MSAL 和 NAA 获取更多调试信息？

初始化可嵌套的公共客户端应用程序时，使用以下代码在 msalConfig 中启用调试信息。这会将其他详细信息记录到控制台。

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

如何实现验证 ID 令牌或对用户进行身份验证？

使用 Exchange 令牌，可以验证 ID 令牌，并使用它来授权用户访问你自己的资源。有关详细信息，请参阅使用 Exchange 的标识令牌对用户进行身份验证。但是，具有 Entra ID 令牌的 MSAL 不使用此方法。

通过 MSAL 请求令牌时，它始终返回三个令牌。

令牌	用途	Scopes
ID 令牌	向客户端 (任务窗格) 提供有关用户的信息。	`profile` 和 `openid`
刷新令牌	在 ID 和访问令牌过期时刷新这些令牌。	`offline_access`
访问令牌	对资源的特定范围（如 Microsoft Graph）的用户进行身份验证。	任何资源范围，例如 `user.read`。

MSAL 始终返回这三个令牌。它请求 profile、 openid和 offline_access 作为默认范围，即使令牌请求不包括它们。这可确保请求 ID 和刷新令牌。但是，必须至少包含一个资源范围，例如 user.read ，以便获取访问令牌。否则，请求可能会失败。

通过网络调用传递 ID 令牌以启用或授权访问服务是一种安全反模式。令牌仅适用于客户端 (任务窗格) ，服务无法可靠地使用该令牌来确保用户具有授权的访问权限。有关 ID 令牌声明的详细信息，请参阅 https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference。

请务必始终向自己的服务请求访问令牌。访问令牌还包括相同的 ID 声明，因此无需传递 ID 令牌。请改为为服务创建自定义范围。有关你自己的服务的应用注册设置的详细信息，请参阅受保护的 Web API：应用注册。当服务收到访问令牌时，它可以对其进行验证，并使用访问令牌内部的 ID 声明。

通过