Application web qui appelle des API web : Configuration de code

Article
10/25/2023

Comme illustré dans le scénario Application web qui connecte des utilisateurs, l'application web utilise le flux du code d'autorisation OAuth 2.0 pour connecter l'utilisateur. Ce flux comporte deux étapes :

Demande d’un code d’autorisation. Cette partie délègue à la plateforme d'identités Microsoft un dialogue privé avec l'utilisateur. Pendant ce dialogue, l'utilisateur se connecte et consent à utiliser des API web. Lorsque le dialogue privé se termine correctement, l'application web reçoit un code d'autorisation sur son URI de redirection.
Demande d’un jeton d’accès pour l’API en échange du code d’autorisation.

Les scénarios Application web qui connecte des utilisateurs ne couvraient que la première étape. Vous allez ici apprendre à modifier votre application web afin qu'elle appelle les API web en plus de connecter les utilisateurs.

Bibliothèques Microsoft prenant en charge les applications web

Les bibliothèques Microsoft suivantes prennent en charge les applications web :

Langage/framework	Projet sur GitHub	Package	Bien démarrer démarré	Connexion des utilisateurs	Accès aux API web	Disponibilité générale ou Préversion publique¹
.NET	MSAL.NET	Microsoft.Identity.Client	—			GA
.NET	Microsoft.IdentityModel	Microsoft.IdentityModel	—	²	²	GA
ASP.NET Core	ASP.NET Core	Microsoft.AspNetCore.Authentication	Démarrage rapide			GA
ASP.NET Core	Microsoft.Identity.Web	Microsoft.Identity.Web	Démarrage rapide			GA
Java	MSAL4J	msal4j	Démarrage rapide			GA
Spring	spring-cloud-azure-starter-active-directory	spring-cloud-azure-starter-active-directory	Didacticiel			GA
Node.js	MSAL Node	msal-node	Démarrage rapide			GA
Python	MSAL Python	msal				GA
Python	identity	identity	Démarrage rapide			--

⁽¹⁾Les termes du contrat de licence universelle pour les services en ligne s’appliquent aux bibliothèques en préversion publique.

⁽²⁾ La bibliothèque Microsoft.IdentityModelvalide uniquement les jetons. Elle ne peut pas demander de jetons d’ID ni de jetons d’accès.

Sélectionnez l'onglet correspondant à la plateforme qui vous intéresse :

Secrets clients ou certificats clients

Dans la mesure où votre application web appelle désormais une API web en aval, fournissez un secret client ou un certificat client dans le fichier appsettings.json. Vous pouvez également ajouter une section spécifiant ce qui suit :

URL de l’API web en aval ;
étendues requises pour appeler l’API.

Dans l’exemple suivant, la section GraphBeta spécifie ces paramètres.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "[Enter_the_Application_Id_Here]",
    "TenantId": "common",

   // To call an API
   "ClientCredentials": [
    {
      "SourceType": "ClientSecret",
      "ClientSecret":"[Enter_the_Client_Secret_Here]"
    }
  ]
 },
 "GraphBeta": {
    "BaseUrl": "https://graph.microsoft.com/beta",
    "Scopes": ["user.read"]
    }
}

Remarque

Vous pouvez proposer une collection d’informations d’identification client, y compris une solution sans informations d’identification comme la fédération des identités de charge de travail pour Azure Kubernetes. Les versions antérieures de Microsoft.Identity.Web exprimaient la clé secrète client dans une propriété unique « ClientSecret » au lieu de « ClientCredentials ». Ce principe est toujours pris en charge à des fins de compatibilité descendante, mais vous ne pouvez pas utiliser à la fois la propriété « ClientSecret » et la collection « ClientCredentials ».

À la place d’un secret client, vous pouvez fournir un certificat client. L’extrait de code suivant montre l’utilisation d’un certificat stocké dans Azure Key Vault.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "[Enter_the_Application_Id_Here]",
    "TenantId": "common",

   // To call an API
   "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://msidentitywebsamples.vault.azure.net",
        "KeyVaultCertificateName": "MicrosoftIdentitySamplesCert"
      }
   ]
  },
  "GraphBeta": {
    "BaseUrl": "https://graph.microsoft.com/beta",
    "Scopes": ["user.read"]
  }
}

Avertissement

