Hai una single-page application (SPA) che chiama un'Azure App Service Web API (API A). L'API A deve chiamare un'API downstream (API B) per conto dell'utente autenticato e applicare le autorizzazioni dell'utente nell'API B. L'API B espone già degli scope nella sua registrazione dell'app. Devi preservare l'identità dell'utente quando chiami l'API B ed evitare di concedere all'API A ampie autorizzazioni applicative. Quali due azioni dovresti eseguire?

Per preservare l'identità dell'utente e applicare le autorizzazioni nell'API B, l'API A deve agire per conto dell'utente. Questo si ottiene tramite il flusso On-Behalf-Of (OBO). L'API A deve scambiare il token utente ricevuto dalla SPA con un nuovo token per l'API B. La prima azione corretta descrive questo processo: usare MSAL e AcquireTokenOnBehalfOf con il token utente come UserAssertion. Affinché l'API A possa richiedere un token per l'API B per conto dell'utente, deve avere l'autorizzazione per farlo. Questo significa che l'API A deve dichiarare nel suo manifesto di registrazione dell'app in Azure AD che richiede i permessi (scope) esposti dall'API B. La seconda azione corretta garantisce ciò: aggiungere l'API B come permesso delegato alla registrazione dell'app dell'API A e concedere il consenso dell'amministratore per tali scope. L'opzione di usare il flusso di credenziali client non è corretta perché l'API A chiamerebbe l'API B con la propria identità, perdendo l'identità dell'utente originale e le sue autorizzazioni. L'opzione di configurare l'API B per ruoli applicativi invece di scope non è corretta perché gli scope sono il meccanismo standard per delegare autorizzazioni specifiche in Azure AD e l'API B espone già scope. Inoltre, richiederebbe comunque un'acquisizione di token per conto dell'utente se si vogliono mantenere le autorizzazioni utente.