为何更新为 Microsoft 标识平台 (v2.0)?Why update to Microsoft identity platform (v2.0)?

开发新应用程序时,必须知道 Microsoft 标识平台 (v2.0) 终结点与 Azure Active Directory (v1.0) 终结点之间的差异。When developing a new application, it's important to know the differences between the Microsoft identity platform (v2.0) and Azure Active Directory (v1.0) endpoints. 本文介绍这些终结点之间的主要差异,以及 Microsoft 标识平台的一些现有限制。This article covers the main differences between the endpoints and some existing limitations for Microsoft identity platform.


Microsoft 标识平台终结点并非支持所有 Azure AD 方案和功能。The Microsoft identity platform endpoint doesn't support all Azure AD scenarios and features. 若要确定是否应使用 Microsoft 标识平台终结点,请阅读 Microsoft 标识平台限制To determine if you should use the Microsoft identity platform endpoint, read about Microsoft identity platform limitations.

谁可以登录Who can sign in

谁可以使用 v1.0 和 v2.0 终结点登录

  • v1.0 终结点仅允许使用工作和学校帐户登录到应用程序 (Azure AD)The v1.0 endpoint allows only work and school accounts to sign in to your application (Azure AD)
  • Microsoft 标识平台终结点使工作帐户和学校帐户可从 Azure AD 登录。The Microsoft identity platform endpoint allows work and school accounts from Azure AD to sign in.

使用 Microsoft 标识平台终结点可以编写接受工作帐户和学校帐户登录的应用。The Microsoft identity platform endpoint allows you to write apps that accept sign-ins from work and school accounts. 这样,你便可以编写完全不区分帐户的应用。This gives you the ability to write your app completely account-agnostic. 例如,如果应用调用 Microsoft Graph,则工作帐户可以使用某些附加功能和数据,如 SharePoint 站点或目录数据。For example, if your app calls the Microsoft Graph, some additional functionality and data will be available to work accounts, such as their SharePoint sites or directory data. 但对于许多操作,相同的代码可以访问工作和学校帐户的电子邮件。But for many actions, the same code can access the email for work and school accounts.

对于 Microsoft 标识平台终结点,可以使用 Microsoft 身份验证库 (MSAL) 来获取对使用者、教育和企业领域的访问权限。For Microsoft identity platform endpoint, you can use the Microsoft Authentication Library (MSAL) to gain access to the consumer, educational, and enterprise worlds. Azure AD v1.0 终结点仅接受工作和学校帐户的登录。The Azure AD v1.0 endpoint accepts sign-ins from work and school accounts only.

使用 Azure AD v1.0 终结点的应用需要提前指定所需的 OAuth 2.0 权限,例如:Apps using the Azure AD v1.0 endpoint are required to specify their required OAuth 2.0 permissions in advance, for example:

显示权限注册 UI 的示例

直接在应用程序注册中设置的权限是静态的The permissions set directly on the application registration are static. 尽管在 Azure 门户中定义应用的静态权限能保持代码的简洁性,但可能会给开发人员带来几个问题:While static permissions of the app defined in the Azure portal keep the code nice and simple, it presents some possible issues for developers:

  • 应用需要在用户首次登录时请求可能需要的权限。The app needs to request all the permissions it would ever need upon the user's first sign-in. 这可能会导致冗长的权限列表,而让最终用户在初始登录时打消审批应用程序访问权限的念头。This can lead to a long list of permissions that discourages end users from approving the app's access on initial sign-in.

  • 应用需要事先知道可能访问的所有资源。The app needs to know all of the resources it would ever access ahead of time. 很难创建能够访问任意数目的资源的应用程序。It was difficult to create apps that could access an arbitrary number of resources.

使用 Microsoft 标识平台终结点,可以忽略在 Azure 门户的应用注册信息中定义的静态权限,而以递增方式请求权限,即,一开始请求最少的一组权限,然后随着时间的推移,当客户使用更多的应用功能时,再请求更多的权限。With the Microsoft identity platform endpoint, you can ignore the static permissions defined in the app registration information in the Azure portal and request permissions incrementally instead, which means asking for a bare minimum set of permissions upfront and growing more over time as the customer uses additional app features. 为此,可以在请求访问令牌时,通过在 scope 参数中包含新的范围指定应用所需的范围 - 无需在应用程序注册信息中预定义这些范围。To do so, you can specify the scopes your app needs at any time by including the new scopes in the scope parameter when requesting an access token - without the need to pre-define them in the application registration information. 如果用户尚未许可添加到请求的新范围,则系统会提示他们仅许可新的权限。If the user hasn't yet consented to new scopes added to the request, they'll be prompted to consent only to the new permissions. 有关详细信息,请参阅权限、许可和范围To learn more, see permissions, consent, and scopes.