Si vous oubliez de remplacer Scopes par un groupe, lorsque vous essayez d’utiliser IDownstreamApi les étendues apparaîtront nulles et IDownstreamApi tentera un appel anonyme (non authentifié) à l’API en aval, ce qui entraînera 401/unauthenticated.

Microsoft.Identity.Web offre plusieurs façons de décrire les certificats, que ce soit en définissant une configuration ou en écrivant du code. Pour plus d’informations, consultez Microsoft.Identity.Web - Using certificates sur GitHub.

Startup.cs

Votre application web doit acquérir un jeton pour l’API en aval. Vous le spécifiez en ajoutant la ligne .EnableTokenAcquisitionToCallDownstreamApi() après .AddMicrosoftIdentityWebApp(Configuration). Cette ligne expose le service IAuthorizationHeaderProvider que vous pouvez utiliser dans vos actions de contrôleur et de page. Toutefois, comme vous le verrez dans les deux options suivantes, il existe un moyen plus simple. Vous devez également choisir une implémentation de cache de jeton, par exemple .AddInMemoryTokenCaches(), dans Startup.cs :

using Microsoft.Identity.Web;

public class Startup
{
  // ...
  public void ConfigureServices(IServiceCollection services)
  {
  // ...
  services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
          .AddMicrosoftIdentityWebApp(Configuration, "AzureAd")
            .EnableTokenAcquisitionToCallDownstreamApi(new string[]{"user.read" })
            .AddInMemoryTokenCaches();
   // ...
  }
  // ...
}

Les étendues transmises à EnableTokenAcquisitionToCallDownstreamApi sont facultatives, et permettent à votre application web de demander les étendues et le consentement de l’utilisateur à ces étendues lors de la connexion. Si vous ne spécifiez pas les étendues, Microsoft.Identity.Web active une expérience de consentement incrémentielle.

Microsoft.Identity.Web offre deux mécanismes pour appeler une API web à partir d’une application web sans que vous ayez à acquérir un jeton. L’option que vous choisissez varie selon que vous souhaitez appeler Microsoft Graph ou une autre API.

Option 1 : Appeler Microsoft Graph

Si vous souhaitez appeler Microsoft Graph, Microsoft.Identity.Web vous permet d’utiliser directement le GraphServiceClient (exposé par le Kit de développement logiciel (SDK) Microsoft Graph) dans vos actions d’API. Pour exposer Microsoft Graph :

Ajoutez le package NuGet Microsoft.Identity.Web.GraphServiceClient à votre projet.

Ajoutez .AddMicrosoftGraph() après .EnableTokenAcquisitionToCallDownstreamApi() dans le fichier Startup.cs. .AddMicrosoftGraph() a plusieurs remplacements. En utilisant le remplacement qui prend une section de configuration en tant que paramètre, le code devient :

using Microsoft.Identity.Web;

public class Startup
{
  // ...
  public void ConfigureServices(IServiceCollection services)
  {
  // ...
  services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
          .AddMicrosoftIdentityWebApp(Configuration, "AzureAd")
            .EnableTokenAcquisitionToCallDownstreamApi(new string[]{"user.read" })
               .AddMicrosoftGraph(Configuration.GetSection("GraphBeta"))
            .AddInMemoryTokenCaches();
   // ...
  }
  // ...
}

Option n°2 : Appeler une API web en aval autre que Microsoft Graph

Si vous souhaitez appeler une autre API que Microsoft Graph, Microsoft.Identity.Web vous permet d’utiliser directement l’interface IDownstreamApi dans vos actions d’API. Pour utiliser cette interface :

Ajoutez le package NuGet Microsoft.Identity.Web.DownstreamApi au projet.

Ajoutez .AddDownstreamApi() après .EnableTokenAcquisitionToCallDownstreamApi() dans le fichier Startup.cs. .AddDownstreamApi() a deux arguments et est illustré dans l’extrait de code suivant :

Nom d’un service (API), qui est utilisé dans vos actions de contrôleur pour référencer la configuration correspondante
Une section de configuration représentant les paramètres utilisés pour appeler l’API web en aval.

using Microsoft.Identity.Web;

public class Startup
{
  // ...
  public void ConfigureServices(IServiceCollection services)
  {
  // ...
  services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
          .AddMicrosoftIdentityWebApp(Configuration, "AzureAd")
            .EnableTokenAcquisitionToCallDownstreamApi(new string[]{"user.read" })
               .AddDownstreamApi("MyApi", Configuration.GetSection("GraphBeta"))
            .AddInMemoryTokenCaches();
   // ...
  }
  // ...
}

