Guide du développeur pour l’accès conditionnel à Microsoft Entra

  • Article

La fonctionnalité d’accès conditionnel dans Microsoft Entra ID constitue l’un des moyens de sécuriser votre application et de protéger un service. L’accès conditionnel permet aux développeurs et aux clients d’entreprise de protéger les services dans une multitude de façons, notamment :

  • Authentification multifacteur
  • Autoriser uniquement les appareils inscrits sur Intune inscrit pour accéder aux services spécifiques
  • Restriction des plages IP et emplacements utilisateur

Pour plus d’informations sur toutes les fonctionnalités de l’accès conditionnel, consultez Qu’est-ce que l’accès conditionnel.

Destiné aux développeurs créant des applications pour Microsoft Entra ID, cet article montre comment utiliser l’accès conditionnel et explique l’impact de l’accès à des ressources non contrôlées auxquelles des stratégies d’accès conditionnel sont peut-être appliquées. Cet article explore également les implications de l’accès conditionnel dans les applications web et le flux On-Behalf-Of accédant à Microsoft Graph et appelant des API.

Supposons une connaissance des applications uniques et multilocataires, ainsi que des modèles courants d’authentification.

Remarque

L’utilisation de cette fonctionnalité nécessite une licence Microsoft Entra ID P1. Pour trouver la licence appropriée à vos besoins, consultez Comparaison des fonctionnalités mises à la disposition générale des éditions gratuite, de base et Premium. Les clients avec des licences Microsoft 365 Business ont également accès aux fonctionnalités d’accès conditionnel.

Comment l’accès conditionnel impacte-t-il une application ?

Incidence sur les types d’application

Dans la plupart des cas, l’accès conditionnel ne change ni le comportement d’une application ni n’exige de modification de la part du développeur. Uniquement dans certains cas, lorsqu’une application en mode silencieux ou indirectement demande un jeton pour un service, une application requiert des modifications du code pour gérer les défis d’accès conditionnel. Cela peut être aussi simple que l’exécution d’une demande de connexion interactive.

Plus précisément, les scénarios suivants requièrent un code pour gérer les défis d’accès conditionnel :

  • Applications effectuant le flux Pour le compte de
  • Applications accédant à plusieurs services/ressources
  • Applications monopages utilisant MSAL.js
  • Les applications appelant une ressource

Les stratégies d’accès conditionnel peuvent être appliquées à l’application, mais peuvent également être appliquées à une API web à laquelle votre application a accès. Pour en savoir plus sur la façon de configurer une stratégie d’accès conditionnel, consultez Démarrage rapide : Demander une authentification multifacteur (MFA) pour des applications spécifiques disposant d’un accès conditionnel à Microsoft Entra.

Selon le scénario, un client d’entreprise peut appliquer et supprimer des stratégies d’accès conditionnel à tout moment. Afin que votre application continue à fonctionner correctement lorsqu’une nouvelle stratégie est appliquée, implémentez la gestion de défis. Les exemples suivants illustrent la gestion des défis.

Exemples d’accès conditionnel

Certains scénarios requièrent des modifications de code pour gérer l’accès conditionnel, tandis que d’autres travaillent tel quel. Voici quelques scénarios d’utilisation de l’accès conditionnel pour effectuer une authentification multifacteur qui donne un aperçu de la différence.

  • Vous générez une application iOS de client unique et appliquez une stratégie d’accès conditionnel. L’application connecte un utilisateur et ne demande pas l’accès à une API. Quand l’utilisateur se connecte, la stratégie est appelée automatiquement et l’utilisateur doit effectuer l’authentification multifacteur (MFA).
  • Vous générez une application native qui utilise un service de niveau intermédiaire pour accéder à une API en aval. Un client d’entreprise de la société utilisant cette application applique une stratégie à l’API en aval. Quand un utilisateur final se connecte, l’application native demande l’accès au niveau intermédiaire et envoie le jeton. Le niveau intermédiaire effectue le flux Pour le compte pour demander l’accès à l’API en aval. À ce stade, un défi de « revendications » est présenté au niveau intermédiaire. Le niveau intermédiaire renvoie la demande à l’application native, qui doit se conformer à la stratégie d’accès conditionnel.

Microsoft Graph

Microsoft Graph possède des considérations spéciales concernant la création d’applications des environnements avec accès conditionnel. En règle générale, les mécanismes d’accès conditionnel ont le même comportement, mais les stratégies que voient vos utilisateurs sont basées sur les données sous-jacentes demandées au graph par votre application.

