Conseils aux développeurs pour l’accès conditionnel Microsoft Entra

S’applique à : Locataires d'entreprise Locataires externes (en savoir plus)

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 à accéder à des services spécifiques
• Restriction des emplacements utilisateur et des plages IP

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.

Il suppose une connaissance des applications mono-abonné et multi-abonnés, ainsi que des modèles courants d’authentification.

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

Incidence sur les types d’application

Dans les cas les plus courants, l’accès conditionnel ne modifie pas le comportement d’une application ou nécessite des modifications 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 des défis d’accès conditionnel :

• Applications exécutant le flux On-Behalf-Of
• Applications accédant à plusieurs services/ressources
• Applications monopages utilisant MSAL.js
• Les applications web 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 configuration d’une stratégie d’accès conditionnel, consultez Démarrage rapide : exiger une authentification multifacteur (MFA) pour des applications spécifiques avec 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 utilisant l’accès conditionnel pour effectuer une authentification multifacteur qui donne un aperçu de la différence.

• Vous développez une application iOS pour un seul client et appliquez une Stratégie d'Accès Conditionnel. L’application connecte un utilisateur et ne demande pas l’accès à une API. Lorsque l’utilisateur se connecte, la stratégie est appelée automatiquement et l’utilisateur doit effectuer l’authentification multifacteur (MFA).
• Vous créez 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 On-Behalf-Of pour demander l’accès à l’API en aval. À ce stade, un « défi » lié aux réclamations 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. Étant donné que les stratégies d’accès conditionnel sont affectées aux jeux de données spécifiques, l’ID Microsoft Entra applique des stratégies d’accès conditionnel basées sur les données derrière Graph, plutôt que sur Graph elle-même.

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 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 demande à 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

Conditions préalables

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 exécutant le flux On-Behalf-Of
• 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 exécutant le flux On-Behalf-Of

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.

La demande de jeton initiale pour l’API Web 1 n’invite pas l’utilisateur final à l’authentification multifacteur, car l’API web 1 peut ne pas toujours atteindre l’API en aval. Une fois que l’API web 1 tente de demander un jeton au nom de l’utilisateur pour l’API web 2, la requête échoue depuis que l’utilisateur n’a pas connecté avec l’authentification multifacteur.

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

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 multifactor 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 On-Behalf-Of.

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 alors appliquée, et par conséquent, les demandes suivantes pour le service Web A réussissent également ainsi.

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. Le cas délicat est si l’application demande ultérieurement 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 multifactor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

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 donner à l'utilisateur final la possibilité de se conformer à la politique.

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() permet d’obtenir silencieusement un jeton d’accès. Autrement dit, il n’affiche en aucun cas l’IU.
• 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().

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 et obtenons un jeton d’ID loginPopup() 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, mais échoue, car l’utilisateur n’a pas encore effectué l’authentification acquireTokenSilent() 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 multifactor 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 forcé d’effectuer une authentification multifacteur. Une fois que l’utilisateur a terminé l’authentification multifacteur, l’application a émis un nouveau jeton d’accès pour la ressource demandée.

Pour tester ce scénario, consultez notre exemple de code Application monopage React appelant l’API web Node.js à l’aide du flux On-Behalf-Of. Cet exemple de code illustre ce scénario à l’aide de la stratégie d’accès conditionnel et de l’API web précédemment inscrites avec une application monopage React. 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

• Pour en savoir plus sur les fonctionnalités, consultez Accès conditionnel dans Microsoft Entra ID.
• Pour obtenir d’autres exemples de code Microsoft Entra, consultez les exemples.
• Pour plus d’informations sur les kits SDK MSAL et accéder à la documentation de référence, consultez la vue d’ensemble de la bibliothèque d’authentification Microsoft.
• Pour en savoir plus sur les scénarios multilocataires, consultez Comment connecter des utilisateurs à l’aide du modèle multilocataire.
• Découvrez-en plus sur l’accès conditionnel et la sécurisation de l’accès aux applications IoT.