Partager via

Authentifier des applications et des utilisateurs avec Microsoft Entra ID

  • Article

L’une des principales fonctions de Microsoft Entra ID pour les applications est l’authentification, le processus par lequel les utilisateurs déclarent leur identité avec un identificateur personnel, comme un nom d’utilisateur ou une adresse e-mail. La preuve de l’identité est fournie. Cette preuve peut être un mot de passe, un artefact d’authentification multifacteur, une empreinte biométrique ou un consentement sans mot de passe.

Cet article décrit comment les applications utilisent Microsoft Entra ID pour authentifier les utilisateurs et les applications. Il s’agit du troisième d’une série d’articles sur la manière dont les développeurs de logiciels indépendants (ISV) peuvent créer et optimiser leurs applications pour Microsoft Entra ID. Dans cette série, vous pouvez en apprendre davantage sur ces sujets :

Requête de jetons

Les applications demandent un jeton à Microsoft Entra ID. Une fois que les applications reçoivent le jeton, elles peuvent utiliser les informations contenues dans ce jeton pour identifier l’utilisateur. Lorsque votre système repose sur Microsoft Entra ID, les utilisateurs peuvent authentifier de nombreuses applications avec un seul compte Microsoft Entra ID inscrit (authentification unique). L’authentification unique permet aux utilisateurs de se connecter à plusieurs systèmes logiciels indépendants avec un ensemble d’informations d’identification unique.

Les protocoles que les développeurs peuvent utiliser pour demander un jeton à Microsoft Entra ID utilisent un navigateur pour connecter l’utilisateur au site web Microsoft Entra ID. Ce site web permet à l’utilisateur d’avoir une conversation privée avec Microsoft Entra ID. L’application ne participe pas à cette conversation privée. Les applications lancent le site web Microsoft Entra ID où l’utilisateur lance le processus d’authentification. Une fois le processus d’authentification terminé, Microsoft Entra ID redirige l’utilisateur vers l’application, avec ou sans jeton.

Il est important que les utilisateurs soient contraints de passer par le processus d’authentification le plus rarement possible. Plus souvent ils devront passer par ce processus, plus ils seront vulnérables aux attaques par hameçonnage.

Réduire les invites de connexion

L’authentification unique peut réduire ou éliminer les invites de connexion. Les développeurs jouent un rôle essentiel dans la réduction et l’élimination des invites de connexion. Toutes les applications doivent partager le navigateur qui accède au site web Microsoft Entra ID où les utilisateurs effectuent le processus d’authentification. Si votre application est une application monopage basée sur un navigateur ou une application web, aucune étape de développement n’est requise. Toutes les applications dans le navigateur partagent ce dernier. Pour les applications natives qui s’exécutent sur des ordinateurs de bureau et des appareils mobiles, les développeurs doivent réduire ou éliminer de manière proactive les invites de connexion.

La meilleure méthode pour réduire ou éliminer les invites de connexion consiste à utiliser des bibliothèques d’authentification Microsoft (MSAL), ou une bibliothèque reposant sur MSAL, et des authentifications de répartiteur. Cette méthode minimise les invites de connexion et offre l’expérience la plus fluide. Si la conception sur MSAL n’est pas possible, votre application doit utiliser le navigateur système pour minimiser les invites de connexion.

Pour les applications s’exécutant dans iOS ou Android, les fournisseurs de plateforme mobile disposent de certaines fonctionnalités pour rendre cette expérience plus fluide. Google fournit des instructions pour les applications Android avec des onglets personnalisés Chrome. Apple fournit des instructions pour authentifier un utilisateur via un service web dans les applications iOS. Évitez d’utiliser des WebViews incorporés, car ils peuvent ne pas autoriser le partage entre les applications ou avec le navigateur système.

Les deux protocoles pour l’authentification utilisateur sont Security Assertion Markup Language (SAML) 2.0 et OpenID Connect (OIDC). Microsoft Entra ID prend entièrement en charge les applications utilisant les deux protocoles, afin que les développeurs puissent choisir l’un ou l’autre en fonction de leurs besoins.

Les références suivantes détaillent la prise en charge de SAML par Microsoft Entra ID.

Il existe certaines limitations concernant la prise en charge de SAML par Microsoft Entra ID. Plus spécifiquement, vous ne pouvez pas migrer des applications qui nécessitent les capacités de protocole suivantes : prise en charge du modèle ActAs WS-Trust et résolution d’artefact SAML.

Bien que Microsoft Entra ID prenne entièrement en charge SAML pour les applications basées sur le protocole SAML, la plateforme d’identités Microsoft ne fournit pas de bibliothèques ni d’autres outils de développement pour le développement d’applications avec SAML. Pour le développement de nouvelles applications, nous vous recommandons d’utiliser OpenID Connect (OIDC) pour l’authentification.

Microsoft Entra ID prend entièrement en charge OpenID Connect. Microsoft fournit des bibliothèques MSAL, Microsoft Identity Web et Azure SDK pour faciliter le développement d’applications OIDC. OpenID Connect (OIDC) sur la plateforme d’identités Microsoft détaille la prise en charge d’OIDC par Microsoft Entra ID. MSAL prend automatiquement en charge OIDC. MSAL demande toujours un jeton d’ID OIDC avec chaque demande de jeton, y compris les demandes d’autorisation à une ressource par une application.

Durée de vie des jetons

