Authentifier des utilisateurs pour Confiance Zéro

Cet article vous aide, en tant que développeur, à apprendre les meilleures pratiques pour authentifier vos utilisateurs d’application dans le cadre du développement d'applications Confiance Zéro. Améliorez toujours la sécurité de votre application avec les principes de Confiance Zéro de privilège minimum et vérifiez explicitement.

Jetons d’ID dans l’authentification utilisateur

Lorsqu’un utilisateur doit s’authentifier auprès de votre application, cette dernière peut demander un jeton d’identité (ID) au lieu de collecter un nom d’utilisateur et un mot de passe. L’authentification des utilisateurs via la Plateforme d’identités Microsoft évite les risques de sécurité qui surviennent lorsque votre application conserve les informations d’identification d’utilisateur. Lorsque vous demandez des jetons d’ID, il n’existe aucun nom d’utilisateur ou mot de passe correspondant dans votre application si un acteur malveillant la viole ou la compromet.

Le jeton d’ID Plateforme d’identités Microsoft fait partie de la norme OpenID Connect (OIDC) qui spécifie les jetons d’ID en tant que jetons Web JSON (JWT). La chaîne longue JWT comprend trois composants :

1. Revendications de l’en-tête. Les revendications de l’en-tête présentes dans les jetons d’ID incluent typ (revendication de type), alg (algorithme pour la signature du jeton) et kid (empreinte numérique de la clé publique pour valider la signature du jeton).
2. Revendications de la charge utile. La charge utile ou le corps (partie centrale d’un jeton Web JSON) contient une série de paires d’attributs de nom. La norme exige qu’il y ait une revendication avec le iss (nom d’émetteur) qui va à l’application ayant émis le jeton (le aud ou la revendication d’audience).
3. Signature. Microsoft Entra ID génère la signature de jeton que les applications peuvent utiliser pour vérifier que le jeton n’est pas modifié et que vous pouvez l’approuver.

L’exemple suivant d’un jeton d’ID affiche des informations sur l’utilisateur et confirme l’authentification pour utiliser l’application.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

Jetons d’ID dans la gestion des accès

Pour recevoir l’ID de votre application (client), inscrivez votre application auprès du Plateforme d’identités Microsoft. Lorsque vous recevez un jeton avec une revendication d’audience (aud) correspondant à l’ID client de votre application, l’utilisateur identifié dans le jeton authentifié dans votre application. Il est possible que les administrateurs informatiques autorisent tous les utilisateurs du tenant à utiliser votre application. Ils peuvent peut-être autoriser l’utilisateur membre d’un groupe à utiliser votre application.

Si vous recevez un jeton dont la revendication d’audience est différente de l’ID client de votre application, rejetez immédiatement le jeton. L’utilisateur n’est pas authentifié à votre application, car il est connecté à une autre application. Vérifiez toujours que l’utilisateur dispose de l’autorisation d’utiliser votre application.

Ces détails de revendications sont importants dans l’authentification utilisateur :

• Un jeton Web JSON est valide jusqu’à son expiration. La exp revendication (expiration) vous indique quand le jeton expire. Si l’heure actuelle est antérieure à l’heure de la revendication exp, le jeton est valide.
• Ne considérez pas l’utilisateur comme authentifié avant l’heure spécifiée dans la revendication nbf (pas avant l’heure). Les temps nbf et exp heures du jeton définissent la durée de vie valide du jeton. Lorsque l’heure d’expiration est imminente, assurez-vous d’obtenir un nouveau jeton d’ID.
• La (revendication d’objet) sub est un identificateur unique pour un utilisateur d’application. Le même utilisateur a une revendication sub différente pour d’autres applications. Si vous souhaitez stocker des données à associer à un utilisateur et empêcher un attaquant de créer cette association, utilisez la revendication de l’objet. Étant donné qu’il n’expose pas l’identité Microsoft Entra de l’utilisateur, il s’agit du moyen le plus privé d’associer des données à un utilisateur. La revendication sub est immuable.
• Si vous souhaitez partager des informations entre plusieurs applications, utilisez la combinaison de revendications ID client (tid) et ID d’objet (oid) propres à l’utilisateur. L’ID client combiné et l’ID d’objet sont immuables.
• Peu importe ce qui arrive à l’identité d’un individu, les revendications sub, oid et tid restent immuables. Tout ce qui concerne l’utilisateur peut changer et vous pouvez toujours clér vos données hors de l’identification de l’utilisateur en fonction de l’objet ou des revendications combinées tid et oid.

Authentification avec OIDC

Pour illustrer l’authentification utilisateur, examinons les applications qui utilisent OIDC pour authentifier un utilisateur. Les mêmes principes s’appliquent aux applications qui utilisent Security Assertion Markup Language (SAML) ou WS-Federation.

