Applications clientes publiques et confidentielles
La bibliothèque d’authentification Microsoft (MSAL) définit deux types de clients : les clients publics et les clients confidentiels. Un client est une entité logicielle dotée d’un identificateur unique attribué par un fournisseur d’identité. Les différents types de clients se distinguent par leur capacité à s’authentifier de manière sécurisée auprès du serveur d’autorisation et à conserver des informations sensibles prouvant leur identité de telle sorte qu’elles soient inaccessibles ou inconnues pour tout utilisateur dans le cadre de son étendue d’accès.
| Applications clientes publiques | Applications clientes confidentielles |
|---|---|
 Application de bureau |
 Application web |
 API sans navigateur |
 API web |
 Application mobile |
Service/démon |
Autorisation des clients publics et confidentiels
Pour déterminer le caractère public ou confidentiel d’un client donné, nous évaluons la capacité de ce client à prouver son identité au serveur d’autorisation. Cela est important, car le serveur d’autorisation doit avoir confiance dans l’identité du client pour émettre des jetons d’accès.
Les applications clientes publiques, comme les applications de bureau, les API sans navigateur, les applications mobiles et les applications pour navigateur côté client, s’exécutent sur des appareils. La sécurité des secrets d'application n'étant pas garantie avec eux, ils ne peuvent accéder aux API Web qu'au nom de l'utilisateur. Chaque fois que le bytecode source ou compilé d’une application donnée est transmis quelque part où il peut être lu, désassemblé ou inspecté par des parties non dignes de confiance, vous avez affaire à un client public. Étant donné que ces applications ne prennent en charge que les flux de clients publics et qu’elles ne peuvent pas conserver les secrets définis au moment de la configuration, elles ne peuvent pas avoir de clés secrètes client.
Les applications clientes confidentielles, comme les applications web, les applications API web et les applications de service/démon, s’exécutent sur des serveurs. Considérées comme difficilement accessibles aux utilisateurs ou aux attaquants, elles peuvent conserver de manière satisfaisante les secrets définis au moment de la configuration pour prouver leur identité. L’ID client est exposé via le navigateur web, mais la clé secrète n’est transmise que dans le canal arrière et jamais directement exposée.
Quand devez-vous activer l’autorisation d’un flux client public dans votre inscription d’application ?
Après avoir déterminé le type d’application cliente que vous créez, vous pouvez décider s’il faut activer le flux client public dans l’inscription de votre application. Par défaut, l’autorisation du flux client public dans votre inscription d’application doit être désactivée, sauf si vous ou votre développeur créez une application cliente publique et que vous utilisez le protocole ou les fonctionnalités d’autorisation OAuth suivants :
| Protocole/fonctionnalité d’autorisation OAuth | Type d’application cliente publique | Exemples/remarque |
|---|---|---|
| Authentification native | Application avec ID externe Microsoft Entra qui nécessite une personnalisation complète de l’interface utilisateur, dont les éléments de conception, le positionnement du logo et la mise en page, garantissant une apparence de marque cohérente. | Remarque : l’authentification native est disponible uniquement pour les inscriptions d’applications dans des locataires avec ID externe Microsoft Entra. En savoir plus ici |
| Flux de code d’appareil | Applications qui s’exécutent sur des appareils avec contrainte d’entrée tels qu’une télévision intelligente, un appareil IoT ou une imprimante. | |
| Flux de mot de passe d’identification du propriétaire de la ressource | Applications qui gèrent directement les mots de passe entrés par les utilisateurs, au lieu de les rediriger vers le site web de connexion hébergé par Entra et de laisser Entra gérer leurs mots de passe de manière sécurisée. | Microsoft vous recommande de ne pas utiliser le flux ROPC. Dans la plupart des scénarios, des alternatives plus sécurisées, telles que le flux de code d’autorisation, sont disponibles et recommandées. |
| Flux d’authentification intégré Windows | Applications mobiles ou de bureau s’exécutant sous Windows ou sur une machine connectée à un domaine Windows (Microsoft Entra ID ou jointe à Microsoft Entra) à l’aide du flux d’authentification intégré Windows au lieu du gestionnaire de comptes Web. | Une application mobile ou de bureau qui doit automatiquement être connectée une fois que l’utilisateur s’est connecté au système Windows du PC avec des informations d’identification Microsoft Entra. |
Secrets et leur importance pour prouver l’identité
Voici quelques exemples de la façon dont un client peut prouver son identité au serveur d’autorisation :
- Identités managées pour les ressources Azure : pour les scénarios d’authentification d’application uniquement, les développeurs d’applications et de services qui s’appuient sur Azure peuvent déplacer la gestion, la rotation et la protection des secrets sur la plateforme. Avec les identités managées, les identités sont fournies et supprimées avec les ressources Azure, et personne, pas même l’administrateur général, ne peut accéder aux informations d’identification sous-jacentes. En utilisant des identités managées, vous pouvez éviter le risque de fuite de secrets et laisser le fournisseur gérer la sécurité à votre place.
- ID client et clé secrète client : dans ce modèle, une paire de valeurs est générée par le serveur d’autorisation lors de l’inscription d’un client. L’ID client est une valeur publique qui identifie l’application, tandis que la clé secrète client est une valeur confidentielle utilisée pour prouver l’identité de l’application.
- Preuve de la possession d’un certificat : l’infrastructure à clé publique (PKI), qui inclut des normes telles que X.509, est la technologie fondamentale qui permet d’établir des communications sécurisées sur Internet et l’épine dorsale de la confidentialité sur Internet. L’infrastructure à clé publique est utilisée pour émettre des certificats numériques qui vérifient l’identité des parties impliquées dans la communication en ligne et constitue la technologie sous-jacente de plusieurs protocoles, notamment HTTPS qui est largement utilisé pour sécuriser le trafic web. De même, il est possible d’utiliser des certificats pour sécuriser la communication de service à service (S2S) dans Azure en activant l’authentification mutuelle entre les services. Pour cela, chaque service présente un certificat à l’autre afin de prouver son identité.
- Présentation d’une assertion signée : utilisées dans la fédération des identités de la charge de travail, les assertions signées permettent d’échanger un jeton de fournisseur d’identité tiers de confiance avec la plateforme d’identité Microsoft afin d’obtenir des jetons d’accès pour appeler des ressources protégées par Microsoft Entra. Vous pouvez utiliser la fédération des identités de charge de travail pour prendre en charge différents scénarios de fédération, notamment Azure Kubernetes Service, Amazon Web Services EKS et GitHub Actions.
Quand est-il important de prouver l’identité d’un client ?
Il est important de prouver l’identité d’un client lorsqu’il est nécessaire de vérifier à la fois l’authenticité et l’autorisation d’une application cliente avant d’octroyer l’accès à des données ou à des ressources sensibles. Voici quelques exemples :
- Contrôle de l’accès à l’API : si vous disposez d’une API qui est limitée (par exemple, pour la facturation) ou qui expose des données ou des ressources sensibles, vous devez vérifier l’identité du client avant d’octroyer l’accès à l’API. Par exemple, cela est important si vous devez vérifier que seules les applications autorisées ont accès à l’API et que l’utilisation de l’API limitée est facturée au bon client.
- Protéger les utilisateurs contre l’emprunt d’identité d’une application : si vous disposez d’une application orientée utilisateur et déployée en tant que service qui accède à des données ou à des services sensibles (par exemple, une application web pilotée par un back-end), l’utilisation de clés secrètes client pour protéger les ressources utilisées par cette application peut empêcher des acteurs malveillants d’emprunter l’identité d’un client légitime pour hameçonner les utilisateurs et exfiltrer des données ou abuser de leurs droits d’accès.
- Communication S2S : si vous disposez de plusieurs services back-end qui doivent communiquer entre eux (par exemple, des API en aval), vous pouvez vérifier l’identité de chaque service pour vous assurer qu’ils sont uniquement autorisés à accéder aux ressources dont ils ont besoin pour remplir leur fonction.
En général, il est important de prouver l’identité d’un client si vous devez authentifier et autoriser un client indépendamment ou en plus d’un utilisateur.
Clients confidentiels : meilleures pratiques relatives à la gestion des secrets
Utiliser des identités managées pour simplifier le déploiement et la sécurité : les identités managées fournissent une identité managée automatiquement dans Microsoft Entra ID que les applications peuvent utiliser lors de la connexion à des ressources qui prennent en charge l’authentification Microsoft Entra. Les applications peuvent utiliser des identités managées pour obtenir des jetons Microsoft Entra ID réservés aux applications sans avoir à gérer les informations d’identification. Cela peut supprimer bon nombre des complexités associées à la gestion des secrets, tout en augmentant votre sécurité et votre résilience. Si vous utilisez des identités managées, la plupart, sinon la totalité, des meilleures pratiques suivantes sont déjà appliquées pour vous.
Utiliser le stockage sécurisé : stockez les clés secrètes client dans un emplacement sécurisé, par exemple dans Key Vault ou dans un fichier config chiffré. Évitez de stocker les clés secrètes client au format texte en clair ou en tant que fichiers archivés dans des systèmes de gestion de version.
Limiter l’accès : limitez l’accès aux clés secrètes client au personnel autorisé. Utilisez le contrôle d’accès en fonction du rôle pour restreindre l’accès aux clés secrètes client aux seules personnes qui en ont besoin pour effectuer leurs tâches opérationnelles.
Effectuer la rotation des clés secrètes client : la rotation des clés secrètes client, au besoin ou de manière planifiée, peut réduire le risque qu’un secret compromis soit exploité pour obtenir un accès non autorisé. En cas d’application, l’intervalle de temps pendant lequel il est suggéré qu’une clé reste active est influencé par la force de l’algorithme de chiffrement utilisé et/ou l’adhésion aux normes ou pratiques de conformité réglementaire.
Utiliser des secrets longs et un chiffrement fort : dans la continuité du point précédent, l’utilisation d’algorithmes de chiffrement fort pour les données en transit (sur le câble) et au repos (sur le disque) permet de réduire le risque d’une attaque par force brute sur les secrets à entropie élevée. Un algorithme comme AES-128 (ou supérieur) peut contribuer à protéger les données au repos, tandis que l’algorithme RSA-2048 (ou supérieur) peut contribuer à protéger efficacement les données en transit. Dans le monde en constante évolution de la cybersécurité, il est toujours recommandé de faire appel à des experts en sécurité et de passer régulièrement en revue votre sélection d’algorithmes.
Éviter de coder en dur les secrets : ne codez pas en dur les clés secrètes client dans le code source. En excluant les secrets du code source, vous pouvez réduire les bénéfices dont pourraient en tirer des acteurs malveillants en accédant à votre code. Cette pratique peut également vous éviter d’envoyer (push) accidentellement de tels secrets à des référentiels non sécurisés ou de les mettre à disposition de contributeurs travaillant sur le projet qui peuvent être autorisés à accéder à la source, mais pas aux secrets.
Monitorer les référentiels à la recherche de secrets fuités : malheureusement, il arrive que le code source fasse l’objet de mauvais archivages. Il est possible d’utiliser des crochets précommit Git pour empêcher les archivages accidentels, mais cette démarche ne saurait remplacer entièrement le monitoring. Le monitoring automatisé des référentiels peut identifier les secrets fuités et, avec un plan de rotation des informations d’identification compromises en place, contribuer à réduire les incidents de sécurité.
Rechercher les activités suspectes : monitorez les journaux et les pistes d’audit à la recherche d’activités suspectes liées aux clés secrètes client. Dans la mesure du possible, utilisez des alertes et des processus de réponse automatisés pour avertir le personnel et définissez des plans d’urgence pour faire face à toute activité inhabituelle liée aux clés secrètes client.
Garder à l’esprit la confidentialité des clés secrètes client lors de la conception de vos applications : la robustesse de votre modèle de sécurité est celle du maillon le plus faible de la chaîne. Ne transférez pas les jetons ou informations d’identification de sécurité de clients confidentiels vers des clients publics, car les données des clés secrètes client pourraient se retrouver sur un client public et favoriser l’emprunt d’identité du client confidentiel.
Utiliser des bibliothèques et des Kits de développement logiciel (SDK) à jour provenant de sources de confiance : la plateforme d’identité Microsoft fournit divers SDK et intergiciels client et serveur conçus pour améliorer votre productivité tout en sécurisant vos applications. Des bibliothèques telles que Microsoft.Identity.Web simplifient l’ajout de mécanismes d’authentification et d’autorisation aux applications web et API sur la plateforme d’identité Microsoft. Le fait de tenir à jour les dépendances permet de garantir que vos applications et services bénéficient des dernières innovations et mises à jour de sécurité.
Comparaison des types de clients et de leurs fonctionnalités
Voici quelques points communs et différences entre les applications clientes publiques et confidentielles :
- Les deux types d’applications gèrent un cache de jetons utilisateur et peuvent acquérir un jeton silencieusement (quand le jeton est présent dans le cache). Les applications clientes confidentielles disposent également d’un cache de jetons d’application pour les jetons acquis par l’application elle-même.
- Les deux types d’application peuvent gérer les comptes d’utilisateur et obtenir un compte à partir du cache des jetons utilisateur, recevoir un compte à partir de son identifiant ou supprimer un compte.
- Dans MSAL, les applications clientes publiques peuvent acquérir un jeton de quatre manières via des flux d’authentification distincts. Les applications clientes confidentielles ne peuvent acquérir un jeton que de trois manières. Elles peuvent calculer l’URL du point de terminaison d’autorisation du fournisseur d’identité d’une seule manière. L’ID client est passé une seule fois lors de la construction de l’application et n’a pas besoin d’être repassé lorsque l’application acquiert un jeton. Pour plus d’informations, consultez Acquisition des jetons.
Les clients publics sont utiles pour activer l’accès délégué par l’utilisateur à des ressources protégées, mais ils ne peuvent pas prouver leur propre identité d’application. En revanche, les clients confidentiels peuvent à la fois authentifier et autoriser des utilisateurs et des applications. Ils doivent être conçus dans une optique de sécurité afin que leurs secrets ne soient pas partagés avec des clients publics ou d’autres tiers.
Dans certains cas, par exemple la communication S2S, l’utilisation d’une infrastructure comme celle des identités managées contribue grandement à simplifier le développement et le déploiement de services et à éliminer une grande partie de la complexité généralement associée à la gestion des secrets. Si vous ne pouvez pas utiliser des identités managées, il est important de mettre en place des stratégies, des mesures préventives et des plans d’urgence pour sécuriser les secrets et répondre aux incidents de sécurité associés.
Voir aussi
Pour plus d’informations sur la configuration et l’instanciation des applications, consultez les articles suivants :