Praktik terbaik autentikasi dengan pustaka Azure Identity untuk .NET

Artikel ini menawarkan panduan untuk membantu Anda memaksimalkan performa dan keandalan aplikasi .NET Anda saat mengautentikasi ke layanan Azure. Untuk memanfaatkan pustaka Azure Identity untuk .NET, penting untuk memahami potensi masalah dan teknik mitigasi.

Menggunakan kredensial deterministik di lingkungan produksi

DefaultAzureCredential adalah cara paling mudah diakses untuk memulai pustaka Azure Identity, tetapi kenyamanan itu juga memperkenalkan kompromi tertentu. Terutama, kredensial tertentu dalam rantai yang akan berhasil dan digunakan untuk autentikasi permintaan tidak dapat dijamin sebelumnya. Dalam lingkungan produksi, ketidakpastian ini dapat menimbulkan masalah yang signifikan dan terkadang halus.

Misalnya, pertimbangkan urutan peristiwa hipotetis berikut:

1. Tim keamanan organisasi mengamanatkan semua aplikasi menggunakan identitas terkelola untuk mengautentikasi ke sumber daya Azure.
2. Selama berbulan-bulan, aplikasi .NET yang dihosting di Azure Virtual Machine (VM) berhasil menggunakan DefaultAzureCredential untuk mengautentikasi melalui identitas terkelola.
3. Tanpa memberi tahu tim dukungan, pengembang menginstal Azure CLI pada VM tersebut dan menjalankan perintah az login untuk mengautentikasi ke Azure.
4. Karena perubahan konfigurasi terpisah di lingkungan Azure, autentikasi melalui identitas terkelola asli secara tak terduga mulai gagal secara diam-diam.
5. DefaultAzureCredential melewati ManagedIdentityCredential yang gagal dan mencari kredensial berikutnya yang tersedia, yaitu AzureCliCredential.
6. Aplikasi mulai menggunakan kredensial Azure CLI daripada identitas terkelola, yang mungkin gagal atau mengakibatkan elevasi atau pengurangan hak istimewa yang tidak terduga.

Untuk mencegah jenis masalah halus ini atau kegagalan senyap dalam aplikasi produksi, sangat pertimbangkan untuk berpindah dari DefaultAzureCredential ke salah satu solusi deterministik berikut:

• Implementasi TokenCredential tertentu, seperti ManagedIdentityCredential. Lihat daftar turunan untuk opsi.
• Implementasi ChainedTokenCredential yang disederhanakan dan dioptimalkan untuk lingkungan Azure tempat aplikasi Anda berjalan. ChainedTokenCredential pada dasarnya membuat daftar izin tertentu dari opsi kredensial yang dapat diterima, seperti ManagedIdentity untuk produksi dan VisualStudioCredential untuk pengembangan.

Misalnya, pertimbangkan konfigurasi DefaultAzureCredential berikut dalam proyek ASP.NET Core:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    DefaultAzureCredential credential = new();
    clientBuilder.UseCredential(credential);
});

Ganti kode sebelumnya dengan implementasi ChainedTokenCredential yang hanya menentukan kredensial yang diperlukan:

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()));
});

Dalam contoh ini, ManagedIdentityCredential akan secara otomatis ditemukan dalam produksi, sementara VisualStudioCredential akan bekerja di lingkungan pengembangan lokal.

Menggunakan kembali instans kredensial

Gunakan kembali instans kredensial jika memungkinkan untuk meningkatkan ketahanan aplikasi dan mengurangi jumlah permintaan token akses yang dikeluarkan untuk ID Microsoft Entra. Ketika kredensial dipakai ulang, upaya dilakukan untuk mengambil token dari cache token aplikasi yang dikelola oleh dependensi MSAL dasar. Untuk informasi selengkapnya, lihat penyimpanan sementara token pada pustaka klien Microsoft Azure Identity.

Strategi penggunaan kembali kredensial yang direkomendasikan berbeda dengan jenis aplikasi .NET.

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);
});

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);
}

Memahami kapan masa pakai token dan logika penyimpanan sementara diperlukan

Jika Anda menggunakan kredensial pustaka Azure Identity di luar konteks pustaka klien Azure SDK yang bergantung pada Azure Core, Anda bertanggung jawab untuk mengelola masa pakai token dan perilaku penembolokan di aplikasi Anda.

Properti RefreshOn pada AccessToken, yang memberikan petunjuk kepada konsumen tentang kapan dapat mencoba penyegaran token, akan secara otomatis digunakan oleh pustaka klien Azure SDK yang bergantung pada pustaka Azure Core untuk memperbarui token. Untuk penggunaan langsung kredensial pustaka Azure Identity yang mendukung penyimpanan token, cache MSAL yang mendasar secara otomatis diperbarui secara proaktif saat waktu RefreshOn terjadi. Desain ini memungkinkan kode klien untuk memanggil GetToken setiap kali token diperlukan dan mempercayakan pembaruan kepada pustaka.

Untuk hanya memanggil GetToken jika perlu, amati tanggal RefreshOn dan secara proaktif mencoba menyegarkan token setelah waktu tersebut. Implementasi khusus terserah pelanggan.

Memahami strategi coba lagi identitas terkelola

Pustaka Azure Identity untuk .NET memungkinkan Anda mengautentikasi melalui identitas terkelola dengan ManagedIdentityCredential. Cara Anda menggunakan ManagedIdentityCredential berdampak pada strategi coba lagi yang diterapkan. Saat digunakan melalui:

• DefaultAzureCredential, tidak ada percobaan ulang yang dicoba ketika upaya akuisisi token awal gagal atau kehabisan waktu setelah durasi singkat. Ini adalah opsi yang paling tidak tangguh karena dioptimalkan untuk "gagal cepat" guna mencapai efisiensi dalam proses pengembangan.
• Pendekatan lain, seperti ChainedTokenCredential atau ManagedIdentityCredential secara langsung:

  • Interval waktu antara percobaan ulang dimulai pada 0,8 detik, dan maksimum lima percobaan ulang dicoba, secara default. Opsi ini dioptimalkan untuk resiliensi tetapi dapat memperkenalkan penundaan yang berpotensi tidak diinginkan dalam siklus internal pengembangan.

  • Untuk mengubah salah satu pengaturan ulang otomatis, gunakan properti Retry pada ManagedIdentityCredentialOptions. Misalnya, coba lagi maksimal tiga kali, dengan interval awal 0,5 detik:

    ManagedIdentityCredentialOptions miCredentialOptions = new(
            ManagedIdentityId.FromUserAssignedClientId(clientId)
        )
        {
            Retry =
            {
                MaxRetries = 3,
                Delay = TimeSpan.FromSeconds(0.5),
            }
        };
        ChainedTokenCredential tokenChain = new(
            new ManagedIdentityCredential(miCredentialOptions),
            new VisualStudioCredential()
        );
    

Untuk informasi selengkapnya tentang mengatur kebijakan percobaan ulang kustom, lihat mengatur kebijakan percobaan ulang kustom.