Azure IAM中App Registration的Application Permissions与Role Assignment的差异

核心差异点 #

• 适用对象与范围
  Application Permissions是针对特定API/服务的权限（比如Microsoft Graph、第三方自定义API），配置在App Registration的「API权限」面板下，属于AAD的OAuth2权限体系，作用是允许应用以自身身份调用目标API。
  Azure IAM的Role Assignment则是针对Azure资源（如Storage Account、VM、Resource Group）的RBAC角色分配，作用是允许主体（包括App的Client ID）对Azure资源执行特定操作（如读取Blob、管理VM）。

• 权限定义来源
  Application Permissions由API的提供者定义（比如微软为Graph API预设User.Read.All、Mail.Send等权限，第三方API开发者可自定义权限）。
  IAM角色是Azure RBAC体系的一部分，分为内置角色（如Contributor、Reader）和自定义角色，由Azure平台或租户管理员定义，对应Azure资源的操作集合。

• 授权流程
  Application Permissions需要管理员同意（部分低风险权限无需同意），需通过AAD的权限授予流程完成，同意后权限绑定到App Registration。
  IAM Role Assignment直接在Azure资源的「IAM」页面添加主体（App的Client ID）和对应角色，分配后通常数分钟内生效，无需额外同意步骤。

• 身份验证上下文
  使用Application Permissions时，应用获取的Access Token中会包含roles声明（对应已同意的API权限），目标API通过验证该声明判断授权。
  使用IAM Role Assignment时，应用获取的Access Token中同样会包含roles声明（对应RBAC角色），Azure资源的服务会验证该角色是否允许执行当前操作。

当目标是Azure资源的API（如Storage REST API）时，两种授权方式可能存在重叠，但核心区别如下：

• 权限模型归属
  API的Application Permission属于AAD OAuth2权限模型，是目标API在AAD中注册时声明的权限，本质是API自身的访问控制规则。
  IAM Role Assignment属于Azure RBAC模型，是Azure平台统一的资源访问控制体系，覆盖所有Azure资源。

• 粒度与覆盖范围
  Application Permissions通常是API级别的细粒度权限（比如某API的特定操作权限），但并非所有Azure资源API都提供这类权限；而RBAC角色是操作的集合，粒度可粗可细（比如内置角色是粗粒度，自定义角色可细化到单个操作），且覆盖所有Azure资源的操作。

• 管理与生效逻辑
  Application Permissions需在App Registration中配置并获取管理员同意，权限变更需重新同意或更新权限列表；IAM Role Assignment直接在资源的IAM面板管理，变更即时生效（传播延迟通常在5分钟内）。

• 适用场景

  • 若要访问非Azure资源的API（如第三方SaaS服务的API），只能使用Application Permissions。
  • 若要访问Azure资源，优先使用IAM Role Assignment，这是Azure官方推荐的资源访问控制方式；部分旧版Azure资源API可能仍支持Application Permissions，但已逐步被RBAC替代。

内容的提问来源于stack exchange，提问作者Tarhone