Résumé

Comme avec des API web, vous pouvez choisir diverses implémentations de cache de jeton. Pour plus d’informations, consultez Microsoft.Identity.Web - Token cache serialization sur GitHub.

L’illustration suivante montre les différentes possibilités de Microsoft.Identity.Web et leur effet sur le fichier Startup.cs :

Diagramme de bloc montrant des options de configuration de service dans le point de départ CS pour appeler une API web et spécifier une implémentation de cache de jeton

Notes

Pour bien comprendre les exemples de code présentés ici, vous devez maîtriser les notions de base d'ASP.NET Core, en particulier l'injection de dépendances et le modèle options.

Secrets clients ou certificats clients

URL de l’API web en aval ;
étendues requises pour appeler l’API.

Dans l’exemple suivant, la section GraphBeta spécifie ces paramètres.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "[Enter_the_Application_Id_Here]",
    "TenantId": "common",

   // To call an API
   "ClientCredentials": [
    {
      "SourceType": "ClientSecret",
      "ClientSecret":"[Enter_the_Client_Secret_Here]"
    }
  ]
 },
 "GraphBeta": {
    "BaseUrl": "https://graph.microsoft.com/beta",
    "Scopes": ["user.read"]
    }
}

Remarque

À la place d’un secret client, vous pouvez fournir un certificat client. L’extrait de code suivant montre l’utilisation d’un certificat stocké dans Azure Key Vault.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "[Enter_the_Application_Id_Here]",
    "TenantId": "common",

   // To call an API
   "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://msidentitywebsamples.vault.azure.net",
        "KeyVaultCertificateName": "MicrosoftIdentitySamplesCert"
      }
   ]
  },
  "GraphBeta": {
    "BaseUrl": "https://graph.microsoft.com/beta",
    "Scopes": ["user.read"]
  }
}

Avertissement

Startup.Auth.cs

Votre application web doit acquérir un jeton pour l’API en aval. Microsoft.Identity.Web propose deux mécanismes pour appeler une API web à partir d’une application web. L’option que vous choisissez varie selon que vous souhaitez appeler Microsoft Graph ou une autre API.

Option 1 : Appeler Microsoft Graph

Ajoutez le package NuGet Microsoft.Identity.Web.GraphServiceClient à votre projet.
Ajoutez .AddMicrosoftGraph() à la collection de services dans le fichier Startup.Auth.cs. .AddMicrosoftGraph() a plusieurs remplacements. En utilisant le remplacement qui prend une section de configuration en tant que paramètre, le code devient :

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Identity.Client;
using Microsoft.Identity.Web;
using Microsoft.Identity.Web.OWIN;
using Microsoft.Identity.Web.TokenCacheProviders.InMemory;
using Microsoft.IdentityModel.Validators;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.Cookies;
using Owin;

namespace WebApp
{
    public partial class Startup
    {
        public void ConfigureAuth(IAppBuilder app)
        {
            app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

            app.UseCookieAuthentication(new CookieAuthenticationOptions());

            // Get an TokenAcquirerFactory specialized for OWIN
            OwinTokenAcquirerFactory owinTokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance<OwinTokenAcquirerFactory>();

            // Configure the web app.
            app.AddMicrosoftIdentityWebApp(owinTokenAcquirerFactory,
                                          updateOptions: options => {});

            // Add the services you need.
            owinTokenAcquirerFactory.Services
                .Configure<ConfidentialClientApplicationOptions>(options => 
                      { options.RedirectUri = "https://localhost:44326/"; })
                .AddMicrosoftGraph()
                .AddInMemoryTokenCaches();
            owinTokenAcquirerFactory.Build();
        }
    }
}

Option n°2 : Appeler une API web en aval autre que Microsoft Graph

Ajoutez le package NuGet Microsoft.Identity.Web.DownstreamApi au projet.
Ajoutez .AddDownstreamApi() après .EnableTokenAcquisitionToCallDownstreamApi() dans le fichier Startup.cs. .AddDownstreamApi() possède deux arguments :
- Le nom d’un service (api), que vous utilisez dans vos actions de contrôleur pour référencer la configuration correspondante
- Une section de configuration représentant les paramètres utilisés pour appeler l’API web en aval.