允许应用通过 scope 参数动态请求权限可让开发人员完全控制用户的体验。Allowing an app to request permissions dynamically through the scope parameter gives developers full control over your user's experience. 还可以将许可体验提前,并在一个初始授权请求中请求所有的权限。You can also front load your consent experience and ask for all permissions in one initial authorization request. 如果应用需要大量的权限,则你可以在用户尝试使用应用的某些功能过程中,以递增方式向用户收集这些权限。If your app requires a large number of permissions, you can gather those permissions from the user incrementally as they try to use certain features of the app over time.

代表组织执行的管理员许可仍然需要为应用注册的静态权限,因此,如果需要管理员代表整个组织提供许可,则应在应用注册门户中为应用设置这些权限。Admin consent done on behalf of an organization still requires the static permissions registered for the app, so you should set those permissions for apps in the app registration portal if you need an admin to give consent on behalf of the entire organization. 这会减少组织管理员设置应用程序所需的周期数。This reduces the cycles required by the organization admin to set up the application.

范围而非资源Scopes, not resources

对于使用 v1.0 终结点的应用,应用可以充当资源或令牌接收者。For apps using the v1.0 endpoint, an app can behave as a resource, or a recipient of tokens. 资源可定义它所了解的许多范围oAuth2Permissions,使客户端应用能够从该资源中为一组特定的范围请求令牌。A resource can define a number of scopes or oAuth2Permissions that it understands, allowing client apps to request tokens from that resource for a certain set of scopes. 请考虑将 Microsoft Graph API 作为资源的示例:Consider the Microsoft Graph API as an example of a resource:

  • 资源标识符,或 AppID URIhttps://microsoftgraph.chinacloudapi.cn/Resource identifier, or AppID URI: https://microsoftgraph.chinacloudapi.cn/
  • 范围或 oAuth2PermissionsDirectory.ReadDirectory.Write 等等。Scopes, or oAuth2Permissions: Directory.Read, Directory.Write, and so on.

对于 Microsoft 标识平台终结点也是如此。This holds true for the Microsoft identity platform endpoint. 应用仍可充当资源、定义范围并由 URI 标识。An app can still behave as a resource, define scopes, and be identified by a URI. 客户端应用程序仍可请求访问这些范围。Client apps can still request access to those scopes. 但是,客户端用于请求这些权限的方式已发生了变化。However, the way that a client requests those permissions have changed.

对于 v1.0 终结点,Azure AD 的 OAuth 2.0 授权请求可能如下所示:For the v1.0 endpoint, an OAuth 2.0 authorize request to Azure AD might have looked like:

GET https://login.partner.microsoftonline.cn/common/oauth2/authorize?

此处的 resource 参数指示客户端应用请求授权的资源。Here, the resource parameter indicated which resource the client app is requesting authorization. Azure AD 根据 Azure 门户中的静态设置计算应用程序所需的权限,并据以发出令牌。Azure AD computed the permissions required by the app based on static configuration in the Azure portal, and issued tokens accordingly.

对于使用 Microsoft 标识平台终结点的应用程序,相同的 OAuth 2.0 授权请求如下所示:For applications using the Microsoft identity platform endpoint, the same OAuth 2.0 authorize request looks like:

GET https://login.partner.microsoftonline.cn/common/oauth2/v2.0/authorize?

此处的 scope 参数指示应用请求授权的资源和权限。Here, the scope parameter indicates which resource and permissions the app is requesting authorization. 所需的资源仍然在请求中提供 - 它包含在 scope 参数的每个值中。The desired resource is still present in the request - it's encompassed in each of the values of the scope parameter. 以此方式使用 scope 参数可让 Microsoft 标识平台终结点更符合 OAuth 2.0 规范,并且更贴近常见的行业实践。Using the scope parameter in this manner allows the Microsoft identity platform endpoint to be more compliant with the OAuth 2.0 specification, and aligns more closely with common industry practices. 此参数还使应用可执行增量同意 - 仅当应用程序需要权限时才请求,而不是一开始就请求。It also enables apps to do incremental consent - only requesting permissions when the application requires them as opposed to up front.

