Augmenter la résilience de l’authentification et de l’autorisation dans les applications clientes que vous développez

Article
10/25/2023

Découvrez comment renforcer la résilience des applications clientes qui utilisent la plateforme d’identités Microsoft et Microsoft Entra ID pour connecter les utilisateurs et effectuer des actions en leur nom.

Utiliser la bibliothèque d’authentification Microsoft (MSAL)

La Bibliothèque d’authentification Microsoft (MSAL) est un des éléments de la plateforme d’identité Microsoft. MSAL acquiert, gère, met en cache et actualise les jetons ; cette solution applique les meilleures pratiques en matière de résilience. MSAL aide les développeurs à créer des solutions sécurisées.

En savoir plus :

MSAL met en cache les jetons et utilise un modèle silencieux d’acquisition de jetons. MSAL sérialise le cache de jetons sur les systèmes d’exploitation qui fournissent nativement un stockage sécurisé, comme la plateforme universelle Windows (UWP), iOS et Android. Personnalisez le comportement de sérialisation lorsque vous utilisez :

Microsoft.Identity.Web
MSAL.NET
MSAL pour Java
MSAL pour Python

En savoir plus :

Lorsque vous utilisez MSAL, la mise en cache des jetons, l’actualisation et l’acquisition en mode silencieux sont prises en charge. Utilisez des modèles simples pour acquérir les jetons d’authentification. De nombreuses langues sont prises en charge. Recherchez des exemples de code sur, Exemples de code pour la plateforme d’identités Microsoft.

C#
JavaScript

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL peut actualiser les jetons. Lorsque la plate-forme d’identité Microsoft émet un jeton de longue durée, elle peut envoyer des informations au client pour actualiser le jeton (refresh_in). L’application s’exécute alors que l’ancien jeton est valide, mais l’acquisition d’un autre jeton prend plus de temps.

Versions MSAL

Nous recommandons aux développeurs de générer un processus d’utilisation de la dernière version de MSAL, car l’authentification fait partie de la sécurité de l’application. Utilisez cette pratique pour les bibliothèques en cours de développement et améliorez la résilience des applications.

Recherchez la dernière version et les notes de publication :

Modèles résilients pour la gestion des jetons

Si vous n’utilisez pas MSAL, utilisez ces modèles résilients pour la gestion des jetons. La Bibliothèque MSAL implémente les meilleures pratiques.

En général, les applications qui utilisent l’authentification moderne appellent un point de terminaison pour récupérer les jetons qui authentifient l’utilisateur ou autorisent l’application à appeler des API protégées. MSAL gère l’authentification et implémente des modèles pour améliorer la résilience. Si vous n’utilisez pas MSAL, suivez les conseils de cette section pour connaître les meilleures pratiques. Autrement, MSAL implémente automatiquement les meilleures pratiques.

Mettre en cache des jetons

Vérifiez que les applications mettent bien en cache les jetons provenant de la plateforme d’identité Microsoft. Une fois que votre application a reçu des jetons, la réponse HTTP avec des jetons a une propriété expires_in qui indique la durée de mise en cache et quand la réutiliser. Confirmez que l’application n’essaie pas de décoder un jeton d’accès à l’API.

Illustration d’une application faisant appel à la plateforme d’identité Microsoft, par le biais d’un cache de jetons sur l’appareil qui exécute l’application.

L’utilisation du jeton mis en cache empêche tout trafic inutile entre une application et la plateforme d’identité Microsoft. Ce scénario rend l’application moins vulnérable aux échecs d’acquisition de jetons en réduisant les appels d’acquisition de jetons. Les jetons mis en cache améliorent les performances de l’application, car celle-ci bloque moins fréquemment l’acquisition des jetons. Les utilisateurs restent connectés à votre application pendant toute la durée de validité du jeton.

Sérialiser et conserver les jetons

Vérifiez que les applications sérialisent leur cache de jetons de manière sécurisée pour conserver les jetons entre les instances d’application. Réutiliser les jetons au cours de leur durée de validité. Les jetons d’actualisation et les jetons d’accès sont émis pour plusieurs heures. Pendant cette période, les utilisateurs peuvent démarrer votre application plusieurs fois. Lorsqu’une application démarre, elle recherche un accès valide ou un jeton d’actualisation. Cela améliore la résilience et les performances de l’application.

En savoir plus :

