SAS （共享访问签名）和 Bearer Token （持有者令牌）

SAS（共享访问签名）和 Bearer Token 是两种常见的认证/授权机制，但它们的应用场景、设计哲学和用法有显著区别。

下面我将详细解释它们的区别、设置和使用方法。

核心区别一览表

设置与使用方法

1. SAS (共享访问签名)

设置（以 Azure Blob Storage 为例）：

SAS通常在生产环境中由后端应用程序生成，然后安全地分发给前端客户端使用。

a. 在 Power Automate 中生成 SAS (作为调用方)：
如果你需要让Power Automate生成一个SAS去访问存储账户，可以使用 "Azure Blob Storage" 连接器 中的相关操作，例如“创建Blob”操作本身就支持使用SAS令牌。

b. 在 Power Automate 中使用 SAS (作为被调用方)：
当你的Flow通过“当收到HTTP请求时”触发，并且你需要让别人通过SAS来调用它时，你需要手动验证SAS。但这在Power Automate中实现比较复杂，更常见的做法是使用其他认证方式（如Entra ID）来保护你的HTTP端点。

使用：
客户端（如Web前端、移动应用）直接使用带有SAS令牌的URL来访问资源。

• 示例URL结构：
  https://mystorageaccount.blob.core.windows.net/mycontainer/myfile.txt?sp=rw&st=2023-10-27T14:30:00Z&se=2023-10-27T15:30:00Z&spr=https&sv=2020-08-04&sr=b&sig=<Generated_Signature>

• 在 Power Automate 的 “调用HTTP请求” 中：
  你只需要将整个带SAS令牌的URL 直接填入 "URL" 字段即可。无需在“认证”部分做任何额外配置。

  • 方法: GET

  • URI: https://mystorageaccount.blob.core.windows.net/mycontainer/myfile.txt?sp=rw&st=...&sig=...

2. Bearer Token

设置：

Bearer Token通常通过OAuth 2.0/OpenID Connect流来获取。在Azure上下文中，这意味着使用 Microsoft Entra ID。

a. 在 Power Automate 中获取并使用 Token (作为调用方)：
这是Power Automate的强项。在 “调用HTTP请求” 操作中，内置了对Entra ID认证的支持。

1. 在“调用HTTP请求”操作中，点击“认证”类型下拉菜单。

2. 选择 “Active Directory OAuth”。

3. 填写以下信息：

   • 权限: https://graph.microsoft.com (或其他目标API的权限，如 https://management.azure.com)

   • 客户端ID: 你的Entra ID中注册的应用程序ID。

   • 客户端密钥/证书: 该应用程序的密钥或证书。

   • 受众: 通常与“权限”相同，表示你希望访问的API。

   • 租户ID: 你的Azure AD租户ID。

配置完成后，Power Automate会自动处理令牌的获取、刷新，并在发送请求时在Authorization头中附加Bearer Token。

使用：
在HTTP请求的Authorization头中携带令牌。

• 示例HTTP头：
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...

• 在 Power Automate 的 “调用HTTP请求” 中：
  如上所述，通过内置的“Active Directory OAuth”认证类型配置后，这一切都是自动完成的。你无需手动构造此头。

总结与如何选择

简单记忆：SAS用于授权访问“东西”（数据资源），而Bearer Token用于授权访问“动作”（API接口）。在Power Automate中，调用受保护的API，优先使用内置的Active Directory OAuth (Bearer Token)认证。

在 “When a HTTP request is received” 触发器中的 “HTTP POST URL” 里，你既不能设置 Bearer，也不能设置 SAS。这个 URL 本身是一个“地址”，而 Bearer 和 SAS 是用于访问这个地址的“钥匙”。

让我用一个比喻来解释：

• HTTP POST URL：就像你家的地址。

• Bearer Token 或 SAS：就像用来打开你家大门的钥匙。

你不会把钥匙本身变成地址的一部分。你会把地址给别人，然后他们在来访时（发送请求时）出示钥匙。

所以，问题应该转变为：调用方（Caller）在调用我这个 Flow 的 URL 时，应该如何设置 Bearer 或 SAS 认证？

调用方如何认证你的 Flow

当其他服务、应用程序或用户想要触发你的 Flow 时，他们需要向那个自动生成的 “HTTP POST URL” 发送一个 POST 请求。认证信息是在这个请求的 HTTP 头 中携带的。

以下是两种方式的详细设置方法：

方案一：使用 Bearer Token (推荐用于服务/服务间认证)

这是最常用且安全的方式，尤其适用于 Azure 服务之间或你信任的应用程序调用你的 Flow。

调用方需要在 HTTP 请求头中设置：

Authorization: Bearer <你的令牌>

如何获取 <你的令牌>？
这个令牌需要从 Microsoft Entra ID 获取，并且其“受众”或“资源”必须是你 Flow 的 URL。