已知的范围Well-known scopes

脱机访问Offline access

使用 Microsoft 标识平台终结点的应用可能需要针对应用使用新的已知权限 - offline_access 范围。Apps using the Microsoft identity platform endpoint may require the use of a new well-known permission for apps - the offline_access scope. 如果应用程序需要长期表示用户访问资源,则所有应用程序都需要请求此权限,即使用户可能不主动使用此应用程序亦然。All apps will need to request this permission if they need to access resources on the behalf of a user for a prolonged period of time, even when the user may not be actively using the app. 在许可对话框中,offline_access 范围对用户显示为“随时访问数据”,而用户必须同意。 The offline_access scope will appear to the user in consent dialogs as Access your data anytime, which the user must agree to. 请求 offline_access 权限可让 Web 应用从 Microsoft 标识平台终结点接收 OAuth 2.0 refresh_tokens。Requesting the offline_access permission will enable your web app to receive OAuth 2.0 refresh_tokens from the Microsoft identity platform endpoint. 刷新令牌属于长效令牌,可用于交换新的 OAuth 2.0 访问令牌以延长访问期限。Refresh tokens are long-lived, and can be exchanged for new OAuth 2.0 access tokens for extended periods of access.

如果应用未请求 offline_access 范围,则收不到刷新令牌。If your app doesn't request the offline_access scope, it won't receive refresh tokens. 这意味着,在 OAuth 2.0 授权代码流中兑换授权代码时,只从 /token 终结点接收访问令牌。This means that when you redeem an authorization code in the OAuth 2.0 authorization code flow, you'll only receive back an access token from the /token endpoint. 该访问令牌短时间维持有效(通常是一小时),但最后终将过期。That access token remains valid for a short period of time (typically one hour), but will eventually expire. 到时,应用必须将用户重定向回到 /authorize 终结点以检索新的授权代码。At that point in time, your app will need to redirect the user back to the /authorize endpoint to retrieve a new authorization code. 在此重定向期间,根据应用程序的类型,用户或许无需再次输入其凭据或重新同意权限。During this redirect, the user may or may not need to enter their credentials again or reconsent to permissions, depending on the type of app.

若要详细了解 OAuth 2.0、refresh_tokensaccess_tokens,请查看 Microsoft 标识平台协议参考To learn more about OAuth 2.0, refresh_tokens, and access_tokens, check out the Microsoft identity platform protocol reference.

OpenID、profile 和 emailOpenID, profile, and email

以前,使用 Microsoft 标识平台的最基本型 OpenID Connect 登录流会在生成的 id_token 中提供丰富的用户相关信息。Historically, the most basic OpenID Connect sign-in flow with Microsoft identity platform would provide a lot of information about the user in the resulting id_token. id_token 中的声明可以包含用户的名称、首选用户名、电子邮件地址和对象 ID 等。The claims in an id_token can include the user's name, preferred username, email address, object ID, and more.

现在对 openid 范围允许应用访问的信息进行了限制。The information that the openid scope affords your app access to is now restricted. openid 范围只允许应用将用户登录,并接收用户的应用特定标识符。The openid scope will only allow your app to sign in the user and receive an app-specific identifier for the user. 如果想要在应用中获取关于用户的个人数据,则应用需要向用户请求额外的权限。If you want to get personal data about the user in your app, your app needs to request additional permissions from the user. 两个新范围 emailprofile 将允许请求额外的权限。Two new scopes, email and profile, will allow you to request additional permissions.

  • 假设用户具有可寻址的电子邮件地址,则 email 范围允许应用通过 id_token 中的 email 声明访问用户的主要电子邮件地址。The email scope allows your app access to the user's primary email address through the email claim in the id_token, assuming the user has an addressable email address.
  • profile 范围可让应用访问 id_token 中有关用户的所有其他基本信息,例如其姓名、首选用户名、对象 ID 等。The profile scope affords your app access to all other basic information about the user, such as their name, preferred username, object ID, and so on, in the id_token.

使用这些范围可在尽可以能透露最少信息的情况下为应用编写代码,因此,只能向用户请求应用执行其作业所需的信息集。These scopes allow you to code your app in a minimal-disclosure fashion so you can only ask the user for the set of information that your app needs to do its job. 有关这些范围的详细信息,请参阅 Microsoft 标识平台范围参考For more information on these scopes, see the Microsoft identity platform scope reference.