Voici le code :

  using Microsoft.Extensions.DependencyInjection;
  using Microsoft.Identity.Client;
  using Microsoft.Identity.Web;
  using Microsoft.Identity.Web.OWIN;
  using Microsoft.Identity.Web.TokenCacheProviders.InMemory;
  using Microsoft.IdentityModel.Validators;
  using Microsoft.Owin.Security;
  using Microsoft.Owin.Security.Cookies;
  using Owin;

  namespace WebApp
  {
      public partial class Startup
      {
          public void ConfigureAuth(IAppBuilder app)
          {
              app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

              app.UseCookieAuthentication(new CookieAuthenticationOptions());

              // Get a TokenAcquirerFactory specialized for OWIN.
              OwinTokenAcquirerFactory owinTokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance<OwinTokenAcquirerFactory>();

              // Configure the web app.
              app.AddMicrosoftIdentityWebApp(owinTokenAcquirerFactory,
                                            updateOptions: options => {});

              // Add the services you need.
              owinTokenAcquirerFactory.Services
                  .Configure<ConfidentialClientApplicationOptions>(options => 
                        { options.RedirectUri = "https://localhost:44326/"; })
                  .AddDownstreamApi("Graph", owinTokenAcquirerFactory.Configuration.GetSection("GraphBeta"))
                  .AddInMemoryTokenCaches();
              owinTokenAcquirerFactory.Build();
          }
      }
  }

Résumé

Vous pouvez choisir diverses implémentations de cache de jeton. Pour plus d’informations, consultez Microsoft.Identity.Web - Token cache serialization sur GitHub.

L’illustration suivante montre les différentes possibilités de Microsoft.Identity.Web et leur effet sur le fichier Startup.cs :

Diagramme de bloc montrant des options de configuration de service dans le point de départ CS pour appeler une API web et spécifier une implémentation de cache de jeton

Notes

Pour bien comprendre les exemples de code présentés ici, vous devez maîtriser les notions de base d'ASP.NET Core, en particulier l'injection de dépendances et le modèle options.

Les exemples de code présentés dans cet article et le suivant proviennent de l'exemple d'application web ASP.NET. Vous pouvez vous référer à cet exemple pour obtenir tous les détails d'implémentation.

Les exemples de code présentés dans cet article et le suivant sont extraits de l’application web Node.js & Express.js qui appelle Microsoft Graph, un exemple d’application web qui utilise MSAL Node.

L’exemple permet actuellement à MSAL Node de produire l’URL du code d’autorisation et gère la navigation vers le point de terminaison d’autorisation de la plateforme d’identités Microsoft. En voici l'illustration ci-dessous :

/**
 * Prepares the auth code request parameters and initiates the first leg of auth code flow
 * @param req: Express request object
 * @param res: Express response object
 * @param next: Express next function
 * @param authCodeUrlRequestParams: parameters for requesting an auth code url
 * @param authCodeRequestParams: parameters for requesting tokens using auth code
 */
redirectToAuthCodeUrl(authCodeUrlRequestParams, authCodeRequestParams, msalInstance) {
    return async (req, res, next) => {
        // Generate PKCE Codes before starting the authorization flow
        const { verifier, challenge } = await this.cryptoProvider.generatePkceCodes();

        // Set generated PKCE codes and method as session vars
        req.session.pkceCodes = {
            challengeMethod: 'S256',
            verifier: verifier,
            challenge: challenge,
        };

        /**
         * By manipulating the request objects below before each request, we can obtain
         * auth artifacts with desired claims. For more information, visit:
         * https://azuread.github.io/microsoft-authentication-library-for-js/ref/modules/_azure_msal_node.html#authorizationurlrequest
         * https://azuread.github.io/microsoft-authentication-library-for-js/ref/modules/_azure_msal_node.html#authorizationcoderequest
         **/
        req.session.authCodeUrlRequest = {
            ...authCodeUrlRequestParams,
            responseMode: msal.ResponseMode.FORM_POST, // recommended for confidential clients
            codeChallenge: req.session.pkceCodes.challenge,
            codeChallengeMethod: req.session.pkceCodes.challengeMethod,
        };

        req.session.authCodeRequest = {
            ...authCodeRequestParams,
            code: '',
        };

        try {
            const authCodeUrlResponse = await msalInstance.getAuthCodeUrl(req.session.authCodeUrlRequest);
            res.redirect(authCodeUrlResponse);
        } catch (error) {
            next(error);
        }
    };
}