1. 在 Flow 中启用 AAD 认证：

   • 编辑你的 Flow。

   • 点击 “When a HTTP request is received” 触发器。

   • 展开 “身份验证” 部分。

   • 默认是 “无”。你可以在这里选择一种预定义的策略，但更常见和灵活的是在 Azure Portal 中配置。

2. 在 Azure API Management 或 Entra ID 中配置：

   • 更标准的做法是，将你的 Flow 的 URL 在 Azure Entra ID 中注册为一个 “应用” 或保护资源。

   • 然后，调用方应用程序使用其 客户端 ID 和 客户端密钥 向 Entra ID 请求一个访问令牌。

   • Power Automate 会验证这个令牌的签名、颁发者和有效期。

在 Power Automate (作为调用方) 的设置示例：
如果你用另一个 Flow 来调用这个 Flow，你可以在 “Invoke an HTTP request” 操作中：

• 认证类型：选择 Active Directory OAuth

• 权限：填写你保护的 Flow 的 URL（或在 AAD 中注册的 App ID URI）。

方案二：使用 SAS (共享访问签名)

这种方式不如 Bearer Token 安全，但配置简单，适用于快速测试或与非 Azure 服务集成。

调用方需要在 HTTP 请求头中设置：

或者，有时也可以使用一个特定的头，如：

x-ms-sas-token: <你的SAS令牌>

如何获取/生成 SAS 令牌？
SAS 令牌通常是对一组声明（如有效期、权限）进行加密签名后生成的字符串。对于保护自定义 HTTP 端点，你需要一个后端服务来按照与你 Flow 验证逻辑相匹配的规则生成和验证它。但请注意，Power Automate 的原生 “When a HTTP request is received” 触发器并不直接支持开箱即用的 SAS 令牌验证。 你需要在自己的触发器逻辑中解析 HTTP 头并手动验证签名，这非常复杂且不推荐。

总结与建议

最终建议：

强烈推荐使用 Bearer Token (通过 Microsoft Entra ID) 的方式来保护你的 “When a HTTP request is received” 触发器。

这样做可以利用 Azure 成熟的身份平台，实现集中、安全、可管理的访问控制。对于简单的、不需要高级安全性的场景，你也可以考虑使用查询字符串参数传递一个自定义的“密钥”并在 Flow 里检查，但这远不如 Bearer Token 安全。

好的，我们来详细分解这个 Power Automate (或 Azure Logic Apps) 的 HTTP 请求触发器 URL 的各个部分。

这个 URL 是当你创建 “当收到 HTTP 请求时” 触发器时自动生成的，是调用该 Flow/Logic App 的唯一入口点。

URL 各部分意义分析

我们以这个结构为例：
https://<region>/workflows/<workflowid>/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0

1. 基础路径部分

• https://

  • 意义：使用 HTTPS 协议，确保通信安全。

• <region>

  • 意义：你的 Flow/Logic App 所在的** Azure 区域数据中心**。

  • 示例：prod-00.westus.logic.azure.com。这表示该工作流托管在美国西部区域。

• /workflows/

  • 意义：表示这是一个工作流服务的固定路径。

• <workflowid>

  • 意义：你的 Flow/Logic App 的唯一标识符。这是一个 GUID，确保每个工作流的 URL 都是全球唯一的。

• /triggers/manual/

  • 意义：指明这是一个“手动”触发器。在 Power Automate 和 Logic Apps 中，“当收到 HTTP 请求时” 触发器被归类为 “manual” 类型。

• /paths/invoke

  • 意义：这是触发工作流的固定端点路径。意思是“调用”或“触发”这个触发器。

2. 查询字符串参数部分

这是 URL 中 ? 之后的部分，以 & 分隔，用于向服务传递额外的指令和信息。

• api-version=2016-06-01

  • 意义：指定要使用的 Logic Apps REST API 的版本。这个版本是 Logic Apps 服务首次正式发布时的 API 版本，Power Automate 基于此构建，因此保持了兼容性。

• sp=%2Ftriggers%2Fmanual%2Frun

  • 意义：这是整个 URL 中最关键的安全和权限部分。

  • 解码：%2F 是 / 的 URL 编码形式。所以解码后是 sp=/triggers/manual/run。

  • 含义：sp 代表 SAS Pattern。它定义了对该资源（即你的触发器）的访问权限。这里的 /triggers/manual/run 表示调用者被授予了执行/运行 这个手动触发器的权限。

  • 重要性：这个参数与一个加密签名（SIG）结合使用，构成了共享访问签名 的安全模型。它精确指定了允许的操作。

• sv=1.0

  • 意义：签名版本。指定用于生成 URL 签名的 SAS 版本。1.0 是当前使用的标准版本。

可能存在的隐藏部分

在你看到的完整 URL 中，通常还会有一个至关重要的参数：

