如何以及为何将应用程序添加到 Azure ADHow and why applications are added to Azure AD

Azure AD 中的应用程序有两种表示形式:There are two representations of applications in Azure AD:

  • 应用程序对象 - 尽管存在一些例外情况,但可将这些应用程序对象视为应用程序的定义。Application objects - Although there are exceptions, application objects can be considered the definition of an application.
  • 服务主体 - 可将其视为应用程序的实例。Service principals - Can be considered an instance of an application. 服务主体通常引用应用程序对象,一个应用程序对象可由不同目录中的多个服务主体引用。Service principals generally reference an application object, and one application object can be referenced by multiple service principals across directories.

什么是应用程序对象,它们来自何处?What are application objects and where do they come from?

用户可以在 Azure 门户中通过应用程序注册体验来管理应用程序对象You can manage application objects in the Azure portal through the App Registrations experience. 应用程序对象描述 Azure AD 中的应用程序,可将其视为应用程序的定义,使服务能够知道如何根据应用程序的设置,向该应用程序颁发令牌。Application objects describe the application to Azure AD and can be considered the definition of the application, allowing the service to know how to issue tokens to the application based on its settings. 应用程序对象只在其主目录中存在,即使它是支持其他目录中服务主体的多租户应用程序也是如此。The application object will only exist in its home directory, even if it's a multi-tenant application supporting service principals in other directories. 应用程序对象可以包括以下任何项(以及此处未提到的其他信息):The application object may include any of the following (as well as additional information not mentioned here):

  • 名称、徽标和发布者Name, logo, and publisher
  • 重定向 URIRedirect URIs
  • 机密(用于对应用程序进行身份验证的对称和/或非对称密钥)Secrets (symmetric and/or asymmetric keys used to authenticate the application)
  • API 依赖关系 (OAuth)API dependencies (OAuth)
  • 发布的 API/资源/范围 (OAuth)Published APIs/resources/scopes (OAuth)
  • 应用程序角色 (RBAC)App roles (RBAC)
  • 用户设置元数据和配置User provisioning metadata and configuration
  • 代理元数据和配置Proxy metadata and configuration

可通过多种途径创建应用程序对象,包括:Application objects can be created through multiple pathways, including:

  • Azure 门户中的应用程序注册Application registrations in the Azure portal
  • 使用 Visual Studio 创建新应用程序,并将其配置为使用 Azure AD 身份验证Creating a new application using Visual Studio and configuring it to use Azure AD authentication
  • 当管理员从应用库添加应用程序时(这也会创建服务主体)When an admin adds an application from the app gallery (which will also create a service principal)
  • 使用 Microsoft Graph API 或 PowerShell 创建新应用程序Using the Microsoft Graph API or PowerShell to create a new application
  • 其他许多途径,包括 Azure 中的各种开发人员体验,以及开发人员中心的 API 资源管理器体验Many others including various developer experiences in Azure and in API explorer experiences across developer centers

什么是服务主体,它们来自何处?What are service principals and where do they come from?

用户可以在 Azure 门户中通过企业应用程序体验来管理服务主体You can manage service principals in the Azure portal through the Enterprise Applications experience. 服务主体是控制与 Azure AD 相连接的应用程序的对象,可视为目录中应用程序的实例。Service principals are what govern an application connecting to Azure AD and can be considered the instance of the application in your directory. 任意给定应用程序最多只能有一个应用程序对象(在“home”目录中注册),此外,可以有一个或多个服务主体对象,这些对象表示运行该应用程序的每个目录中的应用程序实例。For any given application, it can have at most one application object (which is registered in a "home" directory) and one or more service principal objects representing instances of the application in every directory in which it acts.

服务主体可以包括:The service principal can include:

  • 通过应用程序 ID 属性对应用程序对象的反向引用A reference back to an application object through the application ID property
  • 本地用户和组应用程序角色分配的记录Records of local user and group application-role assignments
  • 授予应用程序的本地用户和管理员权限的记录Records of local user and admin permissions granted to the application
    • 例如:应用程序访问特定用户电子邮件的权限For example: permission for the application to access a particular user's email
  • 本地策略(包括条件访问策略)的记录Records of local policies including Conditional Access policy
  • 应用程序的备用本地设置的记录Records of alternate local settings for an application
    • 声明转换规则Claims transformation rules
    • 属性映射(用户设置)Attribute mappings (User provisioning)
    • 目录特定的应用角色(如果应用程序支持自定义角色)Directory-specific app roles (if the application supports custom roles)
    • 目录特定的名称或徽标Directory-specific name or logo

