Łańcuchy poświadczeń w bibliotece klienta tożsamości platformy Azure dla języka JavaScript

Biblioteka klienta tożsamości platformy Azure udostępnia poświadczenia , będące klasami publicznymi implementującymi interfejs TokenCredential biblioteki Azure Core. Poświadczenie reprezentuje odrębny przepływ uwierzytelniania na potrzeby uzyskiwania tokenu dostępu z identyfikatora Entra firmy Microsoft. Te poświadczenia można wybrać pojedynczo lub połączyć w łańcuch, aby utworzyć uporządkowaną sekwencję mechanizmów uwierzytelniania, które mają być wykorzystywane.

• Indywidualne poświadczenia zapewniają szybkość i pewność. Jeśli próba uwierzytelnienia się nie powiedzie, wiesz, że poświadczenie nie zostało uwierzytelnione.
• Łańcuchy zapewniają rozwiązania zapasowe. Gdy poświadczenie nie uda się uwierzytelnić, zostanie podjęta próba następnego poświadczenia w łańcuchu.

Projektowanie przepływów uwierzytelniania

W przypadku korzystania z bibliotek klienckich zestawu Azure SDK pierwszym krokiem jest uwierzytelnianie na platformie Azure. Istnieje wiele opcji uwierzytelniania do rozważenia, takich jak narzędzia i środowiska programistyczne IDE używane w zespole deweloperów, przepływy pracy automatyzacji, takie jak testowanie oraz ciągła integracja/ciągłe wdrażanie (CI/CD), a także platformy hostingu, takie jak Azure App Service.

Wybierz spośród następujących typowych postępów przepływu uwierzytelniania:

• Użyj DefaultAzureCredential dla zespołów , których deweloperzy używają różnych środowisk IDE i interfejsów wiersza poleceń do uwierzytelniania w usłudze Azure. Pozwala to na największą elastyczność. Ta elastyczność jest zapewniana kosztem wydajności w celu zweryfikowania poświadczeń w łańcuchu, dopóki nie powiedzie się.

  • Przejście z jednego poświadczenia na drugie jest wybierane w Twoim imieniu w zależności od wykrytego środowiska.
  • Aby określić, które poświadczenie zostało wybrane, włącz debugowanie.

• Użyj ChainedTokenCredential dla zespołów , które mają ścisły i ograniczony wybór narzędzi. Na przykład wszystkie uwierzytelniają się i używają tego samego IDE lub CLI. Dzięki temu zespół może wybrać dokładne poświadczenia i kolejność, która nadal zapewnia elastyczność, ale przy obniżonym koszcie wydajności.

  • Wybierasz ścieżkę rezerwową poświadczenia do poświadczenia niezależnie od środowiska, w którym jest uruchamiana.
  • Aby określić, które poświadczenie zostało wybrane, włącz debugowanie.

• Dla zespołów z potwierdzonymi poświadczeniami we wszystkich środowiskach, instrukcja sterowania przepływem, taka jak if/else, pozwala określić, które poświadczenie zostało wybrane w każdym środowisku.

  • Nie ma powrotu do innego typu poświadczeń.
  • Nie musisz debugować, aby określić, które poświadczenie zostało wybrane, ponieważ zostało ono określone.

Jak działa poświadczenie łańcuchowe

Podczas wykonywania, ciąg poświadczeń próbuje uwierzytelnić się przy użyciu pierwszego poświadczenia w sekwencji. Jeśli to poświadczenie nie może uzyskać tokenu dostępu, zostanie podjęta próba następnego poświadczenia w sekwencji itd., dopóki token dostępu nie zostanie pomyślnie uzyskany. Poniższy diagram sekwencji ilustruje to zachowanie:

Użyj opcji DefaultAzureCredential, aby uzyskać elastyczność

DefaultAzureCredential jest ukierunkowanym na określone zastosowania, wstępnie skonfigurowanym łańcuchem poświadczeń. Jest ona przeznaczona do obsługi wielu środowisk wraz z najczęściej używanymi przepływami uwierzytelniania i narzędziami deweloperskich. W postaci graficznej podstawowy łańcuch wygląda następująco:

Kolejność, w której DefaultAzureCredential próbuje użyć danych uwierzytelniających, jest następująca.