Code qui échange le code d’autorisation

Microsoft.Identity.Web simplifie votre code en définissant les paramètres corrects d’OpenID Connect, en s’abonnant à l’événement code reçu et en échangeant le code. Aucun code supplémentaire n'est nécessaire pour accepter le code d'autorisation. Pour plus d’informations sur le fonctionnement, consultez Code source de Microsoft.Identity.Web.

La méthode handleRedirect dans la classe AuthProvider traite le code d’autorisation reçu de Microsoft Entra ID. En voici l'illustration ci-dessous :

handleRedirect(options = {}) {
    return async (req, res, next) => {
        if (!req.body || !req.body.state) {
            return next(new Error('Error: response not found'));
        }

        const authCodeRequest = {
            ...req.session.authCodeRequest,
            code: req.body.code,
            codeVerifier: req.session.pkceCodes.verifier,
        };

        try {
            const msalInstance = this.getMsalInstance(this.msalConfig);

            if (req.session.tokenCache) {
                msalInstance.getTokenCache().deserialize(req.session.tokenCache);
            }

            const tokenResponse = await msalInstance.acquireTokenByCode(authCodeRequest, req.body);

            req.session.tokenCache = msalInstance.getTokenCache().serialize();
            req.session.idToken = tokenResponse.idToken;
            req.session.account = tokenResponse.account;
            req.session.isAuthenticated = true;

            const state = JSON.parse(this.cryptoProvider.base64Decode(req.body.state));
            res.redirect(state.successRedirect);
        } catch (error) {
            next(error);
        }
    }
}

Pour en savoir plus sur la façon dont l'exemple Java se procure le code d'autorisation, consultez Application web qui connecte des utilisateurs : configuration de code. Une fois que l'application a reçu le code, AuthFilter.java#L51-L56 :

Délègue à la méthode AuthHelper.processAuthenticationCodeRedirect dans AuthHelper.java#L67-L97.
Appelle getAuthResultByAuthCode.

class AuthHelper {
  // Code omitted
  void processAuthenticationCodeRedirect(HttpServletRequest httpRequest, String currentUri, String fullUrl)
            throws Throwable {

  // Code omitted
  AuthenticationResponse authResponse = AuthenticationResponseParser.parse(new URI(fullUrl), params);

  // Code omitted
  IAuthenticationResult result = getAuthResultByAuthCode(
                    httpRequest,
                    oidcResponse.getAuthorizationCode(),
                    currentUri);

// Code omitted
  }
}

La méthode getAuthResultByAuthCode est définie dans AuthHelper.java#L176. Elle crée un ConfidentialClientApplication MSAL, puis appelle acquireToken() avec les paramètres AuthorizationCodeParameters créés à partir du code d'autorisation.

   private IAuthenticationResult getAuthResultByAuthCode(
            HttpServletRequest httpServletRequest,
            AuthorizationCode authorizationCode,
            String currentUri) throws Throwable {

        IAuthenticationResult result;
        ConfidentialClientApplication app;
        try {
            app = createClientApplication();

            String authCode = authorizationCode.getValue();
            AuthorizationCodeParameters parameters = AuthorizationCodeParameters.builder(
                    authCode,
                    new URI(currentUri)).
                    build();

            Future<IAuthenticationResult> future = app.acquireToken(parameters);

            result = future.get();
        } catch (ExecutionException e) {
            throw e.getCause();
        }

        if (result == null) {
            throw new ServiceUnavailableException("authentication result was null");
        }

        SessionManagementHelper.storeTokenCacheInSession(httpServletRequest, app.tokenCache().serialize());

        return result;
    }

    private ConfidentialClientApplication createClientApplication() throws MalformedURLException {
        return ConfidentialClientApplication.builder(clientId, ClientCredentialFactory.create(clientSecret)).
                authority(authority).
                build();
    }

Pour en savoir plus sur la façon dont l’exemple Python se procure le code d’autorisation, consultez Application web qui connecte des utilisateurs : configuration de code.