MSAL met en cache les jetons d’ID et les jetons d’accès en fonction de l’heure d’expiration du jeton d’accès. Comme Microsoft Entra ID définit différemment la durée de vie des jetons d’ID et des jetons d’accès, vous êtes susceptible de recevoir un jeton d’ID expiré à partir d’un cache MSAL expiré alors que le jeton d’accès est toujours dans sa durée de vie valide.

MSAL ne renouvelle pas automatiquement les jetons d’ID. MSAL renouvelle les jetons d’accès à (ou proche de) la fin de vie du jeton d’accès lorsqu’une application demande le jeton. À ce stade, MSAL demande un nouveau jeton d’ID. Pour implémenter OIDC, utilisez la revendication exp (expiration) dans le jeton d’ID pour planifier une demande de jeton d’ID à l’aide de l’indicateur ForceRefresh dans MSAL.

Lorsque la conception sur MSAL ou sur une bibliothèque basée sur MSAL n’est pas possible, vous pouvez utiliser la norme OpenID Connect pour authentifier l’utilisateur actif. Certaines fonctionnalités des applications natives peuvent ne pas être disponibles sans utiliser MSAL, par exemple garantir que l’application native s’exécute sur un appareil géré. Passez en revue Augmenter la résilience de l’authentification et de l’autorisation dans les applications clientes que vous développez pour obtenir des conseils lorsque vous ne développez pas sur MSAL.

Microsoft Entra ID implémente un point de terminaison UserInfo dans le cadre de la prise en charge des normes OIDC par Microsoft Entra ID avec un chemin d’accès Microsoft Graph spécifique (https://graph.microsoft.com/oidc/userinfo). Il n’est pas possible d’ajouter ou de personnaliser les informations retournées par le point de terminaison UserInfo. Les informations contenues dans le jeton d’ID étant un surensemble des informations retournées par l’appel au point de terminaison UserInfo, nous vous recommandons d’utiliser le jeton d’ID plutôt que d’appeler le point de terminaison UserInfo.

Authentifier des utilisateurs

Les applications interagissent avec les locataires Microsoft Entra ID pour authentifier les utilisateurs. Pour authentifier un utilisateur, une application dirige un navigateur vers https://login.microsoftonline.com/{tenant}/v2.0, où {tenant} est l’ID ou le domaine du locataire. Toutefois, nous recommandons aux éditeurs de logiciels indépendants d’utiliser Microsoft Entra ID pour créer des applications multilocataires capables de prendre en charge la plus large gamme de clients. Une application multilocataire peut ne pas connaître le locataire d’un utilisateur tant que celui-ci ne s’est pas authentifié. Il n’est donc pas possible d’utiliser un point de terminaison de locataire spécifique.

Pour activer les applications multilocataires, Microsoft Entra ID fournit deux points de terminaison OIDC/OAuth 2.0 indépendants du locataire :

  • https://login.microsoftonline.com/common/v2.0 permet aux utilisateurs d’authentifier une application lorsqu’ils proviennent d’un locataire Microsoft Entra ID quelconque ou lorsqu’ils ont un compte Microsoft consommateur de sites tels qu’outlook.com, skype.com, xbox.com, live.com ou Hotmail.com.
  • https://login.microsoftonline.com/organizations/v2.0 permet aux utilisateurs d’authentifier une application lorsqu’ils proviennent de tout locataire Microsoft Entra ID.

Ces points de terminaison permettent à n’importe quel utilisateur de n’importe quel locataire Microsoft Entra ID d’authentifier votre application. Si vous souhaitez autoriser uniquement les utilisateurs provenant de locataires spécifiques, implémentez la logique nécessaire pour autoriser uniquement les utilisateurs de ces locataires à accéder à votre application. L’implémentation normale consiste à filtrer les utilisateurs en fonction de la revendication iss (émetteur) ou tid (ID de locataire) dans le jeton dans une liste verte de locataires que vous gérez.

Les locataires Microsoft Entra ID prennent en charge les utilisateurs qui peuvent être des membres réguliers ou des utilisateurs invités du locataire. Par défaut, les utilisateurs invités d’un locataire ont des capacités limitées. Par exemple, les utilisateurs invités ne peuvent pas voir le profil complet d’autres utilisateurs dans le locataire. Les utilisateurs invités, parfois appelés utilisateurs B2B (Business to Business), permettent à différentes organisations de collaborer avec des outils et des services protégés par Microsoft Entra ID. Un exemple de scénario serait l’invitation d’un utilisateur extérieur à votre organisation à accéder à un fichier SharePoint dans votre locataire. En règle générale, les utilisateurs B2B utilisent leur adresse e-mail en guise de userid. Toutefois, ils peuvent utiliser cette même adresse en tant que userid dans leur locataire d’origine. Par défaut, Microsoft Entra ID connecte l’utilisateur à son locataire d’origine lorsqu’il entre son userid.

Pour connecter un utilisateur en tant qu’utilisateur B2B, une application doit utiliser le point de terminaison de locataire spécifique où l’utilisateur est invité. Bien qu’il soit possible pour un utilisateur de spécifier un locataire auquel il souhaite accéder lorsqu’une application utilise le point de terminaison https://login.microsoftonline.com/organizations/v2.0, les utilisateurs peuvent avoir des difficultés à découvrir cette fonctionnalité.

Étapes suivantes