適用於 JavaScript 的 Azure 身分識別用戶端連結庫中的認證鏈結

Azure 身分識別客戶端連結庫提供 認證，這些是實作 Azure Core 連結庫 TokenCredential 介面的公用類別。 認證憑證代表從 Microsoft Entra ID 取得存取令牌的不同驗證程序。 您可以個別選取這些認證或鏈結在一起，以形成要嘗試的已排序驗證機制序列。

• 個別認證 提供速度和確定性。 如果憑證未能通過驗證，您就知道認證未成功。
• 鏈條 提供備援。 當認證無法驗證時，會嘗試鏈結中的下一個認證。

設計驗證流程

當您使用 Azure SDK 用戶端連結庫時，第一個步驟是向 Azure 進行驗證。 有許多選項可用來進行驗證，例如開發小組中使用的工具和 IDE、測試及 CI/CD 等自動化工作流程，以及 Azure App Service 等裝載平臺。

從下列驗證流程的常見進展中選擇：

• 針對開發人員使用各種 IDE 和 CLI 來驗證 Azure的 團隊，使用 。 這樣會提供最大的彈性。 此彈性是以效能為代價提供，以驗證鏈結中的認證，直到成功為止。

  • 根據偵測到的環境，系統會自動替您選擇不同的認證方式。
  • 若要判斷選取的認證，請開啟 偵錯。

• 針對 小組使用 ChainedTokenCredential，具有嚴格且有範圍的工具選擇。 例如，他們都在相同的 IDE 或 CLI 中進行身份驗證並使用。 這讓團隊可以選擇精確的憑證及其排序，同時保持彈性，但性能成本有所降低。

  • 不論執行環境為何，您都可以從一個認證選取後援路徑到另一個認證。
  • 要判斷哪個憑證被選取，請開啟 偵錯。

• 對於在所有環境中具有認證確定性 小組，控制流程語句，例如 if/else，可讓您知道每個環境中選擇哪一個認證。

  • 沒有另一種認證方式的備援。
  • 您不需要偵錯，即可判斷已選擇哪一個認證，因為它已指定。

鏈結認證的運作方式

在運行時間，認證鏈結會嘗試使用序列的第一個認證進行驗證。 如果該認證無法取得存取令牌，則會嘗試序列中的下一個認證，依此方式，直到成功取得存取令牌為止。 下列順序圖說明此行為：

使用 DefaultAzureCredential 來提升靈活性

DefaultAzureCredential 是一種經仔細設計的、預先配置的認證鏈結。 其設計目的是支援許多環境，以及最常見的驗證流程和開發人員工具。 在圖形化形式中，基礎鏈看起來像這樣：

DefaultAzureCredential 嘗試認證的順序。

訂單	憑據	描述
1	環境	讀取 環境變數的集合，以判斷應用程式服務主體（應用程式使用者）是否已為應用程式設定。 如果是，DefaultAzureCredential 使用這些值向 Azure 驗證應用程式。 此方法最常用於伺服器環境，但也可以在本機開發時使用。
2	工作負載身分識別	如果應用程式部署至已啟用工作負載識別的 Azure 主機，請驗證該帳戶。
3	受控識別	如果應用程式部署至已啟用受控識別的 Azure 主機，請使用該受控識別向 Azure 驗證應用程式。
4	Azure CLI	如果開發人員使用 Azure CLI 的 az login 命令向 Azure 進行驗證，請使用相同的帳戶向 Azure 驗證應用程式。
5	Azure PowerShell	如果開發人員使用 Azure PowerShell 的 Connect-AzAccount Cmdlet 向 Azure 進行驗證，請使用相同的帳戶向 Azure 驗證應用程式。
6	Azure Developer CLI（開發者指令行介面）	如果開發人員使用 Azure Developer CLI 的 azd auth login 命令向 Azure 進行驗證，請使用該帳戶進行驗證。

最簡單的形式，您可以使用無參數版本的 DefaultAzureCredential，如下所示：

import { DefaultAzureCredential } from "@azure/identity";
import { BlobServiceClient } from "@azure/storage-blob";

// Acquire a credential object
const credential = new DefaultAzureCredential();

const blobServiceClient = new BlobServiceClient(
    "https://<my_account_name>.blob.core.windows.net",
    credential
);

憑證在環境中具有全域性

DefaultAzureCredential 會檢查特定 環境變數是否存在。 有人有可能在主電腦上的系統層級新增或修改這些環境變數。 這些變更適用於全球範圍，因此會改變任何在該電腦上執行的應用程式中，於運行時的 DefaultAzureCredential 行為。

使用 ChainedTokenCredential 來達到細緻控制

ChainedTokenCredential 是一個空的憑證鏈，您可以在其中新增憑證以滿足應用程式的需求。 例如，下列範例會新增 ManagedIdentityCredential 實例，然後新增 AzureCliCredential 實例。

import { 
    ChainedTokenCredential, 
    ManagedIdentityCredential, 
    AzureCliCredential 
} from "@azure/identity";

const credential = ChainedTokenCredential(
    ManagedIdentityCredential({ clientId: "<YOUR_CLIENT_ID>" }),
    AzureCliCredential()
);

上述程式代碼範例會建立由兩個認證組成的量身訂做認證鏈結。 首先嘗試使用者指派的受控識別變體 ManagedIdentityCredential，然後在必要時嘗試 AzureCliCredential。 在圖形化形式中，鏈條看起來像這樣：

提示

為了提升效能，請優化您 生產環境中的憑證排列順序。 應該最後添加用於本機開發環境的憑證。

除錯連鎖憑證

若要偵錯認證鏈結，請啟用 Azure SDK 記錄。

更多資源

• Azure CLI