Vérifiez que le stockage de jetons persistant dispose d’un contrôle d’accès et d’un chiffrement qui soient en relation avec l’identité de l’utilisateur-propriétaire ou du processus. Différents systèmes d’exploitation proposent des fonctions de stockage des informations d’identification.

Acquérir des jetons silencieusement

L’authentification d’un utilisateur ou l’obtention de l’autorisation d’appeler une API nécessite plusieurs étapes dans la plateforme d’identité Microsoft. Par exemple, les utilisateurs qui se connectent pour la première fois saisissent des informations d’identification et effectuent une authentification multifacteur. Chaque étape affecte la ressource qui fournit le service. La meilleure expérience utilisateur avec les dépendances minimales est l’acquisition de jetons en mode silencieux.

Illustration des services de la plateforme d’identité Microsoft qui permettent d’effectuer l’authentification ou l’autorisation de l’utilisateur.

L’acquisition d’un jeton silencieux commence par un jeton valide provenant du cache de jetons de l’application. Si aucun jeton valide n’est disponible, l’application tente d’acquérir un jeton en utilisant un jeton d’actualisation disponible et le point de terminaison du jeton. Si aucune de ces options n’est disponible, l’application acquiert un jeton à l’aide du paramètre prompt=none. Cette action utilise le point de terminaison d’autorisation, mais aucune interface utilisateur n’apparaît pour l’utilisateur. Si possible, la plateforme d’identité Microsoft fournit un jeton à l’application sans interaction avec l’utilisateur. Si aucune méthode ne génère de jeton, l’utilisateur devra se réauthentifier manuellement.

Notes

De manière générale, veillez à ce que les applications n’utilisent pas d’invites telles que « connexion » et « consentement ». Ces invites forcent l’interaction de l’utilisateur, lorsqu’aucune interaction n’est requise.

Gestion du code de réponse

Les sections suivantes vous permettront de vous familiariser avec les codes de réponse.

Code de réponse HTTP 429

Il existe des réactions d’erreur qui affectent la résilience. Si votre application reçoit un code de réponse HTTP 429, Trop de requêtes, a plateforme d’identité Microsoft limite vos demandes. Si une application fait trop de demandes, elle est limitée pour l’empêcher de recevoir des jetons. N’autorisez pas une application à tenter d’acquérir des jetons avant que le temps de réponse Nouvelle tentative après ne soit écoulé. Souvent, une réponse 429 indique que l’application ne met pas en cache et réutilise correctement les jetons. Confirmer la manière dont les jetons sont mis en cache et réutilisés dans l’application.

Code de réponse HTTP 5x

Quand une application reçoit un code de réponse HTTP 5x, l’application ne doit pas entrer dans une boucle de nouvelle tentative rapide. Procédez de la même manière que pour une réponse 429. Si l’en-tête « Nouvelle tentative après » n’apparaît, mettez en œuvre une nouvelle tentative exponentielle d’interruption avec la première tentative au moins 5 secondes après la réponse.

Lorsqu’une requête expire, les nouvelles tentatives immédiates sont déconseillées. Mettez en œuvre une tentative de retour exponentiel, la première tentative devant avoir lieu au moins 5 secondes après la réponse.

De nombreuses applications et API ont besoin d’informations sur l’utilisateur pour être autorisées. Les méthodes disponibles présentent des avantages et des inconvénients.

Jetons

Les jetons d’identité (ID) et les jetons d’accès contiennent des revendications standard qui fournissent des informations. Si les informations nécessaires se trouvent dans le jeton, la technique la plus efficace est les revendications de jeton,ce qui permet d’éviter un autre appel au réseau. Moins d’appels réseau équivaut à une meilleure résilience.

En savoir plus :

Notes

Certaines applications appellent le point de terminaison UserInfo pour récupérer les revendications relatives à l’utilisateur qui s’est authentifié. Les informations contenues dans le jeton d’identification sont un surensemble d’informations provenant du point de terminaison UserInfo. Autorisez les applications à utiliser le jeton d’identification plutôt que d’appeler le point de terminaison UserInfo.

Augmentez les revendications standard de jetons avec des revendications optionnelles, telles que les groupes. L’option Groupe d’applications inclut les groupes affectés à l’application. Les options Tout or Groupes de sécurité incluent les groupes d’applications du même client, qui peuvent ajouter des groupes au jeton. Évaluez l’effet, car cela peut annuler l’efficacité de la demande de groupes dans le jeton en provoquant un surdimensionnement du jeton et en exigeant plus d’appels pour récupérer les groupes.

