Vous avez une application monopage (SPA) qui appelle une API web Azure App Service (API A). L'API A doit appeler une API en aval (API B) au nom de l'utilisateur connecté et appliquer les autorisations de l'utilisateur dans l'API B. L'API B expose déjà des étendues (scopes) dans son enregistrement d'application. Vous devez préserver l'identité de l'utilisateur lors de l'appel de l'API B et éviter d'accorder à l'API A des autorisations d'application étendues. Quelles sont les deux actions à effectuer ?

Pour préserver l'identité de l'utilisateur et appliquer les autorisations dans l'API B, l'API A doit obtenir un jeton pour l'API B au nom de l'utilisateur. La première action correcte est d'utiliser MSAL dans l'API A pour échanger le jeton utilisateur entrant contre un jeton en aval pour l'API B en utilisant AcquireTokenOnBehalfOf. Cela permet à l'API A d'agir au nom de l'utilisateur. La deuxième action correcte est de configurer Azure AD en ajoutant l'API B comme autorisation déléguée à l'enregistrement d'application de l'API A et d'accorder le consentement administrateur pour les étendues requises. Cela autorise l'API A à demander des jetons pour l'API B au nom de l'utilisateur. L'option d'utiliser le flux d'informations d'identification du client est incorrecte car elle ferait appel à l'API B en utilisant l'identité de l'API A, et non celle de l'utilisateur, ce qui ne préserverait pas l'identité de l'utilisateur ni n'appliquerait les autorisations de l'utilisateur dans l'API B. L'option de configurer l'API B pour exiger des rôles d'application au lieu d'étendues est incorrecte car les rôles d'application sont généralement utilisés pour les autorisations au niveau de l'application, et non pour les autorisations déléguées au nom de l'utilisateur, et cela n'éliminerait pas le besoin d'acquérir un jeton pour l'API B.