API JavaScript d’authentification

Article
11/12/2024

Le front-end Fabric offre une API Javascript pour les charges de travail Fabric afin d’acquérir un jeton pour son application dans Microsoft Entra ID. Cet article décrit cette API.

API

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

L’API retourne un objet AccessToken qui contient le jeton lui-même et une date d’expiration pour le jeton.

Pour appeler l’API dans l’exemple front-end, créez un exemple d’élément, puis faites défiler vers le bas, puis sélectionnez Naviguer vers la page d'authentification. De là, vous pouvez sélectionner Obtenir un jeton d’accès pour recevoir un jeton en retour.

Capture d’écran montrant le code d’authentification.

Consentements

Pour comprendre pourquoi les consentements sont requis, consultez le consentement de l’utilisateur et de l’administrateur dans Microsoft Entra ID .

Remarque

Les consentements sont requis pour que CRUD/les tâches fonctionnent et obtiennent des jetons entre les clients.

Comment fonctionnent les consentements dans les charges de travail Fabric ?

Pour accorder un consentement pour une application spécifique, Fabric FE crée une instance MSAL configurée avec l’ID d’application de la charge de travail et demande un jeton pour les étendues fournies (additionalScopesToConsent - voir AcquireAccessTokenParams).

Lorsque vous demandez un jeton avec l’application de charge de travail pour une étendue spécifique, l’ID Microsoft Entra affiche un consentement contextuel en cas d’absence, puis redirige la fenêtre contextuelle vers l’URI de redirection configuré dans l’application.

En règle générale, l’URI de redirection se trouve dans le même domaine que la page qui a demandé le jeton, afin que la page puisse accéder à la fenêtre contextuelle et la fermer.

Dans notre cas, ce n’est pas dans le même domaine, car Fabric demande le jeton et l’URI de redirection de la charge de travail n’est pas dans le domaine Fabric. Par conséquent, lorsque la boîte de dialogue de consentement s’ouvre, elle doit être fermée manuellement après la redirection. Nous n’utilisons pas le code retourné dans redirectUri. Par conséquent, nous venons de le fermer automatiquement (lorsque Microsoft Entra ID redirige la fenêtre contextuelle vers l’URI de redirection qu’il ferme simplement).

Vous pouvez voir le code/configuration de l’URI de redirection dans le fichier index.ts.

Voici un exemple de fenêtre contextuelle de consentement pour notre application « mon application de charge de travail » et ses dépendances (stockage et Power BI) que nous avons configurées lors de la configuration de l’authentification :

Capture d’écran de la boîte de dialogue Autorisations requises.

Une autre façon d’accorder des consentements dans le client d’accueil (facultatif)

Pour obtenir un consentement dans le locataire d'origine de l'application, vous pouvez demander à l'administrateur de votre locataire d'accorder un consentement pour l'ensemble du locataire à l'aide d'une URL au format suivant (insérez votre propre identifiant de locataire et l'ID client) :

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

AcquireAccessTokenParams

Lorsque vous appelez l’API acquireAccessToken JS, nous pouvons fournir trois paramètres :

additionalScopesToConsent : autres étendues pour demander un consentement, par exemple des scénarios de re-consentement.
claimsForConditionalAccessPolicy : revendications retournées à partir de Microsoft Entra ID lorsque les flux OBO échouent, par exemple, OBO nécessite l’authentification multifacteur.
promptFullConsent : invite une fenêtre de consentement complet des dépendances statiques de l’application des charges de travail.

additionalScopesToConsent

Si le front-end de charge de travail demande un jeton à utiliser pour les appels au back-end de charge de travail, ce paramètre doit être null. Il arrive que le back-end de charge de travail ne réussisse pas à effectuer l’authentification OBO sur le jeton reçu en raison d’une erreur de consentement manquant. Dans ce cas, le back-end de charge de travail doit propager l’erreur au front-end de charge de travail, et fournir ce paramètre.

claimsForConditionalAccessPolicy

Ce paramètre est utilisé lors des échecs OBO dans la charge de travail BE en raison d’une stratégie d’accès conditionnel configurée sur le client.

Les échecs OBO dus à des politiques d'accès conditionnel renvoient une chaîne de caractères appelée « revendications ». Cette chaîne doit être envoyée à la charge de travail FE où le FE doit demander un jeton et passer la revendication en tant que claimsForConditionalAccessPolicy. Pour plus d’informations, consultez Gestion de l’authentification multifacteur (MFA), de l’accès conditionnel et du consentement incrémentiel.

Reportez-vous à l’utilisation d’AuthenticationService AddBearerClaimToResponse dans l’exemple BE pour voir des exemples de réponses lorsque les opérations OBO échouent en raison du consentement manquant ou des stratégies d’accès conditionnel.

Pour en savoir plus sur ces additionalScopesToConsent et claimsForConditionalAccessPolicy et voir des exemples d’utilisation, consultez Instructions d’authentification de charge de travail et présentation approfondie.

promptFullConsent

Lorsqu’il est passé à true, un consentement complet des dépendances statiques sera donné à l’utilisateur, qu’il ait ou non donné son consentement précédemment. Un exemple d’utilisation de ce paramètre est l’ajout d’un bouton à l’expérience utilisateur, qui permet à l’utilisateur d’octroyer son consentement complet à la charge de travail.

Partager via