Jak uwierzytelniać aplikacje JavaScript w usługach platformy Azure przy użyciu zestawu Azure SDK dla języka JavaScript

Jeśli aplikacja musi uzyskać dostęp do zasobu platformy Azure (takiego jak magazyn, magazyn kluczy lub usługi Cognitive Services), aplikacja musi zostać uwierzytelniona na platformie Azure. Dotyczy to wszystkich aplikacji, zarówno wdrożonych na platformie Azure, wdrożonych lokalnie, jak i w ramach programowania na lokalnej stacji roboczej dewelopera. W tym artykule opisano zalecane podejścia do uwierzytelniania aplikacji na platformie Azure podczas korzystania z zestawu Azure SDK dla języka JavaScript.

Zalecanym procesem jest użycie uwierzytelniania opartego na tokenach, a nie parametry połączenia lub kluczy podczas uwierzytelniania w zasobach platformy Azure. Zestaw Azure SDK zapewnia uwierzytelnianie oparte na tokenach i umożliwia aplikacjom bezproblemowe uwierzytelnianie w zasobach platformy Azure niezależnie od tego, czy aplikacja jest w środowisku lokalnym, wdrożona na platformie Azure, czy wdrożona na serwerze lokalnym.

Określony typ uwierzytelniania opartego na tokenach, którego aplikacja powinna używać do uwierzytelniania w zasobach platformy Azure, zależy od tego, gdzie aplikacja jest uruchomiona i jest pokazana na poniższym diagramie.

Środowisko Uwierzytelnianie
Lokalnych Gdy deweloper uruchamia aplikację podczas programowania lokalnego — aplikacja może uwierzytelniać się na platformie Azure przy użyciu jednostki usługi aplikacji na potrzeby programowania lokalnego lub przy użyciu poświadczeń platformy Azure dewelopera. Każda z tych opcji została omówiona bardziej szczegółowo w sekcji uwierzytelniania podczas programowania lokalnego.
Azure Gdy aplikacja jest hostowana na platformie Azure — aplikacja powinna uwierzytelniać się w zasobach platformy Azure przy użyciu tożsamości zarządzanej. Ta opcja została omówiona bardziej szczegółowo poniżej w sekcji uwierzytelnianie w środowiskach serwera.
Lokalne Gdy aplikacja jest hostowana i wdrożona lokalnie — aplikacja powinna uwierzytelniać się w zasobach platformy Azure przy użyciu jednostki usługi aplikacji. Ta opcja została omówiona bardziej szczegółowo poniżej w sekcji uwierzytelnianie w środowiskach serwera.

Diagram przedstawiający zalecane strategie uwierzytelniania oparte na tokenach dla aplikacji w zależności od tego, gdzie jest uruchomiona.

Zalety uwierzytelniania opartego na tokenach

Podczas tworzenia aplikacji na platformie Azure zdecydowanie zaleca się uwierzytelnianie oparte na tokenach w przypadku wpisów tajnych (parametry połączenia lub kluczy). Uwierzytelnianie oparte na tokenach jest dostarczane z wartością DefaultAzureCredential.

Uwierzytelnianie oparte na tokenach Wpisy tajne (parametry połączenia i klucze)
Zasada najniższych uprawnień, ustanów określone uprawnienia wymagane przez aplikację w zasobie platformy Azure. Klucz lub parametry połączenia przyznaje pełne prawa do zasobu platformy Azure.
Nie ma wpisu tajnego aplikacji do przechowywania. Należy przechowywać i obracać wpisy tajne w ustawieniach aplikacji lub zmiennej środowiskowej.
Zestaw AZURE Identity SDK zarządza tokenami za kulisami. Dzięki temu użycie uwierzytelniania opartego na tokenach jest łatwe w użyciu jako parametry połączenia. Wpisy tajne nie są zarządzane.

Korzystanie z parametry połączenia powinno być ograniczone do początkowego sprawdzania koncepcji lub prototypów programistycznych, które nie uzyskują dostępu do danych produkcyjnych ani poufnych. W przeciwnym razie klasy uwierzytelniania oparte na tokenach dostępne w zestawie Azure SDK powinny być zawsze preferowane podczas uwierzytelniania w zasobach platformy Azure.

Użyj następującego zestawu SDK:

Wartość domyślnaAzureCredential

Domyślna metoda zestawu Azure SDKAzureCredential umożliwia aplikacjom korzystanie z różnych metod uwierzytelniania w zależności od środowiska, w których są uruchamiane. Dzięki temu aplikacje mogą być wdrażane w środowiskach lokalnych, testowych i produkcyjnych bez wprowadzania zmian w kodzie. Należy skonfigurować odpowiednią metodę uwierzytelniania dla każdego środowiska i DefaultAzureCredential automatycznie wykrywać i używać tej metody uwierzytelniania. Użycie funkcji jest preferowane w przypadku ręcznego DefaultAzureCredential kodowania logiki warunkowej lub flag funkcji do używania różnych metod uwierzytelniania w różnych środowiskach.

Szczegółowe informacje o korzystaniu z klasy DefaultAzureCredential zostały omówione w dalszej części tego artykułu w sekcji Use DefaultAzureCredential in an application (Użyj wartości domyślnejAzureCredential w aplikacji).

Uwierzytelnianie w środowiskach serwera

W przypadku hostowania w środowisku serwera każda aplikacja powinna mieć przypisaną unikatową tożsamość aplikacji na środowisko. Na platformie Azure tożsamość aplikacji jest reprezentowana przez jednostkę usługi, specjalny typ podmiotu zabezpieczeń przeznaczonego do identyfikowania i uwierzytelniania aplikacji na platformie Azure. Typ jednostki usługi używanej dla aplikacji zależy od tego, gdzie aplikacja jest uruchomiona.

