使用適用於 .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。 如需選項，請參閱 衍生 清單。 - 對 Azure 環境進行優化的簡化版
ChainedTokenCredential實作，適用於您的應用程式運行所在地。ChainedTokenCredential基本上會建立可接受認證選項的特定允許清單，例如生產ManagedIdentity，以及用於開發VisualStudioCredential。
例如，請考慮在 ASP.NET Core 專案中的下列 DefaultAzureCredential 組態：
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
DefaultAzureCredential credential = new();
clientBuilder.UseCredential(credential);
});
將上述程式代碼取代為只指定必要認證的 ChainedTokenCredential 實作：
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
clientBuilder.UseCredential(new ChainedTokenCredential(
new ManagedIdentityCredential(clientId: userAssignedClientId),
new VisualStudioCredential()));
});
在此範例中，ManagedIdentityCredential 會在生產環境中自動偵測，而 VisualStudioCredential 可在本機開發環境中運行。
重複使用認證實例
盡可能重複使用認證實例，以改善應用程式復原能力，並減少發出給 entra ID Microsoft存取令牌要求的數目。 當認證被重複使用時，系統會嘗試從由基礎 MSAL 相依性所管理的應用程式 Token 快取中取得 Token。 如需詳細資訊，請參閱 Azure 身分識別用戶端程式庫中的 令牌快取。
重要
不重複使用認證的大量應用程式可能會遇到來自 Microsoft Entra ID 的 HTTP 429 節流回應，這可能會導致應用程式中斷。
建議的認證重複使用策略與 .NET 應用程式類型不同。
透過 Microsoft.Extensions.Azure的 UseCredential 方法來實作認證重複使用。 例如，假設 Azure App Service 上裝載 ASP.NET Core 應用程式，並已設定 UserAssignedClientId 環境變數。 .NET 組態提供者會判斷環境變數是否存在，而 ManagedIdentityCredential 將用來驗證 Key Vault 秘密和 Blob 記憶體用戶端。 否則，會使用鏈結的開發時間認證序列。
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddSecretClient(new Uri("<key-vault-url>"));
clientBuilder.AddBlobServiceClient(new Uri("<blob-storage-url>"));
string? clientId = builder.Configuration["UserAssignedClientId"];
TokenCredential credential = clientId is not null
? new ManagedIdentityCredential(
ManagedIdentityId.FromUserAssignedClientId(clientId))
: new ChainedTokenCredential(
new VisualStudioCredential(),
new AzureCliCredential(),
new AzurePowerShellCredential());
clientBuilder.UseCredential(credential);
});
如需此方法的相關信息，請參閱 使用 Microsoft Entra ID進行驗證。
瞭解何時需要令牌存留期和快取邏輯
如果您使用 Azure 身分識別連結庫認證，相依於 Azure Core的 Azure SDK 用戶端連結庫內容之外，您有責任管理應用程式中 令牌存留期 和快取行為。
AccessToken上的 RefreshOn 屬性提供了一個提示，告訴取用者何時可以嘗試刷新令牌。依賴 Azure Core 連結庫的 Azure SDK 用戶端連結庫會自動使用這個屬性來刷新令牌。 若要直接使用支援令牌快取 的 Azure 身分識別程式庫認證資訊，基礎 MSAL 快取會在發生 RefreshOn 時間時自動主動刷新。 此設計可讓用戶端程式代碼在每次需要令牌時呼叫 GetToken，並將重新整理委派給函式庫。
若要在必要時只呼叫 GetToken，請觀察 RefreshOn 日期，並主動嘗試在該時間之後重新整理令牌。 特定實作由客戶決定。
瞭解受控識別重試策略
適用於 .NET 的 Azure 身分識別程式庫可讓您使用 ManagedIdentityCredential透過受管理的身分識別進行驗證。 您使用 ManagedIdentityCredential 的方式會影響套用的重試策略。 透過下列方式使用時：
-
DefaultAzureCredential，當初始令牌擷取嘗試失敗或短時間內逾時時，不會嘗試重試。 這是最不具彈性的選項，因為它被優化為「快速失敗」以提升開發流程的迴圈效率。 - 任何其他方法，例如
ChainedTokenCredential或ManagedIdentityCredential直接：重試之間的時間間隔預設為0.8秒，最多嘗試五次重試。 此選項已針對彈性進行優化，但在開發內部迴圈中導入潛在不受歡迎的延遲。
若要變更任何預設重試設定，請使用
ManagedIdentityCredentialOptions上的Retry屬性。 例如，重試最多三次，開始間隔為0.5秒：ManagedIdentityCredentialOptions miCredentialOptions = new( ManagedIdentityId.FromUserAssignedClientId(clientId) ) { Retry = { MaxRetries = 3, Delay = TimeSpan.FromSeconds(0.5), } }; ChainedTokenCredential tokenChain = new( new ManagedIdentityCredential(miCredentialOptions), new VisualStudioCredential() );
如需自定義重試原則的詳細資訊，請參閱 設定自定義重試原則。
