Masz aplikację jednostronicową (SPA), która wywołuje internetowy interfejs API usługi Azure App Service (API A). API A musi wywoływać podrzędny interfejs API (API B) w imieniu zalogowanego użytkownika i wymuszać uprawnienia użytkownika w API B. API B udostępnia już zakresy w swojej rejestracji aplikacji. Musisz zachować tożsamość użytkownika podczas wywoływania API B i unikać nadawania API A szerokich uprawnień aplikacji. Które dwie czynności należy wykonać?

Aby zachować tożsamość użytkownika i wymusić jego uprawnienia, API A musi uzyskać token dla API B w imieniu użytkownika. Wymaga to użycia przepływu On-Behalf-Of (OBO). Pierwszy krok to konfiguracja w Azure AD: należy dodać API B jako uprawnienie delegowane do rejestracji aplikacji API A. To informuje Azure AD, że API A ma pozwolenie na żądanie tokenów dla API B w imieniu użytkownika. Udzielenie zgody administratora jest konieczne, aby API A mogło żądać tych uprawnień bez indywidualnej zgody każdego użytkownika. Drugi krok to implementacja w kodzie API A: MSAL (Microsoft Authentication Library) jest używana do wymiany przychodzącego tokenu użytkownika (otrzymanego ze SPA) na nowy token przeznaczony dla API B. Metoda AcquireTokenOnBehalfOf przyjmuje przychodzący token jako UserAssertion i zwraca nowy token, który API A może następnie wysłać do API B. API B będzie wtedy w stanie zweryfikować ten token i zastosować uprawnienia użytkownika. Opcja z przepływem client credentials jest nieprawidłowa, ponieważ używa tożsamości aplikacji API A, a nie tożsamości użytkownika, co narusza wymaganie zachowania tożsamości użytkownika. Konfigurowanie API B do używania ról aplikacji zamiast zakresów nie rozwiązuje problemu przekazywania tożsamości użytkownika i uzyskiwania tokenu dla API B.