令牌声明Token claims

为了使有效负荷保持在较小的规模,Microsoft 标识平台终结点默认会在其令牌中发布少量的声明。The Microsoft identity platform endpoint issues a smaller set of claims in its tokens by default to keep payloads small. 如果你的应用和服务依赖于 v1.0 令牌中的特定声明,而 Microsoft 标识平台令牌中默认不再提供该声明,请考虑使用可选声明功能来包含该声明。If you have apps and services that have a dependency on a particular claim in a v1.0 token that is no longer provided by default in a Microsoft identity platform token, consider using the optional claims feature to include that claim.


v1.0 和 v2.0 终结点都可以颁发 v1.0 和 v2.0 令牌!v1.0 and v2.0 tokens can be issued by both the v1.0 and v2.0 endpoints! id_tokens 始终 与请求它们的终结点相匹配,而访问令牌始终 与客户端将使用该令牌调用的 Web API 所需的格式相匹配。id_tokens always match the endpoint they're requested from, and access tokens always match the format expected by the Web API your client will call using that token. 因此,如果应用使用 v2.0 终结点来获取一个调用 Microsoft Graph 的令牌(需要 v1.0 格式的访问令牌),那么应用将收到一个 v1.0 格式的令牌。So if your app uses the v2.0 endpoint to get a token to call Microsoft Graph, which expects v1.0 format access tokens, your app will receive a token in the v1.0 format.


使用 Microsoft 标识平台终结点时有一些要注意的限制。There are a few restrictions to be aware of when using Microsoft identity platform.

生成与 Microsoft 标识平台集成的应用程序时,需确定 Microsoft 标识平台终结点和身份验证协议是否满足需求。When you build applications that integrate with the Microsoft identity platform, you need to decide whether the Microsoft identity platform endpoint and authentication protocols meet your needs. v1.0 终结点和平台仍完全受支持,并且在某些方面比 Microsoft 标识平台的功能更丰富。The v1.0 endpoint and platform is still fully supported and, in some respects, is more feature rich than Microsoft identity platform. 但是,Microsoft 标识平台为开发人员带来了极大的好处However, Microsoft identity platform introduces significant benefits for developers.

下面是目前为开发人员提供的简明建议:Here's a simplified recommendation for developers now:

  • 如果你正在编写新的应用程序,请使用 Microsoft 标识平台。If you're writing a new application, use Microsoft identity platform. 但在此之前,请确保了解本文所述的限制。But before you do, make sure you understand the limitations discussed in this article.
  • 若要迁移或更新依赖于 SAML 的应用程序,则不能使用 Microsoft 标识平台。If you're migrating or updating an application that relies on SAML, you can't use Microsoft identity platform. 请改为参阅 Azure AD v1.0 指南Instead, refer to the Azure AD v1.0 guide.

Microsoft 标识平台终结点将演变为消除此处列出的限制,因此你只需要使用 Microsoft 标识平台终结点。The Microsoft identity platform endpoint will evolve to eliminate the restrictions listed here, so that you'll only ever need to use the Microsoft identity platform endpoint. 在此期间,使用本文来确定 Microsoft 标识平台终结点是否适合你。In the meantime, use this article to determine whether the Microsoft identity platform endpoint is right for you. 我们将持续更新本文,以反映 Microsoft 标识平台终结点当前的状态。We'll continue to update this article to reflect the current state of the Microsoft identity platform endpoint. 请不时返回查阅本文,重新评估 Microsoft 标识平台功能是否符合要求。Check back to reevaluate your requirements against Microsoft identity platform capabilities.

应用注册限制Restrictions on app registrations

对于你想要与 Microsoft 标识平台终结点集成的每个应用,可在 Azure 门户的新应用注册体验中创建应用注册。For each app that you want to integrate with the Microsoft identity platform endpoint, you can create an app registration in the new App registrations experience in the Azure portal. 现有的 Microsoft 帐户应用与门户不兼容,但所有 Azure AD 应用都兼容,无论它们是在何处或何时注册的。Existing Microsoft account apps aren't compatible with the portal, but all Azure AD apps are, regardless of where or when they were registered.

