Tutoriel : transmettre l’authentification de App Service via l’API back-end à Microsoft Graph

Découvrez comment créer et configurer un service App Service principal pour accepter les informations d’identification utilisateur d’une application frontale, puis échanger ces informations d’identification pour un service Azure en aval. Cela permet à un utilisateur de se connecter à un service d’application front-end, de transmettre ses informations d’identification à un service App Service principal, puis d’accéder à un service Azure avec la même identité.

Dans ce tutoriel, vous allez apprendre à :

Configurer l’application d’authentification back-end pour fournir un jeton étendu au service Azure en aval
Utilisez du code JavaScript pour échanger le jeton d’accès de l’utilisateur connecté pour un nouveau jeton pour le service en aval.
Utilisez du code JavaScript pour accéder au service en aval.

Conditions préalables

Suivez le tutoriel précédent, Accédez à Microsoft Graph à partir d’une application JavaScript sécurisée en tant qu’utilisateur, avant de commencer ce didacticiel, mais ne supprimez pas les ressources à la fin du didacticiel. Ce tutoriel part du principe que vous disposez des deux services d’application et de leurs applications d’authentification correspondantes.

Le tutoriel précédent a utilisé Azure Cloud Shell comme interpréteur de commandes pour Azure CLI. Ce didacticiel poursuit cette utilisation.

Architecture

Le tutoriel montre comment transmettre les informations d’identification de l’utilisateur fournies par l’application frontale à l’application back-end, puis à un service Azure. Dans ce tutoriel, le service en aval est Microsoft Graph. Les informations d’identification de l’utilisateur sont utilisées pour obtenir leur profil à partir de Microsoft Graph.

Image architecturale d’App Service se connectant à Microsoft Graph au nom d’un utilisateur connecté.

Flux d’authentification pour qu’un utilisateur obtienne des informations Microsoft Graph dans cette architecture :

Tutoriel précédent a couvert :

Connectez-vous à un service d’application frontal configuré pour utiliser Active Directory comme fournisseur d’identité.
Le service d’application frontal transmet le jeton de l’utilisateur au service d’application principal.
L’application back-end est sécurisée pour permettre au serveur frontal d’effectuer une requête d’API. Le jeton d’accès de l’utilisateur a une audience pour l’API back-end et l’étendue de user_impersonation.
L’inscription de l’application back-end a déjà le Microsoft Graph avec l’étendue User.Read. Cette opération est ajoutée par défaut à toutes les inscriptions d’application.
À la fin du tutoriel précédent, un faux profil a été retourné à l’application frontend, car Graph n’était pas connecté.

Ce tutoriel étend l’architecture :

Accordez le consentement de l’administrateur pour contourner l’écran de consentement de l’utilisateur pour l’application principale.
Modifiez le code de l’application pour convertir le jeton d’accès envoyé de l’application frontale en jeton d’accès avec l’autorisation requise pour Microsoft Graph.
Fournissez du code pour avoir un jeton d’échange d’application back-end pour le nouveau jeton avec l’étendue du service Azure en aval, comme Microsoft Graph.
Fournissez du code pour que l’application back-end utilise un nouveau jeton pour accéder au service en aval en tant qu’utilisateur d’authentification actuel.
Redéployez l’application back-end avec az webapp up.
À la fin de ce didacticiel, un profil réel est retourné à l’application frontale, car Graph est connecté.

Ce tutoriel ne fait pas les choses suivantes :

Modifiez l’application frontale à partir du didacticiel précédent.
Modifiez l’autorisation d’étendue de l’application d’authentification principale, car User.Read elle est ajoutée par défaut à toutes les applications d’authentification.

Dans le tutoriel précédent, lorsque l’utilisateur s’est connecté à l’application frontale, une fenêtre contextuelle s’affiche demandant le consentement de l’utilisateur.

Dans ce tutoriel, pour lire le profil utilisateur à partir de Microsoft Graph, l’application back-end doit échanger le jeton d’accès de l’utilisateur connecté pour un nouveau jeton d’accès avec les autorisations requises pour Microsoft Graph. Étant donné que l’utilisateur n’est pas directement connecté à l’application back-end, il ne peut pas accéder à l’écran de consentement de manière interactive. Vous devez résoudre ce problème en configurant l'inscription de l'application back-end dans Microsoft Entra ID pour accorder le consentement de l'administrateur. Il s’agit généralement d’une modification de paramètre effectuée par un administrateur Active Directory.

Ouvrez le Portail Azure et recherchez votre recherche pour l’App Service principal.
Recherchez la section Paramètres -> Authentification .
Sélectionnez le fournisseur d’identité pour accéder à l’application d’authentification.
Dans l’application d’authentification, sélectionnez Gérer -> Autorisations d’API.
Sélectionnez Accorder le consentement administrateur pour l’annuaire par défaut.
Dans la fenêtre contextuelle, sélectionnez Oui pour confirmer le consentement.
Vérifiez que la colonne État indique Accordé pour le répertoire par défaut. Avec ce paramètre, l’application back-end n’est plus nécessaire pour afficher un écran de consentement à l’utilisateur connecté et peut demander directement un jeton d’accès. L’utilisateur connecté a accès au User.Read paramètre d’étendue, car il s’agit de l’étendue par défaut avec laquelle l’inscription de l’application est créée.

