Inicjowanie poufnych aplikacji klienckich w środowisku MSAL Node

W tym artykule pokazano, jak zainicjować obiekt ConfidentialClientApplication w bibliotece MSAL Node. Dowiesz się, jak bezpiecznie używać kluczy tajnych i certyfikatów oraz jak skonfigurować urząd certyfikacji.

Wymagania wstępne

Przed zainicjowaniem aplikacji należy najpierw zarejestrować ją w centrum administracyjne Microsoft Entra, ustanawiając relację zaufania między aplikacją a Platforma tożsamości Microsoft.

Po zarejestrowaniu aplikacji potrzebne będą niektóre lub wszystkie poniższe wartości, które można znaleźć w centrum administracyjne Microsoft Entra.

Wartość Wymagane Description
Identyfikator aplikacji (klienta) Wymagane Unikatowy identyfikator GUID, który jednoznacznie identyfikuje Twoją aplikację na platformie tożsamości firmy Microsoft.
Władza Optional Adres URL dostawcy tożsamości (element instance) oraz grupa odbiorców logowania dla aplikacji. Instancja i odbiorcy logowania, po połączeniu, tworzą autorytet.
Identyfikator katalogu (klienta) Optional Określ identyfikator katalogu (dzierżawy), jeśli tworzysz aplikację biznesową wyłącznie dla Twojej organizacji, często nazywaną aplikacją jednodzierżawną.
URI przekierowania Optional Jeśli tworzysz aplikację internetową, element redirectUri określa, gdzie dostawca tożsamości (platforma tożsamości firmy Microsoft) powinien zwrócić wydane przez niego tokeny zabezpieczające.

Inicjowanie ConfidentialClientApplication obiektu

Aby używać biblioteki MSAL Node, należy utworzyć instancję obiektu ConfidentialClient.

Bezpieczne używanie wpisów tajnych i certyfikatów

Wpisy tajne nigdy nie powinny być zakodowane na stałe. Pakiet npm dotenv może służyć do przechowywania wpisów tajnych lub certyfikatów w pliku env (znajdującym się w katalogu głównym projektu), który powinien zostać uwzględniony w pliku gitignore , aby zapobiec przypadkowym przekazaniu wpisów tajnych.

Certyfikaty można również odczytywać z plików za pośrednictwem modułu fs środowiska NodeJS. Jednak nigdy nie powinny być przechowywane w katalogu projektu. Aplikacje produkcyjne powinny pobierać certyfikaty z usługi Azure KeyVault lub innych bezpiecznych magazynów kluczy.

Aby uzyskać więcej informacji, zobacz certyfikaty i wpisy tajne .

Zobacz przykład MSAL: auth-code-with-certs

import * as msal from "@azure/msal-node";
import "dotenv/config"; // process.env now has the values defined in a .env file

const clientAssertionCallback = async (config) => {
    // network request that uses config.clientId and (optionally) config.tokenEndpoint
    const result = await Promise.resolve(
        "network request which gets assertion"
    );
    return result;
};

const clientConfig = {
    auth: {
        clientId: "your_client_id",
        authority: "your_authority",
        clientSecret: process.env.clientSecret, // OR
        clientCertificate: {
            thumbprintSha256: process.env.thumbprint,
            privateKey: process.env.privateKey,
        }, // OR
        clientAssertion: clientAssertionCallback, // or a predetermined clientAssertion string
    },
};
const cca = new msal.ConfidentialClientApplication(clientConfig);

Zapoznaj się z typowymi problemami podczas importowania certyfikatów.

Podstawowe informacje o konfiguracji

Konfiguracja opcji dla węzła ma common parametrów i specific parametrów dla każdego przepływu uwierzytelniania.

  • clientId jest wymagany do zainicjowania publicznej aplikacji klienta
  • authority wartość domyślna, https://login.microsoftonline.com/common/ jeśli użytkownik nie ustawi go podczas konfiguracji
  • Poświadczenia klienta są obowiązkowe dla poufnych klientów. Poświadczenie klienta może być następujące:
    • clientSecret jest ciągiem tajnym generowanym w rejestracji aplikacji.
    • clientCertificate jest certyfikatem ustawionym podczas rejestracji aplikacji. thumbprintSha256 to odcisk certyfikatu X.509 SHA-256, a privateKey to klucz prywatny zakodowany w formacie PEM. x5c jest opcjonalnym łańcuchem certyfikatów X.509 używanym w scenariuszach uwierzytelniania nazwy podmiotu/wystawcy.
    • clientAssertion jest obiektem ClientAssertion zawierającym ciąg asercji lub funkcję wywołania zwrotnego, która zwraca ciąg potwierdzenia używany przez aplikację podczas żądania tokenu, a także typ asercji (urn:ietf:params:oauth:client-assertion-type:jwt-bearer). Funkcja zwrotna jest wywoływana za każdym razem, gdy biblioteka MSAL musi uzyskać token od emitenta tokenu. Deweloperzy aplikacji powinni zazwyczaj używać wywołania zwrotnego, ponieważ asercji wygasają i należy utworzyć nowe asercji. Deweloperzy aplikacji są odpowiedzialni za okres istnienia asercji. Użyj tego mechanizmu, aby uzyskać tokeny dla interfejsu API niższego poziomu przy użyciu poświadczenia tożsamości federacyjnej.

Aby uzyskać więcej opcji konfiguracji , zobacz Konfiguracja w węźle MSAL.

Skonfiguruj autorytet

Domyślnie biblioteka MSAL jest skonfigurowana do używania dzierżawy common, która jest używana w aplikacjach wielodzierżawowych oraz aplikacjach dopuszczających konta osobiste (nie B2C).

    authority: 'https://login.microsoftonline.com/common/'

Jeśli aplikacja jest przeznaczona dla jednej dzierżawy, musisz podać adres autoryzacji z identyfikatorem swojej dzierżawy, jak pokazano poniżej:

    authority: 'https://login.microsoftonline.com/{your_tenant_id}'

Dalsze kroki

Uzyskiwanie tokenów w MSAL Node

  • Last updated on