与应用程序对象一样,可通过多种途径创建服务主体,包括:Like application objects, service principals can also be created through multiple pathways including:

  • 当用户登录到与 Azure AD 集成的第三方应用程序时When users sign in to a third-party application integrated with Azure AD
    • 在登录期间,系统要求用户向应用程序授予访问其配置文件的权限和其他权限。During sign-in, users are asked to give permission to the application to access their profile and other permissions. 第一个授权者导致生成一个服务主体,表示要添加到目录中的应用程序。The first person to give consent causes a service principal that represents the application to be added to the directory.
  • 当用户登录到 Microsoft 365 等 Microsoft 联机服务时When users sign in to Microsoft online services like Microsoft 365
    • 当你订阅 Microsoft 365 或开始试用时,会在目录中创建一个或多个服务主体,表示用于传递所有与 Microsoft 365 关联的功能的各种服务。When you subscribe to Microsoft 365 or begin a trial, one or more service principals are created in the directory representing the various services that are used to deliver all of the functionality associated with Microsoft 365.
    • 某些 Microsoft 365 服务(如 SharePoint)会不断地创建服务主体,这样就可以在组件(包括工作流)之间安全地通信。Some Microsoft 365 services like SharePoint create service principals on an ongoing basis to allow secure communication between components including workflows.
  • 当管理员从应用库添加应用程序时(这也会创建基础应用对象)When an admin adds an application from the app gallery (this will also create an underlying app object)
  • 通过 Microsoft Graph API 或 PowerShell 以编程方式实现Programmatically via the Microsoft Graph API or PowerShell

备注和例外情况Notes and exceptions

  • 并非所有服务主体都会往后指向应用程序对象。Not all service principals point back to an application object. 最初生成 Azure AD 时,提供给应用程序的服务存在更多的限制,使用服务主体便足以建立应用程序标识。When Azure AD was originally built the services provided to applications were more limited and the service principal was sufficient for establishing an application identity. 原始服务主体在形式上更接近于 Windows Server Active Directory 服务帐户。The original service principal was closer in shape to the Windows Server Active Directory service account. 出于此原因,仍可以通过不同的途径创建服务主体(例如使用 Azure AD PowerShell),而无需首先创建应用程序对象。For this reason, it's still possible to create service principals through different pathways, such as using Azure AD PowerShell, without first creating an application object. Microsoft Graph API 在创建服务主体之前需要一个应用程序对象。The Microsoft Graph API requires an application object before creating a service principal.
  • 上述信息当前并非全部都是以编程方式公开的。Not all of the information described above is currently exposed programmatically. 只能在 UI 中使用以下功能:The following are only available in the UI:
    • 声明转换规则Claims transformation rules
    • 属性映射(用户设置)Attribute mappings (User provisioning)
  • 有关服务主体和应用程序对象的详细信息,请参阅 Microsoft Graph API 参考文档:For more detailed information on the service principal and application objects, see the Microsoft Graph API reference documentation:

应用程序为何要与 Azure AD 集成?Why do applications integrate with Azure AD?

应用程序将添加到 Azure AD,以利用 Azure AD 提供的一个或多个服务,包括:Applications are added to Azure AD to leverage one or more of the services it provides including:

  • 应用程序身份验证和授权Application authentication and authorization
  • 用户身份验证和授权User authentication and authorization
  • 用户预配和同步User provisioning and synchronization
  • 基于角色的访问控制 - 使用目录定义应用程序角色,以便在应用程序中执行基于角色的授权检查Role-based access control - Use the directory to define application roles to perform role-based authorization checks in an application
  • OAuth 授权服务 - 供 Microsoft 365 和其他 Microsoft 应用程序用来授予对 API/资源的访问权限OAuth authorization services - Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources
  • 应用程序发布和代理 - 将应用程序从专用网络发布到 InternetApplication publishing and proxy - Publish an application from a private network to the internet
  • 目录架构扩展属性 - 扩展服务主体和用户对象的架构以在 Azure AD 中存储其他数据Directory schema extension attributes - Extend the schema of service principal and user objects to store additional data in Azure AD

谁有权向我的 Azure AD 实例添加应用程序?Who has permission to add applications to my Azure AD instance?