2. Installer les packages npm

Dans le tutoriel précédent, l’application back-end n’a pas besoin de packages npm pour l’authentification, car la seule authentification a été fournie en configurant le fournisseur d’identité dans le portail Azure. Dans ce tutoriel, le jeton d’accès de l’utilisateur connecté pour l’API de back-end doit être échangé contre un jeton d’accès avec Microsoft Graph dans son champ d'application. Cet échange est effectué avec deux bibliothèques, car il n’utilise plus l’authentification App Service, mais Microsoft Entra ID et MSAL.js directement.

@azure/MSAL-node - jeton d’échange
@microsoft/microsoft-graph-client - se connecter à Microsoft Graph

Ouvrez Azure Cloud Shell et passez à l’application principale de l’exemple d’annuaire :
```
cd js-e2e-web-app-easy-auth-app-to-app/backend
```
Installez le package npm Azure MSAL :
```
npm install @azure/msal-node
```

Installez le package npm Microsoft Graph :

npm install @microsoft/microsoft-graph-client

3. Ajouter du code pour échanger le jeton actuel pour le jeton Microsoft Graph

Le code source pour effectuer cette étape est fourni pour vous. Procédez comme suit pour l’inclure.

Ouvrez le fichier ./src/server.js .
Décommentez la dépendance suivante en haut du fichier :
```
import { getGraphProfile } from './with-graph/graph';
```
Dans le même fichier, décommentez la variable graphProfile :
```
let graphProfile={};
```

Dans le même fichier, supprimez les marques de commentaire getGraphProfile suivantes dans l’itinéraire get-profile pour obtenir le profil à partir de Microsoft Graph :

// where did the profile come from
profileFromGraph=true;

// get the profile from Microsoft Graph
graphProfile = await getGraphProfile(accessToken);

// log the profile for debugging
console.log(`profile: ${JSON.stringify(graphProfile)}`);

Enregistrez les modifications : Ctrl + s.

Redéployez l’application back-end :

az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name>

4. Inspecter le code back-end afin d'échanger le jeton d’API back-end contre le jeton Microsoft Graph

Pour échanger le jeton d’audience de l’API back-end contre un jeton Microsoft Graph, l’application principale doit rechercher l’ID de locataire et l’utiliser dans le cadre de l’objet de configuration MSAL.js. Étant donné que l’application back-end configurée avec Microsoft comme fournisseur d’identité, l’ID de locataire et plusieurs autres valeurs requises se trouvent déjà dans les paramètres de l’application App Service.

Le code suivant est déjà fourni dans l’exemple d’application. Vous devez comprendre pourquoi il est là et comment il fonctionne pour que vous puissiez appliquer ce travail à d’autres applications que vous créez qui ont besoin de cette même fonctionnalité.

Inspecter le code pour obtenir l’ID de locataire

Ouvrez le fichier ./backend/src/with-graph/auth.js .

Passez en revue la fonction getTenantId().

export function getTenantId() {

    const openIdIssuer = process.env.WEBSITE_AUTH_OPENID_ISSUER;
    const backendAppTenantId = openIdIssuer.replace(/https:\/\/sts\.windows\.net\/(.{1,36})\/v2\.0/gm, '$1');

    return backendAppTenantId;
}

Cette fonction obtient l’ID de locataire actuel de la variable d’environnement WEBSITE_AUTH_OPENID_ISSUER . L’ID est extrait de la variable avec une expression régulière.

Inspecter le code pour obtenir le jeton Graph à l’aide de MSAL.js

Toujours dans le fichier ./backend/src/with-graph/auth.js, passez en revue la fonction getGraphToken().

Générez l’objet de configuration MSAL.js, utilisez la configuration MSAL pour créer le clientCredentialAuthority. Configurez la requête on-behalf-off. Utilisez ensuite l’acquireTokenOnBehalfOf pour échanger le jeton d’accès de l’API principale pour un jeton d’accès Graph.

// ./backend/src/auth.js
// Exchange current bearerToken for Graph API token
// Env vars were set by App Service
export async function getGraphToken(backEndAccessToken) {

    const config = {
        // MSAL configuration
        auth: {
            // the backend's authentication CLIENT ID 
            clientId: process.env.WEBSITE_AUTH_CLIENT_ID,
            // the backend's authentication CLIENT SECRET 
            clientSecret: process.env.MICROSOFT_PROVIDER_AUTHENTICATION_SECRET,
            // OAuth 2.0 authorization endpoint (v2)
            // should be: https://login.microsoftonline.com/BACKEND-TENANT-ID
            authority: `https://login.microsoftonline.com/${getTenantId()}`
        },
        // used for debugging
        system: {
            loggerOptions: {
                loggerCallback(loglevel, message, containsPii) {
                    console.log(message);
                },
                piiLoggingEnabled: true,
                logLevel: MSAL.LogLevel.Verbose,
            }
        }
    };

    const clientCredentialAuthority = new MSAL.ConfidentialClientApplication(config);

    const oboRequest = {
        oboAssertion: backEndAccessToken,
        // this scope must already exist on the backend authentication app registration 
        // and visible in resources.azure.com backend app auth config
        scopes: ["https://graph.microsoft.com/.default"]
    }

    // This example has App service validate token in runtime
    // from headers that can't be set externally

    // If you aren't using App service's authentication, 
    // you must validate your access token yourself
    // before calling this code
    try {
        const { accessToken } = await clientCredentialAuthority.acquireTokenOnBehalfOf(oboRequest);
        return accessToken;
    } catch (error) {
        console.log(`getGraphToken:error.type = ${error.type}  ${error.message}`);
    }
}

