Microsoft Entra ID 是什么？用 Web 系统调用 Power BI API 时为什么需要它

| PowerPlatform | 1 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1327

在使用 Azure、Power BI、Microsoft 365 或其他微软云服务时，经常会看到一个名字：

Microsoft Entra ID

第一次看到时，很容易误以为它是某个新的 Azure 服务，或者是专门用于 Power BI 的功能。

实际上，Microsoft Entra ID 的作用非常基础，也非常重要：

它是微软云平台用来管理用户、程序身份、登录认证和访问权限的统一身份系统。

以前它叫做：

Azure Active Directory
Azure AD
AAD

后来微软将其改名为：

Microsoft Entra ID

虽然名称改变了，但它的核心作用并没有发生根本变化。

一、Entra ID 可以简单理解成什么

可以把 Microsoft Entra ID 理解成微软云环境里的：

户籍管理系统
＋
身份认证系统
＋
门卫
＋
权限管理中心

当某个人或某个程序尝试访问 Azure、Power BI 或 Microsoft 365 时，系统首先需要确认几个问题：

你是谁？
↓
你的身份是否可信？
↓
你属于哪个组织？
↓
你是否有权限访问这个资源？
↓
允许访问，或者拒绝访问

Microsoft Entra ID 负责的就是这个过程。

它并不直接负责运行 Web 应用，也不负责生成 Power BI 报表，而是负责确认调用者的身份。

二、Entra ID 主要管理哪些内容

Microsoft Entra ID 可以管理两大类身份：

人类用户
程序和后台服务

1. 人类用户

例如：

  • 公司员工账号

  • Microsoft 365 账号

  • Azure 管理员账号

  • Power BI 用户账号

  • 外部合作人员账号

  • 用户组和安全组

当用户登录以下服务时，背后通常都会经过 Entra ID：

Microsoft 365
Azure Portal
Power BI Service
Microsoft Fabric
Teams
SharePoint

2. 程序身份

除了人类账号以外，后台程序也需要拥有自己的身份。

例如：

Azure Web App
后台批处理程序
Azure Function
自动化脚本
调用 Power BI API 的 Web 系统

程序不能像人类一样，每次调用 API 时手动输入邮箱、密码和验证码。

因此，微软允许开发者在 Entra ID 中给程序注册一个身份。

这个程序身份通常通过以下信息进行认证：

Tenant ID
Client ID
Client Secret

或者使用安全性更高的证书。

三、Entra ID 在 Power BI PDF 导出流程中做什么

假设现在有这样一个系统：

用户打开 Web 系统
↓
点击“输出账票”
↓
Web 后台调用 Power BI REST API
↓
Power BI 根据 RDL 生成 PDF
↓
Web 系统把 PDF 返回给用户

在这个过程中，Web 后台不能直接对 Power BI 说：

请帮我生成这个 PDF。

Power BI 必须先确认：

调用我的这个程序到底是谁？

因此，完整流程实际上是：

Azure Web App
↓
使用 Tenant ID、Client ID 和 Client Secret
↓
向 Microsoft Entra ID 请求认证
↓
Entra ID 验证程序身份
↓
Entra ID 返回 Access Token
↓
Web App 携带 Access Token 调用 Power BI REST API
↓
Power BI 验证权限
↓
Power BI 执行 RDL 并生成 PDF

所以，Microsoft Entra ID 在这里承担的是：

身份认证
Access Token 发放
程序身份管理

它不负责：

保存 RDL
执行 SQL
渲染报表
生成 PDF

生成 PDF 的工作仍然由 Power BI 或 Microsoft Fabric 完成。

四、什么是“应用注册”

在 Microsoft Entra ID 管理页面中，有一个功能叫：

应用注册
App registrations
アプリの登録

应用注册的作用，是给某个应用程序建立一份身份资料。

例如，给“处理状况等管理系统”的 Web 后台注册一个程序身份。

注册完成后，会获得一些重要信息。

Application ID，也叫 Client ID

Client ID 可以理解成程序的身份证号码。

例如：

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

微软通过 Client ID 判断：

当前请求是哪一个应用程序发起的。

Directory ID，也叫 Tenant ID

Tenant ID 表示这个程序属于哪个 Microsoft Entra ID 组织。

可以理解成：

公司或组织的编号

同一个应用名称可以出现在不同组织中，因此只知道 Client ID 还不够，还需要知道它属于哪个 Tenant。

Client Secret

Client Secret 是程序用于证明身份的密码。

Web 后台会使用：

Tenant ID
Client ID
Client Secret

向 Entra ID 申请 Access Token。