L’écran de connexion Microsoft envoie le code d’autorisation à l’URL /getAToken spécifiée dans l’inscription de l’application. La route auth_response gère cette URL, appelant auth.complete_login pour traiter le code d’autorisation, puis retournant une erreur ou redirigeant vers la page d’accueil.

@app.route(app_config.REDIRECT_PATH)
def auth_response():
    result = auth.complete_log_in(request.args)
    if "error" in result:
        return render_template("auth_error.html", result=result)
    return redirect(url_for("index"))

Consultez app.py pour connaître le contexte complet de ce code.

Au lieu d’utiliser une clé secrète client, l’application cliente confidentielle peut également prouver son identité à l’aide d’un certificat client ou d’une assertion de client. L'utilisation d'assertions de client est un scénario avancé décrit en détail dans Assertions de client.

Cache de jeton

Important

L'implémentation du cache de jetons des applications ou API web est différente de l'implémentation relative aux applications de bureau, qui est souvent basée sur des fichiers. En termes de sécurité et de performances, pour les applications et API web, vous devez impérativement disposer d'un cache de jetons par compte d'utilisateur. Vous devez sérialiser le cache de jetons pour chaque compte.

Le tutoriel ASP.NET Core utilise l’injection de dépendances pour vous laisser déterminer l’implémentation du cache de jetons dans le fichier Startup.cs de votre application. Microsoft.Identity.Web est fourni avec des sérialiseurs de cache de jetons prédéfinis décrits dans Sérialisation du cache de jetons. Une possibilité intéressante consiste à choisir des caches en mémoire distribuée ASP.NET Core :

// Use a distributed token cache by adding:
    services.AddMicrosoftIdentityWebAppAuthentication(Configuration, "AzureAd")
            .EnableTokenAcquisitionToCallDownstreamApi(
                initialScopes: new string[] { "user.read" })
            .AddDistributedTokenCaches();

// Then, choose your implementation.
// For instance, the distributed in-memory cache (not cleared when you stop the app):
services.AddDistributedMemoryCache();

// Or a Redis cache:
services.AddStackExchangeRedisCache(options =>
{
 options.Configuration = "localhost";
 options.InstanceName = "SampleInstance";
});

// Or even a SQL Server token cache:
services.AddDistributedSqlServerCache(options =>
{
 options.ConnectionString = _config["DistCache_ConnectionString"];
 options.SchemaName = "dbo";
 options.TableName = "TestCache";
});

Pour plus d'informations sur les fournisseurs de cache de jetons, consultez également l’article Sérialisation du cache de jetons de Microsoft.Identity.Web et la phase Tutoriels sur les applications web ASP.NET Core | Caches de jetons du tutoriel consacré aux applications web.

Le tutoriel ASP.NET utilise l’injection de dépendances pour vous laisser déterminer l’implémentation du cache de jetons dans le fichier Startup.Auth.cs de votre application. Microsoft.Identity.Web est fourni avec des sérialiseurs de cache de jetons prédéfinis décrits dans Sérialisation du cache de jetons. Une possibilité intéressante consiste à choisir des caches en mémoire distribuée ASP.NET Core :

var services = owinTokenAcquirerFactory.Services;
// Use a distributed token cache by adding:
services.AddDistributedTokenCaches();

// Then, choose your implementation.
// For instance, the distributed in-memory cache (not cleared when you stop the app):
services.AddDistributedMemoryCache();

// Or a Redis cache:
services.AddStackExchangeRedisCache(options =>
{
 options.Configuration = "localhost";
 options.InstanceName = "SampleInstance";
});

// Or even a SQL Server token cache:
services.AddDistributedSqlServerCache(options =>
{
 options.ConnectionString = _config["DistCache_ConnectionString"];
 options.SchemaName = "dbo";
 options.TableName = "TestCache";
});

Pour plus d'informations sur les fournisseurs de cache de jetons, consultez également l’article Sérialisation du cache de jetons de Microsoft.Identity.Web et la phase Tutoriels sur les applications web ASP.NET Core | Caches de jetons du tutoriel consacré aux applications web.

Pour plus d'informations, consultez Sérialisation du cache de jetons dans MSAL.NET.

MSAL Java fournit des méthodes permettant de sérialiser et de désérialiser le cache de jetons. L'exemple Java gère la sérialisation à partir de la session, comme illustré par la méthode getAuthResultBySilentFlow dans AuthHelper.java#L99-L122 :

