使用適用於 .NET 的 Azure 身分識別連結庫進行驗證最佳做法

本文提供指導方針，可協助您在向 Azure 服務進行驗證時，將 .NET 應用程式的效能和可靠性最大化。若要充分利用適用於 .NET 的 Azure 身分識別連結庫，請務必瞭解潛在問題和風險降低技術。

在生產環境中使用決定性認證

DefaultAzureCredential 是開始使用 Azure 身分識別連結庫的最平易近人的方法，但這種便利性也會帶來某些取捨。最值得注意的是，鏈結中成功且用於要求驗證的特定認證無法事先保證。在生產環境中，這種不可預測性可能會帶來重大且有時微妙的問題。

例如，請考慮下列假設的事件序列：

組織的安全性小組會授權所有應用程式使用受控識別向 Azure 資源進行驗證。
幾個月來，裝載在 Azure 虛擬機（VM）上的 .NET 應用程式已成功使用 DefaultAzureCredential 透過受控識別進行驗證。
若未告知支援小組，開發人員會在該 VM 上安裝 Azure CLI，並執行 az login 命令來向 Azure 進行驗證。
由於 Azure 環境中的個別組態變更，透過原始受控識別的驗證會意外開始以無訊息方式失敗。
DefaultAzureCredential 會略過失敗的 ManagedIdentityCredential，並搜尋下一個可用的認證，也就是 AzureCliCredential。
應用程式會開始使用 Azure CLI 認證，而不是受控識別，這可能會失敗，或導致非預期的提高或降低許可權。

若要避免生產應用程式中這類細微的問題或無聲失敗，請將 DefaultAzureCredential 替換為特定的 TokenCredential 實作，例如 ManagedIdentityCredential。如需選項，請參閱衍生清單。

舉例來說，考慮 ASP.NET 核心專案中的以下配置。一個實例 DefaultAzureCredential 被隱含建立並用於所有註冊的服務客戶端：

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));
});

修改上述程式代碼，根據應用程式執行所在的環境選取認證：

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

在此範例中，只有 ManagedIdentityCredential 用於生產環境。然後，本機開發環境的身份驗證需求會由 else 子句中定義的憑證序列來滿足。

重複使用認證實例

盡可能重複使用認證實例，以改善應用程式復原能力，並減少發出給 entra ID Microsoft存取令牌要求的數目。當認證被重複使用時，系統會嘗試從由基礎 MSAL 相依性所管理的應用程式 Token 快取中取得 Token。如需詳細資訊，請參閱 Azure 身分識別用戶端程式庫中的令牌快取。

重要

不重複使用認證的大量應用程式可能會遇到來自 Microsoft Entra ID 的 HTTP 429 節流回應，這可能會導致應用程式中斷。

建議的認證重複使用策略與 .NET 應用程式類型不同。

ASP.NET 核心
其他

若要實作認證重複使用，請使用 UseCredential 中的 Microsoft.Extensions.Azure方法。請考慮在生產環境與預備環境中裝載於 Azure App Service 上的 ASP.NET Core 應用程式。環境變數 ASPNETCORE_ENVIRONMENT 會設定為 Production 或 Staging ，以區分這兩個非開發環境。在生產環境與預備環境中，使用者指派的 ManagedIdentityCredential 變體是用來驗證 Key Vault 秘密和 Blob 記憶體用戶端。

當應用程式在本機開發計算機上執行時，ASPNETCORE_ENVIRONMENT 被設為 Development，而改以使用一系列鏈結的開發人員工具認證。此方法可確保使用環境適當的認證、增強安全性和簡化認證管理。

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(
        new Uri($"https://{keyVaultName}.vault.azure.net"));
    clientBuilder.AddBlobServiceClient(
        new Uri($"https://{storageAccountName}.blob.core.windows.net"));

    TokenCredential credential;

    if (builder.Environment.IsProduction() || builder.Environment.IsStaging())
    {
        string? clientId = builder.Configuration["UserAssignedClientId"];
        credential = new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId));
    }
    else
    {
        // local development environment
        credential = new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());
    }

    clientBuilder.UseCredential(credential);
});

