如何使用適用於 JavaScript 的 Azure SDK 向 Azure 服務驗證 JavaScript 應用程式

當應用程式需要存取 Azure 資源時（例如 儲存體、金鑰保存庫或認知服務），應用程式必須向 Azure 進行驗證。 無論是部署至 Azure、內部部署或在本機開發人員工作站上進行開發，皆須進行此動作。 本文說明使用適用於 JavaScript 的 Azure SDK 時，向 Azure 驗證應用程式的建議方法。

建議的應用程式驗證方法

建議的程式是讓應用程式在向 Azure 資源進行驗證時，使用令牌型驗證，而不是 連接字串 或密鑰。 Azure SDK 提供令牌型驗證，並允許應用程式順暢地向 Azure 資源進行驗證，無論應用程式是在本機開發中、部署至 Azure，還是部署至內部部署伺服器。

應用程式應該用來向 Azure 資源驗證的特定令牌型驗證類型取決於應用程式執行的位置，如下圖所示。

Environment	驗證
本機	當開發人員在本機開發期間執行應用程式時 - 應用程式可針對本機開發使用應用程式服務主體，或使用開發人員的 Azure 認證向 Azure 進行驗證。 在本機開發期間驗證一節中，將詳細分別討論這些選項。
Azure	當應用程式裝載於 Azure 時 - 應用程式應使用受控識別向 Azure 資源進行驗證。 在伺服器環境中驗證一節中，將詳細討論這個選項。
內部部署	當應用程式裝載並部署於內部部署時 - 應用程式應使用應用程式服務主體向 Azure 資源進行驗證。 在伺服器環境中驗證一節中，將詳細討論這個選項。

權杖型驗證的優點

建置適用於 Azure 的應用程式時，強烈建議您將令牌型驗證用於秘密（連接字串 或密鑰）。 令牌型驗證隨附 DefaultAzureCredential。

權杖型驗證	秘密（連接字串和金鑰）
最低許可權原則，在 Azure 資源上建立應用程式所需的特定許可權。	連接字串 或金鑰會授與 Azure 資源的完整許可權。
沒有應用程式秘密可儲存。	必須在應用程式設定或環境變數中儲存和輪替秘密。
Azure 身分識別 SDK 會在幕後為您管理令牌。 這讓使用令牌型驗證變得容易做為 連接字串。	秘密不會受到管理。

連接字串的使用情境，應限制為不存取實際執行或敏感性資料的初始概念證明應用程式或開發原型。 否則，在對 Azure 資源進行驗證時，應一律優先使用 Azure SDK 中所提供的權杖型驗證類別。

使用下列 SDK：

• @azure/identity

DefaultAzureCredential

Azure SDK DefaultAzureCredential 方法可讓應用程式根據其執行環境使用不同的驗證方法。 這可讓應用程式在本機、測試和生產環境中部署，而不需要變更程序代碼。 您可以為每個環境設定適當的驗證方法，並 DefaultAzureCredential 自動偵測並使用該驗證方法。 使用 DefaultAzureCredential 優先於手動編碼條件式邏輯或功能旗標，以在不同的環境中使用不同的驗證方法。

本文稍後將涵蓋使用DefaultAzureCredential類別的詳細數據，請參閱在應用程式中使用DefaultAzureCredential一節。

伺服器環境中的驗證

在伺服器環境中裝載時，每個應用程式都應該為每個環境指派唯 一的應用程式身分 識別。 在 Azure 中，服務主體即代表應用程式身分識別，這是一種特殊類型的安全性主體，用於識別和驗證 Azure 的應用程式。 應用程式要使用的服務主體類型，取決於應用程式的執行位置。

本機開發期間的驗證

在本機開發期間，應用程式在開發人員工作站上執行時，本機環境仍必須向應用程式使用的任何 Azure 服務進行驗證。

使用應用程式中的 DefaultAzureCredential

若要在 JavaScript 應用程式中使用 DefaultAzureCredential，請將@azure/身分識別套件新增至您的應用程式。

npm install @azure/identity

然後，下列程式 代碼範例 示範如何具現化 DefaultAzureCredential 物件，並將其與 Azure SDK 用戶端類別搭配使用，在此案例中是用來存取 Blob 記憶體的 BlobServiceClient。

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential 會自動偵測為應用程式設定的驗證機制，並取得向 Azure 驗證應用程式所需的令牌。 如果應用程式使用多個SDK用戶端，則相同的認證物件可以與每個SDK客戶端物件搭配使用。

使用 DefaultAzureCredential 時選取驗證方法的順序

在內部，實作選取認證提供者的鏈結， DefaultAzureCredential 以便向 Azure 資源驗證應用程式。 每個認證提供者皆可偵測應用程式是否已設定該認證類型。 DefaultAzureCredential 會依序檢查各提供者，從第一個設定認證的提供者開始使用認證。

如果您已設定多個認證，透過鏈結尋找認證的順序很重要。

下圖和下表顯示尋找 JavaScript 認證的順序 DefaultAzureCredential 。

有兩個路徑：

• 已部署的服務 （Azure 或內部部署）：順序會以環境變數開始，然後是受控識別，然後是認證的其他位置（Visual Studio Code、Azure CLI、Azure PowerShell）。
• 開發人員的本機環境：本機開發人員工作站的鏈結會從Visual Studio Code的登入 Azure 使用者開始，顯示在 IDE 的底部列中，然後移至 Azure CLI，然後移至 Azure PowerShell。 請務必瞭解您是否已針對整個環境或專案的虛擬環境設定本機環境變數（例如 DOTENV），這些變數將會覆寫 Visual Studio Code - Azure CLI ->> PowerShell 鏈結，因為它們是鏈結中核取的第一個認證。

認證類型	描述
Environment	DefaultAzureCredential 會讀取一組環境變數，以判斷是否已為應用程式設定應用程式服務主體（應用程式使用者）。 如是，DefaultAzureCredential 則會使用這些值向 Azure 驗證應用程式。 此方法最常用於伺服器環境，但也可在本機開發時使用。
受控識別	若應用程式所部署的 Azure 主機已啟用受控識別，DefaultAzureCredential 將會使用該受控識別來驗證該應用程式。 本文件伺服器環境中的驗證一節會討論使用受控識別的驗證。 只有當應用程式是使用 已啟用受控識別的服務裝載在 Azure 中時，才可使用此方法。
Visual Studio Code	若開發人員已使用 Visual Studio Code Azure 帳戶外掛程式向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。
Azure CLI	若開發人員已使用 Azure CLI 中的 az login 命令向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。
Azure PowerShell	若開發人員已使用 Azure PowerShell 的 Connect-AzAccount Cmdlet 向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。
互動式	如果啟用，DefaultAzureCredential 會透過目前系統的預設瀏覽器以互動方式驗證開發人員。 預設會停用這個選項。