IAuthenticationResult getAuthResultBySilentFlow(HttpServletRequest httpRequest, HttpServletResponse httpResponse)
      throws Throwable {

  IAuthenticationResult result =  SessionManagementHelper.getAuthSessionObject(httpRequest);

  IConfidentialClientApplication app = createClientApplication();

  Object tokenCache = httpRequest.getSession().getAttribute("token_cache");
  if (tokenCache != null) {
      app.tokenCache().deserialize(tokenCache.toString());
  }

  SilentParameters parameters = SilentParameters.builder(
          Collections.singleton("User.Read"),
          result.account()).build();

  CompletableFuture<IAuthenticationResult> future = app.acquireTokenSilently(parameters);
  IAuthenticationResult updatedResult = future.get();

  // Update session with latest token cache.
  SessionManagementHelper.storeTokenCacheInSession(httpRequest, app.tokenCache().serialize());

  return updatedResult;
}

Les détails de la classe SessionManagementHelper sont fournis dans l'exemple MSAL pour Java.

Dans l’exemple Node.js, la session d’application est utilisée pour stocker le cache de jeton. À l’aide des méthodes de cache de nœud MSAL Node, le cache de jeton dans la session est lu avant la finalisation d’une demande de jeton, puis mis à jour une fois la demande de jeton correctement terminée. En voici l'illustration ci-dessous :

acquireToken(options = {}) {
    return async (req, res, next) => {
        try {
            const msalInstance = this.getMsalInstance(this.msalConfig);

            /**
             * If a token cache exists in the session, deserialize it and set it as the 
             * cache for the new MSAL CCA instance. For more, see: 
             * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/caching.md
             */
            if (req.session.tokenCache) {
                msalInstance.getTokenCache().deserialize(req.session.tokenCache);
            }

            const tokenResponse = await msalInstance.acquireTokenSilent({
                account: req.session.account,
                scopes: options.scopes || [],
            });

            /**
             * On successful token acquisition, write the updated token 
             * cache back to the session. For more, see: 
             * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/caching.md
             */
            req.session.tokenCache = msalInstance.getTokenCache().serialize();
            req.session.accessToken = tokenResponse.accessToken;
            req.session.idToken = tokenResponse.idToken;
            req.session.account = tokenResponse.account;

            res.redirect(options.successRedirect);
        } catch (error) {
            if (error instanceof msal.InteractionRequiredAuthError) {
                return this.login({
                    scopes: options.scopes || [],
                    redirectUri: options.redirectUri,
                    successRedirect: options.successRedirect || '/',
                })(req, res, next);
            }

            next(error);
        }
    };
}

Dans l’exemple Python, le package d’identité s’occupe du cache de jetons, utilisant l’objet global session pour le stockage.

Flask offre une prise en charge intégrée des sessions stockées dans un cookie, mais en raison de la longueur des cookies d’identité, l’exemple utilise le package Flask-session à la place. Tout est initialisé dans app.py :

import identity
import identity.web
import requests
from flask import Flask, redirect, render_template, request, session, url_for
from flask_session import Session

import app_config

app = Flask(__name__)
app.config.from_object(app_config)
Session(app)

auth = identity.web.Auth(
    session=session,
    authority=app.config["AUTHORITY"],
    client_id=app.config["CLIENT_ID"],
    client_credential=app.config["CLIENT_SECRET"],
)

En raison du paramètre SESSION_TYPE="filesystem" dans app_config.py, le package Flask-session stocke les sessions à l’aide du système de fichiers local.

Pour la production, vous devez utiliser un paramètre qui persiste sur plusieurs instances et déploie votre application, par exemple « sqlachemy » ou « redis ».

Étapes suivantes

À ce stade, lorsque l'utilisateur se connecte, un jeton est stocké dans le cache de jetons. Nous allons voir comment il est ensuite utilisé dans d'autres parties de l'application web.

Passez à l’article suivant de ce scénario, Supprimer des comptes du cache lors de la déconnexion globale.

Application web qui appelle des API web : Configuration de code

Bibliothèques Microsoft prenant en charge les applications web

Secrets clients ou certificats clients

Startup.cs

Option 1 : Appeler Microsoft Graph

Option n°2 : Appeler une API web en aval autre que Microsoft Graph

Résumé

Code qui échange le code d’autorisation

Cache de jeton

Étapes suivantes

Ressources supplémentaires