支持工作和学校帐户的应用注册的注意事项如下:App registrations that support work and school accounts have the following caveats:

  • 每个应用程序 ID 只允许有两个应用密码。Only two app secrets are allowed per application ID.
  • 未在租户中注册的应用程序只能由注册它的帐户管理。An application that wasn't registered in a tenant can only be managed by the account that registered it. 不能与其他开发人员共享该应用程序。It can't be shared with other developers. 如果要与多名开发人员共享应用注册,请使用 Azure 门户的新“应用注册”部分在租户中注册该应用程序 。If you'd like to share your app registration with multiple developers, register the application in a tenant using the new App registrations section of the Azure portal.
  • 允许的重定向 URL 格式存在一些限制。There are several restrictions on the format of the redirect URL that is allowed. 有关重定向 URL 的详细信息,请参阅下一部分。For more information about redirect URL, see the next section.

重定向 URL 的限制Restrictions on redirect URLs

为 Microsoft 标识平台注册的应用限制为一组有限的重定向 URL 值。Apps that are registered for Microsoft identity platform are restricted to a limited set of redirect URL values. Web 应用和服务的重定向 URL 必须以方案 https 开头,并且所有重定向 URL 值必须共享一个 DNS 域。The redirect URL for web apps and services must begin with the scheme https, and all redirect URL values must share a single DNS domain. 注册系统会将现有重定向 URL 的完整 DNS 名称与要添加的重定向 URL 的 DNS 名称相比较。The registration system compares the whole DNS name of the existing redirect URL to the DNS name of the redirect URL that you're adding. 也支持将 http://localhost 用作重定向 URL。http://localhost is also supported as a redirect URL.

如果满足以下任一条件,添加 DNS 名称的请求会失败:The request to add the DNS name will fail if either of the following conditions is true:

  • 新的重定向 URL 的完整 DNS 名称与现有的重定向 URL 的 DNS 名称不匹配。The whole DNS name of the new redirect URL doesn't match the DNS name of the existing redirect URL.
  • 新重定向 URL 的完整 DNS 名称不是现有重定向 URL 的子域。The whole DNS name of the new redirect URL isn't a subdomain of the existing redirect URL.

示例 1Example 1

如果应用的重定向 URL 为 https://login.contoso.com,则你可以添加 DNS 名称完全匹配的重定向 URL,如以下示例所示:If the app has a redirect URL of https://login.contoso.com, you can add a redirect URL where the DNS name matches exactly, as shown in the following example:


或者,可以引用 login.contoso.com 的 DNS 子域,如以下示例所示:Or, you can refer to a DNS subdomain of login.contoso.com, as shown in the following example:


示例 2Example 2

若要在应用中包含 login-east.contoso.comlogin-west.contoso.com 作为重定向 URL,必须按以下顺序添加这些重定向 URL:If you want to have an app that has login-east.contoso.com and login-west.contoso.com as redirect URLs, you must add those redirect URLs in the following order:


可以添加后两个重定向 URL,因为它们是第一个重定向 URL (contoso.com) 的子域。You can add the latter two because they're subdomains of the first redirect URL, contoso.com.

一个特定应用程序只能有 20 个回复 URL - 此限制适用于注册支持的所有应用类型(单页应用程序 (SPA)、本机客户端、Web 应用和服务)。You can have only 20 reply URLs for a particular application - this limit applies across all app types that the registration supports (single-page application (SPA), native client, web app, and service).

若要了解如何注册应用以配合 Microsoft 标识平台使用,请参阅使用新的应用注册体验来注册应用To learn how to register an app for use with Microsoft identity platform, see Register an app using the new App registrations experience.

库和 SDK 限制Restrictions on libraries and SDKs