Plus précisément, toutes les étendues de Microsoft Graph représentent un jeu de données auquel il est possible d’appliquer des stratégies individuellement. Dans la mesure où les stratégies d’accès conditionnel sont attribuées à des jeux de données spécifiques, Microsoft Entra ID applique des stratégies d’accès conditionnel basées sur les données derrière Graph, plutôt que sur Graph.

Par exemple, si une application demande les étendues suivantes de Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

Une application peut s’attendre à ce que ses utilisateurs répondent à toutes les stratégies définies sur Teams et Exchange. Certaines étendues peuvent mapper vers plusieurs jeux de données si elles disposent de l’accès.

Conformité à une stratégie d’accès conditionnel

Pour différentes topologies d’applications, une stratégie d’accès conditionnel est évaluée lorsque la session est établie. Étant donné qu’une stratégie d’accès conditionnel fonctionne sur la granularité des applications et des services, le point sur lequel elle est appelée dépend essentiellement du scénario que vous essayez d’accomplir.

Lorsque votre application tente d’accéder à un service avec une stratégie d’accès conditionnel, elle peut rencontrer un défi d’accès conditionnel. Ce défi est encodé dans le paramètre claims qui est fourni dans une réponse de Microsoft Entra ID. Voici un exemple de ce paramètre de défi :

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Les développeurs peuvent prendre ce défi et l’ajouter à une nouvelle requête à Microsoft Entra ID. Le fait de passer cet état invite l’utilisateur final à exécuter toute action nécessaire pour se conformer à la stratégie d’accès conditionnel. Les scénarios suivants expliquent les détails de l’erreur et le mode d’extraction du paramètre.

Scénarios

Prérequis

L’accès conditionnel à Microsoft Entra est une fonctionnalité incluse dans Microsoft Entra ID P1 ou P2. Les clients avec des licences Microsoft 365 Business ont également accès aux fonctionnalités d’accès conditionnel.

Considérations pour des scénarios spécifiques

Les informations suivantes s’appliquent uniquement dans ces scénarios d’accès conditionnel :

  • Applications effectuant le flux Pour le compte de
  • Applications accédant à plusieurs services/ressources
  • Applications monopages utilisant MSAL.js

Les sections suivantes décrivent des scénarios courants plus complexes. Le principe de fonctionnement central est que les stratégies d’accès conditionnel sont évaluées au moment où le jeton est demandé pour le service qui contient une stratégie d’accès conditionnel.

Scénario : application effectuant le flux Pour le compte de

Dans ce scénario, nous abordons le cas dans lequel une application native appelle une API/ service Web. À son tour, ce service exécute le flux On-Behalf-Of pour appeler un service en aval. Dans notre cas, nous avons appliqué notre stratégie d’accès conditionnel pour le service en aval (API Web 2) et nous utilisons une application native plutôt qu’une application démon/serveur.

App performing the on-behalf-of flow diagram

La demande de jeton initiale pour l’API Web 1 n’affiche aucune invite pour l’utilisateur final en lien avec l’authentification multifacteur, car l’API Web 1 ne peut pas toujours atteindre l’API en aval. Quand l’API Web 1 essaye de demander un jeton flux pour le compte de l’utilisateur pour l’API Web 2, la demande échoue, car l’utilisateur ne s’est pas connecté avec l’authentification multifacteur.

Microsoft Entra ID renvoie une réponse HTTP avec des données intéressantes :

Remarque

Dans cette instance, il s’agit d’une description d’erreur de l’authentification multifacteur, mais il existe une large gamme de interaction_required possible concernant l’accès conditionnel.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Dans l’API Web 1, nous interceptons l’erreur error=interaction_required, et renvoyons le défi claims à l’application de bureau. À ce stade, l’application de bureau peut effectuer un nouvel appel acquireToken() et ajouter le défi claims comme un paramètre de chaîne de requêtes supplémentaire. Cette nouvelle demande oblige l’utilisateur à effectuer une authentification multifacteur et à renvoyer ce nouveau jeton à l’API Web 1, puis exécuter le flux pour le compte de.

Pour tester ce scénario, consultez notre exemple de code .NET. Il indique comment repasser le défi de revendications à partir d’API Web 1 vers l’application native et construire une nouvelle demande à l’intérieur de l’application cliente.

Scénario : application accédant à plusieurs services