Une application authentifie l’utilisateur lorsque l’application demande un jeton d’ID à partir de la Plateforme d’identités Microsoft. Les charges de travail (applications qui n’ont pas d’utilisateurs présents, mais plutôt s’exécutent en tant que services, traitements en arrière-plan, démons) ignorent cette étape.

Vous devez toujours demander ce jeton de manière silencieuse en premier. Pour acquérir silencieusement un jeton dans les bibliothèques Microsoft Authenticator (MSAL), votre application peut commencer par la méthode AcquireTokenSilent. Si votre application peut s’authentifier sans déranger l’utilisateur, elle reçoit le jeton d’ID demandé.

Si la Plateforme d’identités Microsoft ne peut pas terminer la requête sans interagir avec l’utilisateur, votre application doit revenir à la méthode MSALAcquireTokenInteractive. Pour acquérir de manière interactive un jeton, effectuez la requête en ouvrant une surface web à une adresse sous le domaine https://login.microsoftonline.com.

À partir de cette surface web, l’utilisateur a une conversation privée avec la Plateforme d’identités Microsoft. Votre application n’a aucune vue sur cette conversation, ni n’a aucun contrôle de la conversation. La plateforme d’identités Microsoft peut demander un ID d’utilisateur et un mot de passe, une authentification multifacteur (MFA), une authentification sans mot de passe ou toute autre interaction d’authentification que l’administrateur informatique ou l’utilisateur a configuré.

Votre application reçoit un jeton d’ID après exécution par l’utilisateur des étapes d’authentification requises. Quand votre application reçoit le jeton, vous pouvez avoir la certitude que la plateforme d’identités Microsoft a authentifié l’utilisateur. Si votre application ne reçoit aucun jeton d’ID, la plateforme d’identités Microsoft n’a pas authentifié l’utilisateur. N’autorisez pas les utilisateurs non authentifiés à continuer dans des zones sécurisées de votre application.

Il est recommandé aux applications de créer une session pour un utilisateur après avoir reçu un jeton d’ID de Microsoft Entra ID. Dans le jeton d’ID qu’une application reçoit, une revendication d’expiration (exp) avec un horodateur Unix. Cet horodatage spécifie l’heure d’expiration ou après pour laquelle l'application ne doit pas accepter le JWT pour le traitement. Utilisez ce délai d’expiration de jeton pour piloter la durée de vie de vos sessions utilisateur. La revendication exp joue un rôle crucial dans le maintien d’un utilisateur vérifié explicitement devant l’application avec le privilège approprié et pour la durée appropriée.

Prise en charge de l’authentification unique

L’authentification unique (SSO) permet aux utilisateurs de se connecter avec un seul jeu d'identifiants à plusieurs systèmes logiciels indépendants. Le SSO permet aux développeurs d’applications de ne pas exiger qu’un utilisateur se connecte à chaque application séparément et à plusieurs reprises. Au cœur du SSO, les développeurs garantissent que toutes les applications sur l’appareil de l’utilisateur partagent l’aire web qui authentifie l’utilisateur. Artefacts sur l’aire web (tels que l’état de session et les cookies) après la réussite de l’authentification unique du lecteur d’authentification SSO.

Comme illustré dans le diagramme suivant, le cas d’utilisation le plus simple d’une surface web partagée est une application qui s’exécute dans un navigateur web (par exemple, Microsoft Edge, Google Chrome, Firefox, Safari). Les onglets du navigateur partagent l’état SSO.

Titre du diagramme : navigateur web – cas le plus simple. L’affichage en haut du diagramme est une forme cloud contenant une icône Microsoft Entra ID. En dessous de la forme cloud est une boîte. Connecter la forme cloud et la zone est une ligne avec une flèche sur chaque extrémité. L’étiquette de zone est « Me permet de rester connecté, sauvegarde les cookies d'état SSO à travers les appels ». À l’intérieur de la zone, sur le côté gauche, est une icône qui ressemble à un cookie. Sous le cookie, la légende est « Conversation privée avec l’utilisateur ». Sous la légende se trouve une icône qui représente l'utilisateur. À gauche de ces trois composants, à l’intérieur de la boîte, il s’agit d’une autre boîte. L'étiquette de la boîte interne est « Onglets ». Sous l’étiquette figurent quatre zones carrées qui représentent les fenêtres du navigateur dans les onglets.

La Plateforme d’identités Microsoft gère l’état du SSO dans un navigateur spécifique, sauf si l’utilisateur dispose de différents navigateurs ouverts sur le même appareil. Sous Windows 10 ou version plus récente, la plateforme d’identités Microsoft prend en charge en mode natif l’authentification unique (SSO) du navigateur Microsoft Edge. Quand l’utilisateur s’est connecté à Windows, les ajustements dans Google Chrome (via l’extension de comptes Windows 10) et dans Mozilla Firefox v91+ (via un paramètre de navigateur) permettent à chaque navigateur de partager l’état de SSO de Windows lui-même.

Comme illustré dans le diagramme suivant, le cas d’utilisation de l’application native est plus compliqué.

