如何使用 Azure 身分識別連結庫向 Azure 服務驗證 JavaScript 應用程式
當應用程式需要存取 Azure 資源時,例如記憶體、Key Vault 或認知服務,應用程式必須向 Azure 進行驗證。 無論是部署到 Azure、內部部署,還是在本機開發人員工作站上進行開發,所有應用程式都是如此。 本文說明使用適用於 JavaScript 的 Azure SDK 時,向 Azure 驗證應用程式的建議方法。
建議的應用程式驗證方法
建議的方法是讓應用程式在向 Azure 資源進行驗證時,使用 令牌型驗證,而不是連接字串或密鑰。 Azure 身分識別程式庫提供令牌驗證,允許應用程式在本機開發、部署至 Azure 或部署到內部伺服器時,順暢地向 Azure 資源進行驗證。
應用程式應該用來向 Azure 資源驗證的特定令牌型驗證類型取決於應用程式執行的位置,如下圖所示。
環境 | 認證 |
---|---|
本機 | 當開發人員在本機開發期間執行應用程式時,可以選擇兩種方式向 Azure 驗證:一是使用應用程式服務主體進行本機開發,或是使用開發人員自己的 Azure 認證。 在本機開發期間 驗證一節中,會更詳細地討論這些選項。 |
天藍 | 在 Azure 上裝載應用程式時 - 應用程式應該使用受控識別向 Azure 資源進行驗證。 將在伺服器環境中的 驗證一節中,更詳細地討論這個選項。 |
內部部署 | 當應用程式在內部環境中裝載和部署時,應用程式應該使用應用程式服務主體來驗證 Azure 資源。 在伺服器環境中的驗證()一節中,將更詳細地討論這個選項()。 |
令牌型驗證的優點
建置 Azure 應用程式時,強烈建議使用令牌為基礎的驗證,代替使用秘密(如連接字串或密鑰)。 權杖型驗證隨附於 defaultAzureCredential
令牌型驗證 | 秘密 (連線字串與金鑰 ) |
---|---|
最低許可權原則,在 Azure 資源上建立應用程式所需的特定許可權。 | 連接字串或金鑰會授與 Azure 資源的完整許可權。 |
沒有需要儲存的應用程式密碼。 | 必須在應用程式設定或環境變數中儲存和輪替秘密。 |
Azure 身分識別程式庫會在幕後為您管理存取權杖。 這使得使用令牌驗證就像使用連接字串一樣簡單。 | 秘密不會受到管理。 |
應將連接字串的使用限制在不存取生產或敏感數據的概念驗證應用程式或開發原型階段。 否則,向 Azure 資源驗證時,Azure 身分識別連結庫中提供的令牌型驗證類別應該一律優先使用。
使用下列程式庫。
DefaultAzureCredential
Azure 身分識別連結庫所提供的 DefaultAzureCredential 類別可讓應用程式根據執行所在的環境使用不同的驗證方法。 此行為可讓應用程式從本機開發升級至測試環境,而不需變更程序代碼。 您可以為每個環境設定適當的驗證方法,DefaultAzureCredential
會自動偵測並使用該驗證方法。 使用 DefaultAzureCredential
應該優先於手動編碼條件式邏輯或功能旗標,以在不同的環境中使用不同的驗證方法。
關於使用 DefaultAzureCredential
的詳細資料,請參閱 在應用程式中使用 DefaultAzureCredential
。
伺服器環境中的驗證
在伺服器環境中裝載時,每個應用程式都應該為每個環境指派唯一 應用程式身分識別。 在 Azure 中,應用程式身分識別是由 服務主體來表示,這是一種特殊類型的 安全性主體,用來識別及驗證 Azure 的應用程式。 應用程式要使用的服務主體類型取決於您的應用程式執行位置。
本地開發時的驗證
在本機開發期間,應用程式在開發人員工作站上執行時,本機環境仍必須向應用程式使用的任何 Azure 服務進行驗證。
在應用程式中使用DefaultAzureCredential
DefaultAzureCredential 是一種有明確設計的、經排序的機制序列,用於向 Microsoft Entra ID 進行驗證。 每個驗證機制都是衍生自 TokenCredential 類別的類別,稱為 認證。 在運行時間,DefaultAzureCredential
嘗試使用第一個認證進行驗證。 如果該認證無法取得存取令牌,則會嘗試序列中的下一個認證,依此方式,直到成功取得存取令牌為止。 如此一來,您的應用程式就可以在不同的環境中使用不同的認證,而不需要撰寫環境特定的程序代碼。
若要使用 DefaultAzureCredential,請將 @azure/身分識別 套件新增至您的應用程式。
npm install @azure/identity
然後,下列 程式代碼範例 示範如何具現化 DefaultAzureCredential
物件,並將其與 Azure SDK 服務用戶端類別搭配使用,在此案例中是用來存取 Azure Blob 記憶體的 BlobServiceClient
。
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客戶端物件搭配使用。