Dans ce scénario, nous abordons le cas dans lequel une application Web accède aux deux services, dont un d’entre eux est affecté à une stratégie d’accès conditionnel. En fonction de votre logique d’application, il peut exister un chemin d’accès dans lequel votre application ne nécessite pas l’accès aux deux services Web. Dans ce scénario, l’ordre dans lequel vous demandez un jeton joue un rôle important dans l’expérience de l’utilisateur final.

Supposons que nous disposons d’un service Web A et B et que le service Web B applique notre stratégie d’accès conditionnel. Tandis que la demande initiale d’authentification interactive requiert le consentement pour les deux services, la stratégie d’accès conditionnel n’est pas requise dans tous les cas. Si l’application demande un jeton pour le service Web B, la stratégie est appelée et les demandes ultérieures pour le service Web A réussissent également comme suit.

App accessing multiple-services flow diagram

Sinon, si l’application demande initialement un jeton pour le service Web A, l’utilisateur final n’appelle pas la stratégie d’accès conditionnel. Cela permet au développeur d’applications de contrôler l’expérience de l’utilisateur final et de ne pas forcer l’appel de la stratégie d’accès conditionnel dans tous les cas. Cela se complique si l’application demande ensuite un jeton pour le service web B. À ce stade, l’utilisateur final doit se conformer à la stratégie d’accès conditionnel. Lorsque l’application tente de acquireToken, cela peut générer l’erreur suivante (illustrée dans le diagramme suivant) :

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Si l’application utilise la bibliothèque MSAL, un échec d’acquisition du jeton est toujours retenté interactivement. Lorsque cette demande interactive se produit, l’utilisateur final a la possibilité de se conformer à l’accès conditionnel. Cela est vrai, sauf si la demande est un AcquireTokenSilentAsync ou PromptBehavior.Never et dans ce cas, l’application doit effectuer une demande interactive AcquireToken pour permettre à l’utilisateur final de se conformer à la stratégie.

Scénario : Application monopage (SPA) utilisant MSAL.js

Dans ce scénario, nous abordons le cas d’une application monopage (SPA) appelant une API web protégée par l’accès conditionnel à l’aide de MSAL.js. Il s’agit d’une architecture simple mais avec des nuances qui doivent être prises en compte lors du développement autour de l’accès conditionnel.

Dans MSAL.js, plusieurs fonctions obtiennent des jetons : acquireTokenSilent(), acquireTokenPopup() et acquireTokenRedirect().

  • acquireTokenSilent() peut être utilisé pour obtenir silencieusement un jeton d’accès, c'est-à-dire qu’il n’affiche pas l’interface utilisateur dans tous les cas.
  • acquireTokenPopup() et acquireTokenRedirect() sont tous deux utilisés pour demander interactivement un jeton pour une ressource, ce qui signifie qu’ils affichent toujours l’interface utilisateur de connexion.

Lorsqu’une application a besoin d’un jeton d’accès pour appeler une API web, elle tente une acquireTokenSilent(). Si le jeton a expiré ou si nous devons nous conformer à une stratégie d’accès conditionnel, la fonction acquireToken échoue et l’application utilise acquireTokenPopup() ou acquireTokenRedirect().

Single-page app using MSAL flow diagram

Examinons un exemple avec notre scénario d’accès conditionnel. L’utilisateur final a simplement accédé au site et n’a pas de session. Nous effectuons un appel loginPopup() et obtenons un jeton d’ID sans authentification multifacteur. Puis l’utilisateur final appuie sur un bouton qui exige que l’application demande des données depuis une API Web. L’application tente d’effectuer un appel acquireTokenSilent() mais échoue, étant donné que l’utilisateur n’a pas encore effectué l’authentification multifacteur et doit se conformer à la stratégie d’accès conditionnel.

Microsoft Entra ID renvoie la réponse HTTP suivante :

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Notre application a besoin d’intercepter le error=interaction_required. L’application peut alors utiliser acquireTokenPopup() ou acquireTokenRedirect() sur la même ressource. L’utilisateur est obligé d’effectuer une authentification multifacteur. Une fois que l’utilisateur a terminé l’authentification multifacteur, l’application émet un nouveau jeton d’accès pour la ressource demandée.

Pour tester ce scénario, consultez notre exemple de code React SPA appelant l’API web Node.js à l’aide du flux On-Behalf-Of. Cet exemple de code utilise la stratégie d’accès conditionnel et l’API Web précédemment inscrites avec un React SPA pour illustrer ce scénario. Il explique comment gérer correctement le défi de revendications et obtenir un jeton d’accès qui peut être utilisé pour votre API web.

Voir aussi