Azure Active Directory 中的应用、权限和同意

在 Azure Active Directory 内,可以向目录添加应用程序。 可以添加的应用程序因应用程序的类型而异。 如果要在经典管理门户中查看应用程序,请选择一个目录,并选择应用程序。

应用类型

  1. 单租户应用

    • 单租户应用 - 通常称为业务线 (LOB) 应用。 这是指组织内的人员开发自己的应用,并希望组织中的用户能够登录该应用的情况。
    • 应用代理应用 - 使用 Azure AD 应用代理公开本地应用程序时,单租户应用将注册到租户中(此外,还会注册到应用代理服务中)。 此应用代表本地应用程序进行所有的云交互(例如身份验证)。 (应用代理要求使用 Azure AD Basic 或更高版本。)
  2. 多租户应用

    • 其他人可以许可的多租户应用 - 类似于“组织开发的单租户应用”。 除了应用自身内部的逻辑不同之外,主要差别还在于其他租户中的用户也可以许可并登录到该应用。
    • 其他用户开发的、Contoso 可以同意的多租户应用。 (简称“已许可的应用”。)) 这是“组织开发的多租户应用”的另外一面。 其他组织开发多租户应用时,本组织的用户可以同意并登录该应用。
    • Microsoft 第一方应用 - 代表 Microsoft 服务的应用。 注册服务即表示许可该应用。 某些第一方应用有时附带特殊的用户界面 (UX) 和逻辑,围绕应用的访问建立策略时,经常会用到该界面和逻辑。
    • 预先集成的应用 - Azure AD 应用库中提供的应用,可将其添加到目录,在常用 SaaS 应用中实现单一登录(在某些情况下,还可以提供预配功能)。
    • Azure AD 单一登录:用于可与 Azure AD 集成的应用的“真实”SSO,通过 SAML 2.0 或 OpenID Connect 等受支持的登录协议提供。 向导会引导完成设置过程。
    • 密码单一登录:Azure AD 可安全存储应用的用户凭据,以及由 Azure AD 应用访问浏览器扩展“注入”登录表单的凭据。 也称为“密码存储”。

权限

注册应用时,执行应用注册的用户(即开发人员)将定义应用需要访问哪些权限和资源。 (资源本身的定义方式与其他应用一样。)) 例如,生成邮件阅读器应用的人员会表明,其应用需要“Office 365 Exchange Online”资源中的“以登录用户身份访问邮箱”权限:

为使一个应用(客户端)能够从另一个应用(资源)请求特定的权限,资源应用的开发人员可定义存在的权限。 在我们的示例中,“Office 365 Exchange Online”资源应用的所有者 Microsoft 已定义名为“以登录用户身份访问邮箱”的权限。

定义权限时,应用开发人员必须定义用户是否可以同意该权限,或是否需要管理员同意。 这样一来,开发人员能够允许用户自行同意仅请求低敏感度权限的应用,但需要管理员才能同意更敏感的权限。 例如,“Azure Active Directory”资源应用已经过定义,因此,用户可以同意请求有限只读权限的应用。 但是,需要管理员同意才能获取完整的读取权限和所有写入权限。

本机客户端未经过身份验证,因此,定义为本机客户端应用的应用仅可请求委托的权限。 这意味着获取令牌时,必须始终有实际用户的参与。 Web 应用和 Web API(机密客户端)在获取访问令牌时,始终必须在 Azure AD 上进行身份验证。 这意味着,它们还有可能请求仅限应用的权限。 例如,一个后端服务需要向另一个后端服务进行身份验证。 请求仅限应用的权限的应用程序始终需要管理员同意。

总结:

  • 应用(客户端)指明它需要对其他应用(资源)拥有的权限。
  • 应用(资源)指明要向其他应用(客户端)公开哪些权限。
  • 权限可以是仅限应用的权限,也可以是委托的权限。
  • 委托的权限可以标记为“允许用户同意”或“需要管理员同意”。
  • 应用可以充当客户端(通过声明它需要对某个资源拥有的权限)和/或资源(通过声明它要公开哪些权限)。