如需 ASP.NET Core 應用程式中此方法的相關信息，請參閱使用 Microsoft Entra 標識符進行驗證。

在 non-ASP.NET Core 應用程式中，藉由將相同的認證實例傳遞至每個用戶端建構函式，來完成認證重複使用。例如，假設 WPF 應用程式使用 Windows 上的驗證代理程式。

private void testBrokeredAuth_Click(object sender, RoutedEventArgs e)
{
    IntPtr windowHandle = new WindowInteropHelper(this).Handle;
    InteractiveBrowserCredential credential = new(
        new InteractiveBrowserCredentialBrokerOptions(windowHandle)
        {
            UseDefaultBrokerAccount = true,
        });

    BlobServiceClient blobServiceClient = new(
        new Uri("<blob-storage-url>"),
        credential);

    SecretClient secretClient = new(
        new Uri("<key-vault-url>"),
        credential);
}

瞭解何時需要令牌存留期和快取邏輯

如果您使用 Azure 身分識別連結庫認證，相依於 Azure Core的 Azure SDK 用戶端連結庫內容之外，您有責任管理應用程式中令牌存留期和快取行為。

RefreshOn上的 AccessToken 屬性提供了一個提示，告訴取用者何時可以嘗試刷新令牌。依賴 Azure Core 連結庫的 Azure SDK 用戶端連結庫會自動使用這個屬性來刷新令牌。若要直接使用支援令牌快取的 Azure 身分識別程式庫認證資訊，基礎 MSAL 快取會在發生 RefreshOn 時間時自動主動刷新。此設計可讓用戶端程式代碼在每次需要令牌時呼叫 GetToken，並將重新整理委派給函式庫。

若要在必要時只呼叫 GetToken，請觀察 RefreshOn 日期，並主動嘗試在該時間之後重新整理令牌。特定實作由客戶決定。

瞭解受控識別重試策略

適用於 .NET 的 Azure 身分識別程式庫可讓您使用 ManagedIdentityCredential透過受管理的身分識別進行驗證。您使用的 ManagedIdentityCredential 模式會影響套用的重試策略。

「快速失敗」模式

何時使用： 適用於需要快速回饋的本機開發情境
如何啟動： 以下列其中一種方式使用 DefaultAzureCredential ：
- 不設定環境變數 AZURE_TOKEN_CREDENTIALS
- 當環境變數 AZURE_TOKEN_CREDENTIALS 被設為不等於 ManagedIdentityCredential 的字串時
怎麼運作的： 當初始令牌獲取嘗試失敗或在短時間內超時時，不會嘗試重試。這是彈性最差的模式，因為它經過最佳化，可「快速失敗」，以實現高效的開發內部迴圈。

韌性模式

何時使用： 適用於彈性很重要的生產案例
如何啟動： 採取下列其中一種方法：
- 使用 DefaultAzureCredential 並將環境變數 AZURE_TOKEN_CREDENTIALS 設定為 ManagedIdentityCredential
  
  重要
  
  此 DefaultAzureCredential 方法只會在使用 Azure.Identity 套件 1.16.0 版或更新版本時，以復原模式運作。在舊版中，此方法以「快速失敗」模式運作。
- 利用 ChainedTokenCredential 以包含 ManagedIdentityCredential
- 直接使用ManagedIdentityCredential
怎麼運作的： 重試之間的時間間隔從 0.8 秒開始，預設最多進行五次重試，且每次的等待時間會以指數退避方式增加。此模式針對彈性進行了最佳化，但在開發內部迴圈中引入了可能不必要的延遲。

若要變更預設重試設定，請使用 Retry 或 DefaultAzureCredentialOptions上的ManagedIdentityCredentialOptions屬性。例如，重試最多三次，開始間隔為0.5秒：
```
ManagedIdentityCredentialOptions miCredentialOptions = new(
        ManagedIdentityId.FromUserAssignedClientId(clientId)
    )
    {
        Retry =
        {
            MaxRetries = 3,
            Delay = TimeSpan.FromSeconds(0.5),
        }
    };

ManagedIdentityCredential miCredential = new(miCredentialOptions);
```
如需自定義重試原則的詳細資訊，請參閱設定自定義重試原則。

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-09-19