Zamówienie	Poświadczenie	Opis
1	środowiska	Odczytuje kolekcję zmiennych środowiskowych w celu określenia, czy dla aplikacji skonfigurowano głównego użytkownika usługi (użytkownika aplikacji). Jeśli tak, DefaultAzureCredential używa tych wartości do uwierzytelniania aplikacji na platformie Azure. Ta metoda jest najczęściej używana w środowiskach serwera, ale może być również używana podczas opracowywania lokalnie.
2	Tożsamość zasobów roboczych	Jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną tożsamością zadania, uwierzytelnij konto tej usługi.
3	tożsamość zarządzana	Jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną tożsamością zarządzaną, uwierzytelnij aplikację na platformie Azure przy użyciu tej tożsamości zarządzanej.
4	Interfejs wiersza polecenia platformy Azure	Jeśli deweloper uwierzytelnił się na platformie Azure za pomocą polecenia az login Azure CLI, uwierzytelnij aplikację na platformie Azure za pomocą tego samego konta.
5	Azure PowerShell	Jeśli deweloper uwierzytelnił się w Azure przy użyciu polecenia cmdlet Connect-AzAccount programu Azure PowerShell, uwierzytelnij aplikację w Azure przy użyciu tego samego konta.
6	interfejsu wiersza polecenia dewelopera platformy Azure	Jeśli deweloper zalogował się do platformy Azure za pomocą polecenia azd auth login narzędzia Azure Developer CLI, zaloguj się za pomocą tego samego konta.

W najprostszej formie można użyć bez parametrów wersji DefaultAzureCredential w następujący sposób:

import { DefaultAzureCredential } from "@azure/identity";
import { BlobServiceClient } from "@azure/storage-blob";

// Acquire a credential object
const credential = new DefaultAzureCredential();

const blobServiceClient = new BlobServiceClient(
    "https://<my_account_name>.blob.core.windows.net",
    credential
);

Poświadczenia są globalne dla środowiska

DefaultAzureCredential sprawdza obecność pewnych zmiennych środowiskowych . Możliwe, że ktoś może dodać lub zmodyfikować te zmienne środowiskowe na poziomie systemu na maszynie hosta. Te zmiany są stosowane globalnie i w związku z tym zmieniają zachowanie DefaultAzureCredential w czasie wykonywania w dowolnej aplikacji uruchomionej na tym komputerze.

Jak dostosować DefaultAzureCredential

Aby wykluczyć wszystkie Developer tool lub Deployed service poświadczenia, ustaw odpowiednio zmienną środowiskową AZURE_TOKEN_CREDENTIALS na prod lub dev. Gdy jest używana wartość prod , podstawowy łańcuch poświadczeń wygląda następująco:

W przypadku użycia wartości dev łańcuch wygląda następująco:

Ważne

Zmienna środowiskowa AZURE_TOKEN_CREDENTIALS jest obsługiwana w pakietach w wersji @azure/identity 4.10.0 lub nowszej.

Użyj elementu ChainedTokenCredential w celu uzyskania szczegółowości

ChainedTokenCredential to pusty łańcuch, do którego dodajesz poświadczenia zgodnie z potrzebami aplikacji. Na przykład poniższy przykład dodaje wystąpienie ManagedIdentityCredential, a następnie wystąpienie AzureCliCredential.

import { 
    ChainedTokenCredential, 
    ManagedIdentityCredential, 
    AzureCliCredential 
} from "@azure/identity";

const credential = new ChainedTokenCredential(
    new ManagedIdentityCredential({ clientId: "<YOUR_CLIENT_ID>" }),
    new AzureCliCredential()
);

Powyższy przykładowy kod tworzy dostosowany łańcuch poświadczeń składający się z dwóch poświadczeń. Najpierw wybierany jest wariant zarządzanej tożsamości przypisanej przez użytkownika ManagedIdentityCredential, a następnie, w razie potrzeby, AzureCliCredential. W formie graficznej łańcuch wygląda następująco:

Napiwek

Aby uzyskać lepszą wydajność, zoptymalizuj kolejność poświadczeń dla środowiska produkcyjnego . Poświadczenia przeznaczone do użytku w lokalnym środowisku programistycznym powinny zostać dodane na końcu.

Debugowanie poświadczeń łańcuchowych

Aby debugować łańcuch poświadczeń, włącz logowanie SDK Azure.

Więcej zasobów

• Interfejs wiersza polecenia platformy Azure