目前,Microsoft 标识平台终结点的库支持有限。Currently, library support for the Microsoft identity platform endpoint is limited. 如果想要在生产应用程序中使用 Microsoft 标识平台终结点,可使用以下选项:If you want to use the Microsoft identity platform endpoint in a production application, you have these options:

  • 如果要生成 Web 应用程序,可以放心使用正式版服务器端中间件来执行登录和令牌验证操作。If you're building a web application, you can safely use the generally available server-side middleware to do sign-in and token validation. 其中包括适用于 ASP.NET 的 OWIN OpenID Connect 中间件和 Node.js Passport 插件。These include the OWIN OpenID Connect middleware for ASP.NET and the Node.js Passport plug-in. 有关使用 Microsoft 中间件的代码示例,请参阅 Microsoft 标识平台入门部分。For code samples that use Microsoft middleware, see the Microsoft identity platform getting started section.
  • 如果要生成桌面或移动应用程序,可以使用 Microsoft 身份验证库 (MSAL) 之一。If you're building a desktop or mobile application, you can use one of the Microsoft Authentication Libraries (MSAL). 这些库是正式发布版或支持在生产环境中使用的预览版,因此可在生产应用程序中放心使用。These libraries are generally available or in a production-supported preview, so it is safe to use them in production applications. 有关预览版和可用库的术语的详细信息,请阅读身份验证库参考中的内容。You can read more about the terms of the preview and the available libraries in authentication libraries reference.
  • 对于 Microsoft 库不支持的平台,可以通过直接在应用程序代码中发送和接收协议消息来与 Microsoft 标识平台终结点进行集成。For platforms not covered by Microsoft libraries, you can integrate with the Microsoft identity platform endpoint by directly sending and receiving protocol messages in your application code. OpenID Connect 和 OAuth 协议有明确的说明文档,有助于执行此类集成。The OpenID Connect and OAuth protocols are explicitly documented to help you do such an integration.
  • 最后,可以使用开源 OpenID Connect 和 OAuth 库来与 Microsoft 标识平台终结点集成。Finally, you can use open-source OpenID Connect and OAuth libraries to integrate with the Microsoft identity platform endpoint. Microsoft 标识平台终结点应与许多开源协议库兼容,不需要进行更改。The Microsoft identity platform endpoint should be compatible with many open-source protocol libraries without changes. 此类库的可用性根据语言和平台而有所不同。The availability of these kinds of libraries varies by language and platform. OpenID ConnectOAuth 2.0 网站将维护一份热门实现列表。The OpenID Connect and OAuth 2.0 websites maintain a list of popular implementations. 有关详细信息,请参阅 Microsoft 标识平台和身份验证库,其中提供了已在 Microsoft 标识平台终结点中进行测试的开源客户端库和示例列表。For more information, see Microsoft identity platform and authentication libraries, and the list of open-source client libraries and samples that have been tested with the Microsoft identity platform endpoint.
  • (供参考)Microsoft 标识平台的通用 .well-known 终结点是 https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configurationFor reference, the .well-known endpoint for the Microsoft identity platform common endpoint is https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration. common 替换为你的租户 ID,以获取特定于你的租户的数据。Replace common with your tenant ID to get data specific to your tenant.

协议更改Protocol changes

Microsoft 标识平台终结点不支持 SAML 或 WS 联合身份验证;它仅支持 OpenID Connect 和 OAuth 2.0。The Microsoft identity platform endpoint does not support SAML or WS-Federation; it only supports OpenID Connect and OAuth 2.0. 相比 v1.0 终结点,OAuth 2.0 协议的重大变化包括:The notable changes to the OAuth 2.0 protocols from the v1.0 endpoint are:

  • 如果配置了可选声明,或者在请求中指定了 scope=email,则返回 email 声明。The email claim is returned if an optional claim is configured or scope=email was specified in the request.
  • 现在支持使用 scope 参数来取代 resource 参数。The scope parameter is now supported in place of the resource parameter.
  • 许多响应已经过修改,因此更符合 OAuth 2.0 规范,例如,可正确返回整数而不是字符串形式的 expires_inMany responses have been modified to make them more compliant with the OAuth 2.0 specification, for example, correctly returning expires_in as an int instead of a string.

若要进一步了解 Microsoft 标识平台终结点支持的协议功能范围,请参阅 OpenID Connect 和 OAuth 2.0 协议参考To better understand the scope of protocol functionality supported in the Microsoft identity platform endpoint, see OpenID Connect and OAuth 2.0 protocol reference.

SAML 限制SAML restrictions

如果已在 Windows 应用程序中使用了 Active Directory 身份验证库 (ADAL),则可能已利用了 Windows 集成身份验证,该身份验证使用安全断言标记语言 (SAML) 断言授予。If you've used Active Directory Authentication Library (ADAL) in Windows applications, you might have taken advantage of Windows Integrated authentication, which uses the Security Assertion Markup Language (SAML) assertion grant. 借助这种授权,联合 Azure AD 租户的用户可使用其本地 Active Directory 实例以静默方式进行身份验证,而无需输入凭据。With this grant, users of federated Azure AD tenants can silently authenticate with their on-premises Active Directory instance without entering credentials. Microsoft 标识平台终结点不支持 SAML 断言授予。The SAML assertion grant isn't supported on the Microsoft identity platform endpoint.