您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

为什么要更新到 Microsoft 标识平台(v2.0)?Why update to Microsoft identity platform (v2.0)?

开发新应用程序时,了解 Microsoft 标识平台(v2.0)与 Azure Active Directory (1.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 和个人 Microsoft 帐户(MSA)(如 hotmail.com、outlook.com 和 msn.com)的工作和学校帐户登录。The Microsoft identity platform endpoint allows work and school accounts from Azure AD and personal Microsoft accounts (MSA), such as hotmail.com, outlook.com, and msn.com, to sign in.
  • 对于配置为 单租户 的应用程序或配置为指向特定于租户的终结点(https://login.microsoftonline.com/{TenantId_or_Name})的多租户应用程序,这两个终结点还接受 Azure AD 目录的 来宾用户 的登录。Both endpoints also accept sign-ins of guest users of an Azure AD directory for applications configured as single-tenant or for multi-tenant applications configured to point to the tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}).

Microsoft 标识平台终结点允许你编写应用,这些应用接受来自 Microsoft 个人帐户和工作和学校帐户的登录。The Microsoft identity platform endpoint allows you to write apps that accept sign-ins from personal Microsoft accounts, and 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, such as Reading a user's mail, the same code can access the email for both personal and 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://graph.microsoft.com/Resource identifier, or AppID URI: https://graph.microsoft.com/
  • 范围或 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.microsoftonline.com/common/oauth2/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&resource=https://graph.windows.net/
...

此处的 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.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&scope=https://graph.windows.net/directory.read%20https://graph.windows.net/directory.write
...

此处的 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. 如果你的应用程序和服务依赖于不在 Microsoft 标识平台令牌中默认提供的1.0 版令牌中的特定声明,请考虑使用可选的声明功能来包含该声明。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 格式的访问令牌,则你的应用程序将收到采用1.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 recieve a token in the v1.0 format.

限制Limitations

使用 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. 1.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 帐户,或者你正在编写新应用程序,请使用 Microsoft 标识平台。If you want or need to support personal Microsoft accounts in your application, or 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 and personal 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. 在应用注册门户中使用 Microsoft 个人帐户注册的大多数应用都是如此。This is the case for most apps that were registered using a personal Microsoft account in the App Registration Portal. 如果要与多个开发人员共享应用注册,请使用 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:

https://login.contoso.com/new

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

https://new.login.contoso.com

示例 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:

https://contoso.com
https://login-east.contoso.com
https://login-west.contoso.com

可以添加后两个,因为它们是第一个重定向 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.microsoftonline.com/common/v2.0/.well-known/openid-configurationFor reference, the .well-known endpoint for the Microsoft identity platform common endpoint is https://login.microsoftonline.com/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),则可能已利用了使用安全断言标记语言(SAML)断言授予的 Windows 集成身份验证。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.