Client Secret 必须妥善保存，不能直接写在前端 JavaScript、HTML 或公开代码仓库中。

通常应该保存在：

Azure Web App Application Settings
Azure Key Vault
服务器环境变量
安全的机密管理系统

Redirect URI

Redirect URI 主要用于需要用户交互登录的场景。

例如：

用户点击“使用 Microsoft 登录”
↓
跳转到 Microsoft 登录画面
↓
登录完成
↓
返回指定的 Web 页面

但如果系统使用 Service Principal，在后台无用户参与地调用 Power BI REST API，通常主要使用的是 Client Credentials 流程，并不依赖普通的用户登录跳转。

五、什么是 Service Principal

理解 Microsoft Entra ID 时，最容易混淆的两个概念是：

App Registration
Service Principal

可以简单理解为：

App Registration
＝应用程序的身份模板

Service Principal
＝这个应用程序在当前组织中的实际身份

也可以用“身份证”来类比：

App Registration
＝给程序办理身份证

Service Principal
＝程序拿着这张身份证，在当前公司内部形成的实际账号

当一个应用程序被注册后，Entra ID 会在当前 Tenant 中创建对应的 Service Principal。

Power BI Workspace 真正授权的对象，通常就是这个 Service Principal，或者包含这个 Service Principal 的安全组。

六、普通用户账号和 Service Principal 有什么区别

普通用户账号

普通 Power BI 用户通常通过以下方式登录：

邮箱
密码
MFA 多重验证

完整流程类似：

用户打开 Power BI
↓
输入账号密码
↓
完成 MFA
↓
访问 Workspace 和报表

这种方式适合人类用户操作 Power BI 页面。

Service Principal

Service Principal 是给程序使用的身份。

它通常不需要人工输入密码，也不会弹出登录界面。

完整流程类似：

Web 后台程序
↓
使用 Client ID 和 Client Secret
↓
向 Entra ID 申请 Token
↓
自动调用 Power BI API

Service Principal 适合：

后台自动生成 PDF
定时生成报表
系统间 API 调用
无人值守处理
批量导出文件

因此，在 Web 系统调用 Power BI ExportToFile API 的场景下，通常使用 Service Principal，而不是让后台长期保存某个员工的 Power BI 用户名和密码。

七、什么是 Access Token

Access Token 是 Entra ID 发放给程序的临时访问凭证。

可以把它理解成：

临时通行证

Web 后台先向 Entra ID 证明自己的身份。

认证成功后，Entra ID 返回 Access Token。

之后 Web 后台调用 Power BI REST API 时，会在 HTTP 请求头中携带 Token：

Authorization: Bearer AccessToken

Power BI 收到请求后，会检查：

Token 是否有效
Token 是否过期
调用者是谁
调用者是否有权限访问目标 Workspace
调用者是否有权限执行导出

Access Token 通常具有有效期限，因此后台程序需要在过期后重新申请，而不是把一个 Token 永久保存下来。

八、为什么有了 Entra ID，还要配置 Power BI Workspace 权限

Microsoft Entra ID 只负责证明：

这个程序是谁。

但它不会自动决定：

这个程序可以访问哪个 Power BI Workspace。

所以，即使 Web App 已经成功从 Entra ID 获得 Access Token，如果没有 Power BI Workspace 权限，调用 API 仍然会失败。

完整权限结构可以理解为：

Microsoft Entra ID
负责确认调用者身份
↓
Power BI Workspace
负责决定调用者可以访问哪些报表
↓
Microsoft Fabric Capacity
负责提供报表执行和 PDF 导出的计算能力

因此，通常还需要在 Power BI Workspace 中，将 Service Principal 添加为成员。

也可以先建立一个 Entra ID 安全组：

Power BI API Applications

然后把 Service Principal 加入该安全组，再将安全组添加到 Workspace。

这样做的好处是权限更容易统一管理。

九、Entra ID、Power BI 和 Fabric 分别负责什么

这三个概念非常容易混在一起。

实际上，它们负责的事情完全不同。

服务 主要作用
Microsoft Entra ID 身份认证、用户管理、程序身份、Token 发放
Power BI Service 保存和管理报表、Workspace、RDL
Microsoft Fabric Capacity 提供报表运行、渲染和导出所需的计算资源
Azure Web App 运行自己的 Web 系统和后台代码
Power BI REST API 提供程序调用 Power BI 功能的接口

可以用下面的流程来理解：

用户
↓
Azure Web App
↓
Microsoft Entra ID 验证 Web App 身份
↓
Power BI 检查 Workspace 权限
↓
Fabric Capacity 执行并渲染 RDL
↓
生成 PDF
↓
Web App 返回给用户