尽管有些任务只能由全局管理员执行,但默认情况下,目录中的所有用户都有权注册正在开发的应用程序对象,并通过许可来决定要共享哪些应用程序/授予对其组织数据的访问权限。While there are some tasks that only global administrators can do by default all users in your directory have rights to register application objects that they are developing and discretion over which applications they share/give access to their organizational data through consent. 当目录中的第一个用户登录到应用程序并授予许可时,会在租户中创建一个服务主体;否则,许可授予信息将存储在现有的服务主体中。If a person is the first user in your directory to sign in to an application and grant consent, that will create a service principal in your tenant; otherwise, the consent grant information will be stored on the existing service principal.

允许用户注册和许可应用程序最初听上去可能令人担忧,但请记住以下要点:Allowing users to register and consent to applications might initially sound concerning, but keep the following in mind:

  • 多年以来,应用程序一直可以利用 Windows Server Active Directory 进行用户身份验证,而无需在目录中注册或记录应用程序。Applications have been able to leverage Windows Server Active Directory for user authentication for many years without requiring the application to be registered or recorded in the directory. 现在,组织提高了可见性,完全知道有多少应用程序正在使用目录以及为何使用目录。Now the organization will have improved visibility to exactly how many applications are using the directory and for what purpose.
  • 将这些责任委托给用户消除了管理员驱动的应用程序发布和注册过程。Delegating these responsibilities to users negates the need for an admin-driven application registration and publishing process. 过去,在使用 Active Directory 联合身份验证服务 (ADFS) 时,管理员可能必须代表开发人员添加一个应用程序作为信赖方。With Active Directory Federation Services (ADFS) it was likely that an admin had to add an application as a relying party on behalf of their developers. 现在,开发人员可以自行解决问题。Now developers can self-service.
  • 用户为了业务目的使用其组织帐户登录到应用程序是一个好现象。Users signing in to applications using their organization accounts for business purposes is a good thing. 如果他们以后离开了组织,便会自动失去他们所用应用程序中帐户的访问权限。If they subsequently leave the organization they will automatically lose access to their account in the application they were using.
  • 记录与哪个应用程序共享了哪些数据是一个很好的做法。Having a record of what data was shared with which application is a good thing. 数据的可流动性比以往更好,因此,明确记录哪个用户与哪些应用程序共享了哪些数据会很有用。Data is more transportable than ever and it's useful to have a clear record of who shared what data with which applications.
  • 为 OAuth 使用 Azure AD 的 API 所有者将明确决定用户可向应用程序授予哪些权限,以及哪些权限需要管理员的许可。API owners who use Azure AD for OAuth decide exactly what permissions users are able to grant to applications and which permissions require an admin to agree to. 只有管理员才能许可较大范围的且更重要的权限,而用户许可范围限制为用户自己的数据和功能。Only admins can consent to larger scopes and more significant permissions, while user consent is scoped to the users' own data and capabilities.
  • 当用户添加应用程序或允许应用程序访问其数据时,可以审核事件,使你能够在 Azure 门户中查看“审核报告”,以确定应用程序是如何添加到目录中的。When a user adds or allows an application to access their data, the event can be audited so you can view the Audit Reports within the Azure portal to determine how an application was added to the directory.

如果仍然想要阻止目录中的用户在未经管理员批准的情况下注册和登录应用程序,可以更改两项设置来关闭这些功能:If you still want to prevent users in your directory from registering applications and from signing in to applications without administrator approval, there are two settings that you can change to turn off those capabilities:

  • 阻止用户自行许可应用程序:To prevent users from consenting to applications on their own behalf:

    1. 在 Azure 门户中,转到企业应用程序下的“用户设置”部分。In the Azure portal, go to the User settings section under Enterprise applications.

    2. 用户可以自行许可访问公司数据的应用 设置为 Change Users can consent to apps accessing company data on their behalf to No.


      如果决定关闭用户许可,则必须由管理员许可用户需要使用的任何新应用程序。If you decide to turn off user consent, an admin will be required to consent to any new application a user needs to use.

  • 阻止用户注册其自己的应用程序:To prevent users from registering their own applications:

    1. 在 Azure 门户中,转到“Azure Active Directory”下的用户设置部分In the Azure portal, go to the User settings section under Azure Active Directory
    2. 用户可以注册应用程序 更改为 Change Users can register applications to No.


Microsoft 自身使用默认配置,允许用户自行注册应用程序和许可应用程序。Microsoft itself uses the default configuration with users able to register applications and consent to applications on their own behalf.