Sie haben eine Single-Page-Anwendung (SPA), die eine Azure App Service Web API (API A) aufruft. API A muss im Namen des angemeldeten Benutzers eine Downstream-API (API B) aufrufen und die Berechtigungen des Benutzers in API B durchsetzen. API B macht bereits Scopes in ihrer App-Registrierung verfügbar. Sie müssen die Identität des Benutzers beim Aufruf von API B beibehalten und vermeiden, API A umfassende Anwendungsberechtigungen zu erteilen. Welche zwei Aktionen sollten Sie durchführen?

Um die Identität des Benutzers beizubehalten und die Berechtigungen in API B durchzusetzen, ist der On-Behalf-Of-Flow erforderlich. Die erste korrekte Aktion besteht darin, in API A MSAL zu verwenden, um das eingehende Benutzertoken gegen ein Downstream-Token für API B auszutauschen. Dies geschieht mit AcquireTokenOnBehalfOf, wobei das eingehende Bearer-Token als UserAssertion dient. Dieses neue Token wird dann an API B gesendet. Die zweite korrekte Aktion ist, in Azure AD die API B als delegierte Berechtigung zur App-Registrierung von API A hinzuzufügen und die Administratorzustimmung für die benötigten Scopes zu erteilen. Dies erlaubt API A, im Namen des Benutzers auf API B zuzugreifen. Die Option, den Client-Anmeldeinformationsfluss zu verwenden, ist falsch, da dies die Identität des Benutzers nicht beibehält, sondern API A mit ihrer eigenen Anwendungsidentität aufrufen würde. Die Konfiguration von API B zur Verwendung von Anwendungsrollen anstelle von Scopes ist ebenfalls falsch, da dies das Problem der Token-Akquisition für Downstream-APIs nicht löst und die Scopes von API B bereits verfügbar sind.