5. Inspecter le code principal pour accéder à Microsoft Graph avec le nouveau jeton

Pour accéder à Microsoft Graph en tant qu’utilisateur connecté à l’application frontale, les modifications sont les suivantes :

Configuration de l’inscription de l’application Active Directory avec une autorisation d’API sur le service en aval, Microsoft Graph, avec l’étendue nécessaire de User.Read.
Accordez le consentement de l’administrateur pour contourner l’écran de consentement de l’utilisateur pour l’application principale.
Modifiez le code de l’application pour convertir le jeton d’accès envoyé de l’application frontale en jeton d’accès avec l’autorisation requise pour le service en aval, Microsoft Graph.

Maintenant que le code a le jeton correct pour Microsoft Graph, utilisez-le pour créer un client dans Microsoft Graph, puis obtenez le profil de l’utilisateur.

Ouvrez le ./backend/src/graph.js

Dans la getGraphProfile() fonction, obtenez le jeton, puis le client authentifié à partir du jeton, puis obtenez le profil.

// 
import graph from "@microsoft/microsoft-graph-client";
import { getGraphToken } from "./auth.js";

// Create client from token with Graph API scope
export function getAuthenticatedClient(accessToken) {
    const client = graph.Client.init({
        authProvider: (done) => {
            done(null, accessToken);
        }
    });

    return client;
}
export async function getGraphProfile(accessToken) {
    // exchange current backend token for token with 
    // graph api scope
    const graphToken = await getGraphToken(accessToken);

    // use graph token to get Graph client
    const graphClient = getAuthenticatedClient(graphToken);

    // get profile of user
    const profile = await graphClient
        .api('/me')
        .get();

    return profile;
}

6. Tester vos modifications

Utilisez le site web front-end dans un navigateur. Vous devrez peut-être actualiser votre jeton s’il a expiré.
Sélectionnez Get user's profile. Cela transmet votre authentification dans le jeton du porteur à l’application back-end.
Le back-end répond avec le profil Microsoft Graph réel pour votre compte.

7. Nettoyer

Au cours des étapes précédentes, vous avez créé des ressources Azure au sein d’un groupe de ressources.

Supprimez le groupe de ressources en exécutant la commande suivante dans Cloud Shell. L’exécution de cette commande peut prendre une minute.
```
az group delete --name myAuthResourceGroup
```
Utilisez l’ID client des applications d’authentification, que vous avez précédemment trouvé et noté dans les sections Enable authentication and authorization des applications back-end et front-end.

Supprimez les inscriptions d’applications pour les applications front-end et back-end.

# delete app - do this for both frontend and backend client ids
az ad app delete --id <client-id>

Questions fréquentes

J’ai eu une erreur `80049217`, qu’est-ce que cela signifie ?

Cette erreur signifie CompactToken parsing failed with error code: 80049217que le service d’application principal n’est pas autorisé à retourner le jeton Microsoft Graph. Cette erreur est due au fait que l’inscription de l’application ne dispose pas de l’autorisation User.Read .

J’ai eu une erreur `AADSTS65001`, qu’est-ce que cela signifie ?

Cette erreur signifie AADSTS65001: The user or administrator has not consented to use the application with ID \<backend-authentication-id>. Send an interactive authorization request for this user and resourceque l’application d’authentification principale n’a pas été configurée pour le consentement administrateur. Étant donné que l’erreur s’affiche dans le journal de l’application back-end, l’application frontale ne peut pas indiquer à l’utilisateur pourquoi il n’a pas vu son profil dans l’application frontale.

Comment me connecter à un autre service Azure en aval en tant qu’utilisateur ?

Ce tutoriel montre une application API authentifiée auprès de Microsoft Graph. Toutefois, les mêmes étapes générales peuvent être appliquées pour accéder à n’importe quel service Azure pour le compte de l’utilisateur.

Aucune modification apportée à l’application frontale. Seules les modifications apportées à l’inscription de l’application d’authentification du back-end et au code source de l’application back-end.
Échangez le jeton de l’utilisateur étendu à l’API back-end contre un jeton au service en aval auquel vous souhaitez accéder.
Utilisez le jeton dans le Kit de développement logiciel (SDK) du service en aval pour créer le client.
Utilisez le client en aval pour accéder aux fonctionnalités du service.

Étapes suivantes

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-06-09