En savoir plus :

Nous vous recommandons d’utiliser et d’inclure des rôles d’application, que les clients gèrent à l’aide du portail ou des API. Attribuez des rôles aux utilisateurs et aux groupes pour contrôler l’accès. Lorsqu’un jeton est émis, les rôles attribués sont dans la revendication des rôles de jeton. Les informations dérivées d’un jeton empêchent d’autres appels d’API.

Consultez, Ajouter des rôles d’application dans votre application et les recevoir dans le jeton

Ajoutez des revendications basées sur les informations fournies par les clients. Par exemple, une extension a un ID utilisateur spécifique à l’entreprise.

L’ajout d’informations du répertoire à un jeton est efficace et augmente la résilience en réduisant les dépendances. Cela ne règle pas les problèmes de résilience dus à l’impossibilité d’acquérir un jeton. Ajoutez des revendications facultatives pour les scénarios principaux de l’application. Si l’application a besoin d’informations pour des fonctions administratives, elle peut les obtenir, le cas échéant.

Microsoft Graph

Microsoft Graph dispose d’un point de terminaison d’API unifié pour accéder aux données Microsoft 365 sur les modèles de productivité, l’identité et la sécurité. Les applications utilisant Microsoft Graph peuvent utiliser les informations Microsoft 365 pour l’autorisation.

Les applications nécessitent un jeton pour accéder à Microsoft 365, qui est plus résilient que les API précédentes pour les composants Microsoft 365 tels que Microsoft Exchange ou Microsoft SharePoint qui nécessitaient plusieurs jetons.

Lorsque vous utilisez des API Microsoft Graph, utilisez un Kit de développement logiciel (SDK) Microsoft Graph qui simplifie la création d’applications résilientes qui accèdent à Microsoft Graph.

Consultez Vue d’ensemble du Kit de développement logiciel (SDK) Microsoft Graph

Pour l’autorisation, envisagez d’utiliser des revendications de jeton au lieu de certains appels Microsoft Graph. Demander des groupes, des rôles d’application et des revendications facultatives dans les jetons. Microsoft Graph pour l’autorisation nécessite plus d’appels réseau qui s’appuient sur le plateforme d’identités Microsoft et Microsoft Graph. Toutefois, si votre application s’appuie sur Microsoft Graph comme couche de données, Microsoft Graph pour l’autorisation ne présente pas plus de risques.

Utiliser l’authentification par répartiteur sur des appareils mobiles

Sur les appareils mobiles, l’utilisation d’un répartiteur d’authentification comme Microsoft Authenticator améliore la résilience. Le répartiteur d’authentification utilise un jeton d’actualisation principal (PRT) avec des revendications concernant l’utilisateur et l’appareil. Utilisez un PRT pour les jetons d’authentification afin d’accéder à d’autres applications à partir de l’appareil. Lorsqu’un PRT demande l’accès à l’application, Microsoft Entra ID approuve ses revendications d’appareil et d’authentification multifacteur (MFA). Cela augmente la résilience en limitant les étapes d’authentification de l’appareil. Les utilisateurs ne reçoivent pas plusieurs invites MFA sur le même appareil.

Consultez Qu’est-ce qu’un jeton d’actualisation principal ?

Illustration d’une application faisant appel à la plateforme d’identité Microsoft, par le biais d’un cache de jetons et d’un répartiteur d’authentification sur l’appareil qui exécute l’application.

MSAL prend en charge l’authentification de répartiteur. En savoir plus :

Évaluation continue de l’accès

L’évaluation continue de l’accès (CAE) renforce la sécurité et la résilience des applications grâce à des jetons de longue durée. Avec la CAE, un jeton d'accès est révoqué en fonction d'événements critiques et de l'évaluation de la stratégie, plutôt que sur la base d'une courte durée de validité du jeton. Pour certaines API de ressources, parce que le risque et la stratégie sont évalués en temps réel, la CAE augmente la durée de validité des jetons jusqu’à 28 heures. MSAL actualise les jetons de longue durée.

En savoir plus :

Si vous développez des API de ressources, accédez à openid.net pour Signaux partagés – Une infrastructure de webhooks sécurisée.

Augmenter la résilience de l’authentification et de l’autorisation dans les applications clientes que vous développez