• &sig=<很长的一段字符串>

  • 意义：签名。这是基于 URL 路径、查询参数（特别是 sp）以及一个秘密密钥通过哈希算法生成的加密签名。

  • 作用：这是验证请求是否合法的关键。Azure 后端服务会使用相同的密钥重新计算签名，如果匹配，则证明请求有效，有权执行 sp 参数所定义的操作。

  • 警告：这个 sig 参数相当于你的 Flow 的密码。 如果整个 URL（包含 sig）被泄露，任何拥有该 URL 的人都可以触发你的 Flow。

总结与整体理解

你可以将这个 URL 理解为：

“请向位于 <region> 的、ID 为 <workflowid> 的特定工作流，发起一个请求，要求‘运行’其‘手动’触发器。我使用的 API 版本是 2016-06-01，并且我提供的签名 sig 证明我有权限 sp 来执行这个‘运行’操作。”

重要提示：

• 这个 URL 是一次性生成的。如果你在 Flow 的触发器设置中点击“Regenerate”（重新生成），sig 部分会改变，旧的 URL 将立即失效。

• 在实际调用时，你必须是 POST 请求到这个 URL，并在请求体中携带 JSON 数据（与你在触发器定义的 JSON Schema 匹配）。

本文转自：Regenerate the SAS key used in HTTP trigger flows - Power Automate | Microsoft Learn

This article provides instructions on how to regenerate the SAS (Shared Access Signature) key used in HTTP trigger flows in Power Automate. Regenerating the SAS key is essential for maintaining the security and functionality of your HTTP trigger flows. Over time, the SAS key might become compromised or need to be updated to adhere to security policies. By regenerating the key, you ensure that only authorized requests can trigger your flow, which protects your data and processes from unauthorized access.

Step 1: Identify the SAS string being used by your flow

Identifying the SAS string being used by your flow is crucial because it allows you to confirm that the key regeneration process was successful. By noting the current SAS string, you can compare it with the new string after regeneration to ensure that the operation was executed correctly. This step helps in validating that the flow is using the updated key, which is essential for maintaining the security and functionality of your HTTP trigger flows.

To identify the SAS string being used by your flow:

1. Sign in to Power Automate.

2. Open your flow in the designer.

   

3. Copy the HTTP trigger URL.

   https://<region>/workflows/<workflowid>/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<value>

4. Make a note of the URL string that starts with sig=.

   Once the key is regenerated, this value changes and serves as a confirmation that the execution of the following steps was successful.

Step 2: Create the request to regenerate the string

Creating the request to regenerate the SAS string is essential for maintaining the security and functionality of your HTTP trigger flows. This multi-step process requires using the browser tools. The steps in this section use Microsoft Edge browser.

To create the request to regenerate the string:

1. Navigate to the flow Details page (not the designer page).

   

2. In the Windows Settings menu, select More tools > Developer tools and navigate to the Network tab.

3. Select Clear network log (or select Ctrl + L).

4. Select Record network log (or select Ctrl + E).

5. Refresh the page by selecting Ctrl + R.

6. Filter the items with api.flow and select the request that starts with runs?api-version=.

   

7. From the Network tab > Headers subtab, copy the Request URL to a text editor.

8. Replace the word runs with regenerateAccessKey.

9. From the Network tab > Headers subtab, copy the Authorization header. Make sure you don't include the next header in your selection.

10. Copy the following text in your text editor:

fetch('<regenerateAccessKeyUrl>', {
  method: 'POST',
  headers: {
    'Content-type': 'application/json; charset=UTF-8',
   'Authorization': '<Authentication Header>'
  }
})
.then(result => result.json())
.then(console.log)

11. In the fetch command, replace <regenerateAccessKeyUrl> with the request URL you constructed in Step 8 in your text editor.
12. Replace <regenerateAccessKeyUrl> with the Authorization header you copied in Step 9 to your text editor.

Congratulations! You're now ready with the command to regenerate the key.

Step 3: Execute the regenerate request

When you execute the regenerate request, the SAS key associated with your HTTP trigger flow is regenerated. This means that a new key is created, and the old key is invalidated. The new key is reflected in the sig= parameter of the HTTP trigger URL. This ensures that only requests with the new key can trigger the flow, enhancing the security of your automation.

To execute the regenerate request:

1. Copy the code snippet from Step 2 that you constructed in the text editor.

2. Navigate to the Console tab and paste the text here.

3. Select Enter.

   The command executes as Promise Pending.

   

4. Open your flow in the Power Automate designer and open the HTTP trigger action.

   The Post URL should have a different value for sig= than what was recorded at the end of Step 1.

   

Congratulations! You successfully refreshed the SAS key.

Troubleshooting

• If you encounter an error executing the command, make sure the text in the command doesn't have any extra spacings and is well constructed.

• If the command execution returns Rejected, the key might still be updated successfully. It’s best to validate the flow URL to ensure the sig= value is indeed updated.