Uwierzytelnianie podczas programowania lokalnego

Gdy aplikacja jest uruchamiana na stacji roboczej dewelopera podczas programowania lokalnego, środowisko lokalne musi nadal uwierzytelniać się w dowolnych usługach platformy Azure używanych przez aplikację.

Używanie wartości defaultAzureCredential w aplikacji

Aby użyć wartości DefaultAzureCredential w aplikacji JavaScript, dodaj pakiet @azure/identity do aplikacji.

npm install @azure/identity

Następnie poniższy przykład kodu pokazuje, jak utworzyć DefaultAzureCredential wystąpienie obiektu i użyć go z klasą klienta zestawu Azure SDK, w tym przypadku obiekt BlobServiceClient używany do uzyskiwania dostępu do usługi Blob Storage.

// connect-with-default-azure-credential.js
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 Automatycznie wykryje mechanizm uwierzytelniania skonfigurowany dla aplikacji i uzyska niezbędne tokeny do uwierzytelniania aplikacji na platformie Azure. Jeśli aplikacja korzysta z więcej niż jednego klienta zestawu SDK, ten sam obiekt poświadczeń może być używany z każdym obiektem klienta zestawu SDK.

Sekwencja wybierania metod uwierzytelniania w przypadku używania wartości DefaultAzureCredential

DefaultAzureCredential Wewnętrznie implementuje łańcuch wybierania dostawców poświadczeń na potrzeby uwierzytelniania aplikacji w zasobach platformy Azure. Każdy dostawca poświadczeń może wykryć, czy poświadczenia tego typu są skonfigurowane dla aplikacji. DefaultAzureCredential sekwencyjnie sprawdza każdego dostawcę w kolejności i używa poświadczeń od pierwszego dostawcy, który ma skonfigurowane poświadczenia.

Jeśli skonfigurowano więcej niż jedno poświadczenie, kolejność znajdowania poświadczeń za pośrednictwem łańcucha jest ważna.

Kolejność, w której DefaultAzureCredential szuka poświadczeń dla języka JavaScript, jest wyświetlana na diagramie i w poniższej tabeli.

Diagram przedstawiający sekwencję, w której ustawienie DefaultAzureCredential sprawdza, jakie źródło uwierzytelniania jest skonfigurowane dla aplikacji.

Istnieją dwie ścieżki:

  • Wdrożona usługa (platforma Azure lub środowisko lokalne): sekwencja rozpoczyna się od zmiennych środowiskowych, a następnie tożsamości zarządzanej, a następnie pozostałych lokalizacji dla poświadczeń (Visual Studio Code, interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell).
  • Środowisko lokalne dewelopera: łańcuch lokalnej stacji roboczej dewelopera rozpoczyna się od zalogowanego użytkownika platformy Azure programu Visual Studio Code, wyświetlanego na dolnym pasku środowiska IDE, a następnie przechodzi do interfejsu wiersza polecenia platformy Azure, a następnie do programu Azure PowerShell. Ważne jest, aby zrozumieć, czy skonfigurowano lokalne zmienne środowiskowe dla całego środowiska lub środowiska wirtualnego projektu (np. z doTENV), te zmienne zastąpią łańcuch programu Visual Studio Code —> interfejs wiersza polecenia platformy Azure —> łańcuch programu PowerShell, ponieważ są to pierwsze poświadczenia zaewidencjonowane w łańcuchu.
Typ poświadczeń opis
Środowisko DefaultAzureCredential odczytuje zestaw zmiennych środowiskowych w celu określenia, czy dla aplikacji została ustawiona jednostka usługi aplikacji (użytkownik aplikacji). Jeśli tak, DefaultAzureCredential użyj 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.
Tożsamość zarządzana Jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną tożsamością zarządzaną, DefaultAzureCredential uwierzytelni aplikację na platformie Azure przy użyciu tej tożsamości zarządzanej. Uwierzytelnianie przy użyciu tożsamości zarządzanej zostało omówione w sekcji Uwierzytelnianie w środowiskach serwera w tym dokumencie.

Ta metoda jest dostępna tylko wtedy, gdy aplikacja jest hostowana na platformie Azure przy użyciu usługi obsługującej tożsamość zarządzaną.
Visual Studio Code Jeśli deweloper uwierzytelnił się na platformie Azure przy użyciu wtyczki konta platformy Azure programu Visual Studio Code, DefaultAzureCredential uwierzytelni aplikację na platformie Azure przy użyciu tego samego konta.
Interfejs wiersza polecenia platformy Azure Jeśli deweloper uwierzytelnił się na platformie Azure przy użyciu az login polecenia w interfejsie wiersza polecenia platformy Azure, DefaultAzureCredential uwierzytelni aplikację na platformie Azure przy użyciu tego samego konta.
Azure PowerShell Jeśli deweloper uwierzytelnił się na platformie Azure przy użyciu Connect-AzAccount polecenia cmdlet z programu Azure PowerShell, DefaultAzureCredential uwierzytelni aplikację na platformie Azure przy użyciu tego samego konta.
Interakcyjny Jeśli to ustawienie jest włączone, ustawienie DefaultAzureCredential będzie interaktywnie uwierzytelniać dewelopera za pośrednictwem domyślnej przeglądarki bieżącego systemu. Domyślnie ta opcja jest wyłączona.