Interfejs API języka JavaScript uwierzytelniania

Fronton sieci szkieletowej oferuje interfejs API języka JavaScript dla obciążeń sieci szkieletowej w celu uzyskania tokenu dla aplikacji w usłudze Microsoft Entra ID. W tym artykule opisano ten interfejs API.

interfejs API

acquireAccessToken(params: AcquireAccessTokenParams): Promise<AccessToken>;  
export interface AcquireAccessTokenParams {
    additionalScopesToConsent?: string[];  
    claimsForConditionalAccessPolicy?: string;
    promptFullConsent?: boolean;
}

Interfejs API zwraca obiekt AccessToken zawierający sam token i datę wygaśnięcia tokenu.

Aby wywołać interfejs API w przykładzie frontonu, utwórz przykładowy element, a następnie przewiń w dół i wybierz pozycję Przejdź do strony Uwierzytelnianie. W tym miejscu możesz wybrać pozycję Pobierz token dostępu, aby odebrać token z powrotem.

Zgody

Aby dowiedzieć się, dlaczego wymagane są zgody, przejdź do sekcji User and admin consent in Microsoft Entra ID (Identyfikator firmy Microsoft).

Uwaga

Zgody są wymagane, aby operacje CRUD/Zadania działały i uzyskiwały tokeny między dzierżawami.

Jak działają zgody w obciążeniach sieci szkieletowej?

Aby udzielić zgody dla określonej aplikacji, usługa Fabric FE tworzy wystąpienie biblioteki MSAL skonfigurowane przy użyciu identyfikatora aplikacji obciążenia i prosi o token dla podanych zakresów (additionalScopesToConsent — zobacz AcquireAccessTokenParams).

Podczas monitowania o token z aplikacją obciążenia dla określonego zakresu identyfikator Entra firmy Microsoft wyświetla wyskakujące wyrażenie zgody na wypadek jego braku, a następnie przekierowuje okno podręczne do identyfikatora URI przekierowania skonfigurowanego w aplikacji.

Zazwyczaj identyfikator URI przekierowania znajduje się w tej samej domenie co strona, która zażądała tokenu, więc strona może uzyskać dostęp do wyskakującego okienka i zamknąć go.

W naszym przypadku nie znajduje się w tej samej domenie, ponieważ sieć szkieletowa żąda tokenu, a identyfikator URI przekierowania obciążenia nie znajduje się w domenie sieci szkieletowej. Dlatego po otwarciu okna dialogowego zgody należy go zamknąć ręcznie po przekierowaniu. Nie używamy kodu zwróconego w identyfikatorze redirectUri, dlatego po prostu automatycznie je tworzymy (gdy identyfikator Entra firmy Microsoft przekierowuje wyskakujące okienko do identyfikatora URI przekierowania po prostu zamyka).

Kod/konfiguracja identyfikatora URI przekierowania można wyświetlić w pliku index.ts .

Oto przykład wyskakującego okienka zgody dla aplikacji "moja aplikacja obciążenia" i jej zależności (magazyn i usługa Power BI), które skonfigurowaliśmy podczas przechodzenia przez konfigurację uwierzytelniania:

Inny sposób udzielania zgody w dzierżawie macierzystej (opcjonalnie)

Aby uzyskać zgodę w dzierżawie głównej aplikacji, możesz poprosić administratora dzierżawy o wyrażenie zgody dla całej dzierżawy przy użyciu adresu URL w następującym formacie (wstawić własny identyfikator dzierżawy i identyfikator klienta):

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}

AcquireAccessTokenParams

Podczas wywoływania interfejsu API acquireAccessToken JS możemy podać trzy parametry:

• additionalScopesToConsent: inne zakresy, w których należy poprosić o zgodę, na przykład scenariusze ponownego rozpoznania.
• claimsForConditionalAccessPolicy: oświadczenia zwrócone z identyfikatora Entra firmy Microsoft, gdy przepływy OBO kończą się niepowodzeniem, na przykład OBO wymaga uwierzytelniania wieloskładnikowego.
• promptFullConsent: monituje o pełne okno zgody dla statycznych zależności aplikacji obciążeń.

additionalScopesToConsent

Jeśli fronton obciążenia prosi o token do użycia dla wywołań zaplecza obciążenia, ten parametr powinien mieć wartość null. Zaplecze obciążenia może nie wykonać OBO na tokenie odebranym z powodu braku zgody, w takim przypadku zaplecze obciążenia będzie musiało propagować błąd do frontonu obciążenia i podać ten parametr.

claimsForConditionalAccessPolicy

Ten parametr jest używany w przypadku awarii OBO w obciążeniu BE ze względu na niektóre zasady dostępu warunkowego, które zostały skonfigurowane w dzierżawie.

Błędy OBO z powodu zasad dostępu warunkowego zwracają ciąg o nazwie "claims". Ten ciąg powinien być wysyłany do fe obciążenia, gdzie FE powinien poprosić o token i przekazać oświadczenie jako oświadczeniaForConditionalAccessPolicy. Aby uzyskać więcej informacji, zobacz Obsługa uwierzytelniania wieloskładnikowego (MFA), dostępu warunkowego i zgody przyrostowej.

Zapoznaj się z tematem AuthenticationService AddBearerClaimToResponse usage in the BE sample (Użycie elementu AuthenticationService AddBearerClaimToResponse w przykładzie BE), aby zobaczyć przykłady odpowiedzi, gdy operacje OBO kończą się niepowodzeniem z powodu braku zgody lub zasad dostępu warunkowego.

Aby dowiedzieć się więcej na temat tych dodatkowych elementówScopesToConsent i claimsForConditionalAccessPolicy, zobacz przykłady użycia, zobacz Wskazówki dotyczące uwierzytelniania obciążeń i szczegółowe omówienie.

promptFullConsent

Po przekazaniu wartości true pełna zgoda statycznych zależności będzie pojawiać się dla użytkownika niezależnie od tego, czy wcześniej udzieliła zgody, czy nie. Przykładem użycia tego parametru jest dodanie przycisku do środowiska użytkownika, w którym użytkownik może użyć go do udzielenia pełnej zgody na obciążenie.