Love in coding...

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.

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.

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.

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.

• 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.