十、Entra ID 本身需要单独购买吗

通常情况下，创建基础的 Entra ID Tenant、用户、应用注册和 Service Principal，并不需要为每个 Service Principal 单独购买许可证。

Service Principal 不是一个真实员工账号，因此一般不需要购买一份 Power BI Pro 用户许可证。

但是，Service Principal 能否成功使用 Power BI 的某些功能，还取决于：

Power BI Tenant 设置
Workspace 权限
报表所在容量
Fabric Capacity
API 本身的授权条件

因此，不能简单理解为：

有了 Entra ID，就可以免费调用所有 Power BI API。

Entra ID 只是解决身份问题，不负责解决 Power BI 和 Fabric 的产品授权问题。

十一、Web 系统中应该保存哪些信息

后台程序通常需要保存以下配置：

Tenant ID
Client ID
Client Secret
Power BI Workspace ID
Power BI Report ID

其中：

Tenant ID
Client ID

虽然不一定等同于密码，但仍不建议随意公开。

而：

Client Secret

必须按照密码级别管理。

不要将 Client Secret 写在：

前端 JavaScript
HTML 页面
GitHub 公开仓库
浏览器 LocalStorage
可被用户下载的配置文件

更合适的保存方式是：

Azure Web App 环境变量
Azure Key Vault
服务器机密配置

十二、一个完整的 Power BI API 身份验证示例

以 Web 系统导出 PDF 为例，可以把逻辑分成三个阶段。

第一阶段：获取 Access Token

Web 后台
↓
把 Tenant ID、Client ID、Client Secret 提交给 Entra ID
↓
Entra ID 验证身份
↓
返回 Access Token

第二阶段：调用 Power BI REST API

Web 后台
↓
携带 Access Token
↓
调用 ExportToFile API
↓
传入 Workspace ID、Report ID 和报表参数

第三阶段：取得 PDF

Power BI 开始执行报表
↓
RDL 使用参数查询数据库
↓
Fabric Capacity 渲染报表
↓
生成 PDF
↓
Web 后台下载 PDF
↓
返回浏览器

在这个流程中：

Entra ID
负责认证

Power BI
负责管理报表和接口

Fabric
负责计算和渲染

Web App
负责业务逻辑和向用户提供文件

十三、常见误解

误解一：Entra ID 是数据库

不是。

Entra ID 不是用于保存业务数据的 SQL 数据库。

它保存的是：

用户身份
组织信息
应用身份
用户组
权限关系
认证配置

误解二：Entra ID 会生成 Power BI 报表

不会。

Entra ID 只负责认证和授权。

真正生成报表的是：

Power BI
Microsoft Fabric
RDL 报表引擎

误解三：注册了应用，就自动获得 Power BI 权限

不会。

应用注册完成后，只代表程序拥有了一个身份。

还需要继续配置：

Power BI Tenant 设置
Workspace 访问权限
Service Principal 权限
Fabric Capacity

误解四：Service Principal 就是一个 Power BI 用户账号

不是。

Service Principal 是程序身份，不是普通员工账号。

它不能完全替代所有用户操作，也不等同于购买了一份 Power BI Pro 许可证。

误解五：Client Secret 可以写在前端

绝对不应该。

浏览器前端代码对用户基本是可见的。

如果将 Client Secret 写入前端，就相当于把程序密码公开给所有使用者。

Client Secret 只能在服务器端使用。

十四、总结

Microsoft Entra ID 是微软云平台的统一身份认证和权限管理系统。

在 Web 系统调用 Power BI REST API 生成 PDF 的场景中，它主要负责：

给 Web 程序注册身份
保存程序的 Client ID
验证 Client Secret
生成 Access Token
让 Power BI 知道调用者是谁

它不负责：

保存 RDL
查询业务数据库
渲染报表
生成 PDF
提供 Fabric 计算容量

可以用一句话概括：

Microsoft Entra ID 负责证明“这个 Web 程序是谁”，Power BI Workspace 负责决定“它能访问什么”，Microsoft Fabric Capacity 负责实际执行报表并生成 PDF。

最终完整架构是：

Web 系统
↓
使用 Service Principal
↓
向 Microsoft Entra ID 获取 Access Token
↓
调用 Power BI REST API
↓
Power BI 检查 Workspace 权限
↓
Fabric Capacity 执行 RDL
↓
生成 PDF
↓
返回给 Web 用户

只要理解了这条身份与权限链，Entra ID、Service Principal、Power BI Workspace 和 Fabric Capacity 之间的关系就会清晰很多。

This article was last edited at