Titre du diagramme : applications natives – navigateurs incorporés – aucun SSO. L’affichage en haut du diagramme est une forme cloud contenant une icône Microsoft Entra ID. En bas du diagramme, quatre zones sont réparties horizontalement. Dans le coin inférieur droit de chaque boîte se trouve une icône représentant un utilisateur. À l'intérieur de chaque boîte se trouve une représentation des fenêtres du navigateur, y compris une icône de cookie et une icône de globe. Chacune des quatre boîtes est reliée à la forme du cloud par une ligne munie d'une flèche à chaque extrémité.

Approche du répartiteur d’authentification

Il est courant que chaque application native ait sa propre vue WebView intégrée, ce qui l'empêche de participer au SSO. Pour répondre à ce scénario, Microsoft Entra ID utilise une approche de répartiteur d'authentification (auth broker) pour les applications natives, comme illustré dans le diagramme suivant.

Titre du diagramme : approche du répartiteur d’authentification. L’affichage en haut du diagramme est une forme cloud contenant une icône Microsoft Entra ID. Sous le cloud se trouve un rectangle portant l'étiquette Auth Broker. La forme rectangle contient une icône de cookie et une icône de globe. Le cloud et le rectangle sont reliés par une ligne avec une flèche à chaque extrémité. En bas du diagramme, quatre zones sont réparties horizontalement. Dans le coin inférieur droit de chaque boîte se trouve une icône représentant un utilisateur. Les icônes de chaque zone représentent les fenêtres du navigateur. Chacune des quatre boîtes est reliée au rectangle par une ligne munie d'une flèche à chaque extrémité.

Lorsqu'un répartiteur d'authentification est en place, les applications envoient des demandes d'authentification au répartiteur plutôt que directement à la Plateforme d’identités Microsoft. De cette façon, le répartiteur devient la surface partagée pour toutes les authentifications sur l’appareil.

En plus de fournir une surface partagée, le répartiteur d’authentification offre d’autres avantages. Lors de l’adoption de Confiance Zéro, il est possible que les entreprises souhaitent que des applications s’exécutent uniquement à partir des appareils gérés de l’entreprise. Les exemples de gestion des appareils d’entreprise incluent la gestion des périphériques mobiles (MDM) et des scénarios dans lesquels les utilisateurs apportent leurs propres appareils qui participent à la gestion des applications mobiles (GAM).

Par conception, les systèmes d’exploitation sous-jacents (OS) isolent les navigateurs. Les développeurs ont besoin d’une connexion plus étroite avec le système d’exploitation pour avoir un contrôle total sur les détails de l’appareil. Dans Windows, le répartiteur d’authentification est le Gestionnaire de comptes web Windows (WAM). Sur d’autres appareils, le répartiteur d’authentification est l’application Microsoft Authenticator (pour les appareils exécutant iOS ou Android) ou l’application Portail d’entreprise (pour les appareils exécutant Android). Les applications accèdent au répartiteur d’authentification avec MSAL. Dans Windows, une application peut accéder à WAM sans MSAL. Toutefois, MSAL est le moyen le plus simple pour les applications d’accéder au répartiteur d’authentification (en particulier les applications qui ne sont pas plateforme Windows universelle applications).

Les répartiteurs d’authentification fonctionnent conjointement avec Microsoft Entra ID pour utiliser les jetons d’actualisation principaux (PRT) qui réduisent la nécessité pour les utilisateurs de s’authentifier plusieurs fois. Les PRT peuvent déterminer si l’utilisateur se trouve sur un appareil géré. Microsoft Entra ID nécessite des répartiteurs d’authentification car il introduit des jetons de preuve de possession, une option plus sûre que les jetons du porteur qui prévalent aujourd'hui.

Étapes suivantes

• Dépannage des problèmes de jetons d’accès Microsoft Entra : valider un jeton d’accès décrit comment, lorsque vous disposez d’un jeton d’accès Microsoft Entra, vous vérifiez que certains champs correspondent à l’enregistrement.
• Augmenter la résilience des applications d’authentification et d’autorisation que vous développez applications d’adresses en série qui utilisent la plateforme d’identités Microsoft et Microsoft Entra ID. Elles comprennent des aides pour les applications clientes et de service qui travaillent pour le compte d'un utilisateur connecté et pour les applications démon qui travaillent pour leur propre compte. Ils contiennent les meilleures pratiques relatives à l’utilisation de jetons et à l’appel de ressources.
• Personnaliser les jetons décrit les informations que vous pouvez recevoir dans des jetons Microsoft Entra et la façon dont vous pouvez les personnaliser.
• Configurer les revendications de groupe et les rôles d’application dans les jetons vous montre comment configurer des définitions de rôle d’application pour vos applications et comment affecter des groupes de sécurité aux rôles d’application.
• Générer des applications qui sécurisent l’identité via les autorisations et le consentement fournit une vue d’ensemble des autorisations et des meilleures pratiques d’accès.