Quelles sont les nouveautés en matière d’authentification ?

Microsoft ajoute et modifie régulièrement des fonctions et fonctionnalités de la plateforme d’identités Microsoft pour améliorer sa sécurité, son utilisabilité et sa conformité aux normes.

Sauf indication contraire, les modifications décrites ici s’appliquent uniquement aux applications inscrites après la date d’effet indiquée.

Consultez régulièrement cet article pour découvrir :

• Les problèmes connus et les corrections
• Changements de protocole
• Fonctionnalités dépréciées

Août 2024

Les informations d’identification de l’identité fédérée utilisent désormais la correspondance respectant la casse

Date d’effet : septembre 2024

Protocole affecté : Fédération des identités de charge de travail

Changer

Auparavant, lors de la mise en correspondance des informations d’identification de l’identité fédérée (FIC), issuersubjectet audience des valeurs par rapport aux valeurs correspondantesissuersubject, et audience les valeurs contenues dans le jeton envoyé à Microsoft Entra ID par un idP externe, la correspondance sans respect de la casse a été utilisée. Pour fournir un contrôle plus précis aux clients, nous basculons vers l’application de la correspondance respectant la casse.

Exemple non valide :

• Objet du jeton : repo:contoso/contoso-org:ref:refs/heads/main
• Objet FIC : repo:Contoso/Contoso-Org:ref:refs/heads/main

Ces deux valeurs d’objet ne correspondent pas sensiblement à la casse. Par conséquent, la validation échoue. Le même mécanisme est appliqué à et audience à issuer la validation.

Cette modification est appliquée initialement aux applications ou aux identités managées créées après August 14th, 2024. Les applications inactives ou les identités managées, déterminées par l’absence de demandes de fédération d’identité de charge de travail effectuées par l’application ou l’identité managée entre la période et la période August 1st, 2024 August 31st, 2024, sont requises pour utiliser des correspondances sensibles à la casse.September 27th, 2024 Pour les applications actives, la correspondance ne respectant pas la casse se produit à une date ultérieure à communiquer.

Pour mieux mettre en évidence les échecs en raison de l’insensitivité de la casse, nous réorganisons le message d’erreur pour AADSTS700213. Il va maintenant indiquer ;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

L’espace réservé '{subject}' fournit la valeur de la revendication d’objet contenue dans le jeton envoyé du fournisseur d’identité externe à l’ID Microsoft Entra. Ce modèle d’erreur est également utilisé pour les échecs qui ne respectent pas la casse et audience la issuer validation. Si vous rencontrez cette erreur, vous devez trouver les informations d’identification de l’identité fédérée qui correspond au , subjectou audience répertoriées dans l’erreur et confirmer que les valeurs correspondantes sont équivalentes du point de vue sensible à issuerla casse. S’il existe une incompatibilité, vous devez remplacer le , subjectou la valeur actuelle issuerdans le FIC par la issuervaleur , subjectou audience la valeur contenue dans le message d’erreuraudience.

Juin 2024

Les applications doivent être inscrites dans un annuaire

Date d’entrée en vigueur : juin 2024

Points de terminaison impactés : v2.0 et v1.0

Protocole impacté : Tous les flux

Changer

Auparavant, lors de l’inscription d’une application à l’aide de l’expérience d’inscriptions d’applications Microsoft Entra, si l’utilisateur était connecté avec son compte Microsoft personnel (MSA), il peut choisir d’associer uniquement l’application à son compte personnel. Cela signifie que l’application ne serait pas associée ou contenue dans un répertoire (également appelé « locataire » ou « organisation »). Toutefois, à compter de juin 2024, toutes les applications doivent être inscrites dans un annuaire. Il peut s’agir d’un répertoire existant ou d’un nouvel annuaire créé par l’utilisateur de compte Microsoft personnel pour héberger ses applications Microsoft Entra et d’autres ressources Microsoft. Les utilisateurs peuvent facilement créer un répertoire à utiliser à cet effet en joignant le Programme microsoft 365 développeur ou en vous inscrivant à Azure.

L’inscription d’une application dans un répertoire, au lieu de l’associer à un compte personnel, présente différents avantages. Il s’agit notamment des paramètres suivants :

• Les applications inscrites dans un annuaire ont plus de fonctionnalités à leur disposition, telles que la possibilité d’ajouter plusieurs propriétaires à l’application et la possibilité de vérifier l’application.
• L’application se trouve au même endroit que d’autres ressources Microsoft utilisées par le développeur, telles que les ressources Azure.
• L’application reçoit des avantages améliorés en matière de résilience.

Cela n’affectera aucune application existante, y compris les applications existantes qui ne sont associées qu’à un compte personnel. Seule la possibilité d’inscrire de nouvelles applications est affectée.

Octobre 2023

Invite d’expérience utilisateur RemoteConnect mise à jour

Date d’effet : octobre 2023

Points de terminaison impactés : v2.0 et v1.0

Protocole affecté : RemoteConnect

RemoteConnect est un flux inter-appareils utilisé pour les scénarios associés au répartiteur d’authentification Microsoft et à Microsoft Intune impliquant des jetons d’actualisation principaux. Pour éviter les attaques par hameçonnage, le flux RemoteConnect reçoit le langage d’expérience utilisateur mis à jour pour appeler que l’appareil distant (l’appareil qui a lancé le flux) pourra accéder à toutes les applications utilisées par votre organisation à la fin du flux.

L’invite qui s’affiche ressemblera à ceci :

Juin 2023

Omission des revendications d’e-mail avec un propriétaire de domaine non vérifié

Date d’effet : juin 2023

Points de terminaison impactés : v2.0 et v1.0

Changement

Pour des applications multi-tenant, les e-mails qui ne sont pas vérifiés par le propriétaire du domaine sont omis par défaut lorsque la revendication facultative email est demandée dans une charge utile de jeton.

Un e-mail est considéré comme vérifié par le propriétaire du domaine si :

1. Le domaine appartient au tenant où réside le compte d’utilisateur et l’administrateur du tenant a effectué la vérification du domaine.
2. L’e-mail provient d’un compte Microsoft (MSA).
3. L’e-mail provient d’un compte Google.
4. L’e-mail a été utilisé pour l’authentification à l’aide du flux de code secret à usage unique (OTP).

Il convient également de noter que les comptes Facebook et SAML/WS-Fed n’ont pas de domaines vérifiés.

Mai 2023

Le rôle d’administrateur Power BI sera renommé Administrateur Fabric.

Date d’effet : juin 2023

Points de terminaison impactés :

• Liste roleDefinitions - Microsoft Graph v1.0
• Liste directoryRoles - Microsoft Graph v1.0

Changer

Le rôle Administrateur Power BI est renommé Administrateur de l’infrastructure.

Le 23 mai 2023, Microsoft a dévoilé Microsoft Fabric, qui fournit une expérience d’intégration de données basée sur Data Factory, l’engineering données basé sur Synapse, les entrepôts de données, la science des données et des expériences d’analytique en temps réel, ainsi que sur l’analyse décisionnelle (BI) avec Power BI, le tout hébergé sur une solution SaaS centrée sur un lac de données. L’administration des locataires et des capacités pour ces expériences est centralisée dans le portail d’administration Fabric (anciennement portail d’administration Power BI).

À compter de juin 2023, le rôle Administrateur Power BI est renommé Administrateur fabric pour s’aligner sur l’étendue et la responsabilité changeantes de ce rôle. Toutes les applications, y compris Microsoft Entra ID, les API Microsoft Graph, Microsoft 365 et GDAP, commenceront à refléter ce nouveau nom de rôle au bout de plusieurs semaines.

Pour rappel, le code et les scripts de votre application ne doivent pas prendre de décisions en fonction du nom d’un rôle ou de son nom d’affichage.

Décembre 2021

Les utilisateurs AD FS voient davantage d’invites de connexion pour s’assurer que l’utilisateur approprié est connecté.

Date d’effet : décembre 2021

Points de terminaison concernés : Authentification Windows intégrée

Protocole concerné : Authentification Windows intégrée

Changement

Aujourd’hui, quand un utilisateur est envoyé à AD FS pour s’authentifier, il est connecté en mode silencieux à un compte qui a déjà une session avec AD FS. La connexion silencieuse se produit même si l’utilisateur est censé se connecter à un compte d’utilisateur différent. Pour réduire la fréquence de cette connexion incorrecte, depuis décembre, Microsoft Entra ID envoie le paramètre prompt=login à AD FS si le gestionnaire de comptes web dans Windows fournit à Microsoft Entra ID un login_hint pendant la connexion, indiquant qu’un utilisateur spécifique est souhaité pour la connexion.

Quand les conditions ci-dessus sont remplies (WAM est utilisé pour diriger l’utilisateur vers Microsoft Entra ID afin qu’il se connecte, un login_hint est inclus et l’instance AD FS pour le domaine de l’utilisateur prend en charge prompt=login), l’utilisateur n’est pas connecté en mode silencieux, mais invité à fournir un nom d’utilisateur pour continuer à se connecter à AD FS. S’il souhaite se connecter à sa session AD FS existante, il peut sélectionner l’option « Continuer en tant qu’utilisateur actuel » affichée sous l’invite de connexion. Dans le cas contraire, il peut continuer avec le nom d’utilisateur qu’il a l’intention d’utiliser pour se connecter.

Cette modification sera déployée en décembre 2021 sur plusieurs semaines. Elle ne change pas le comportement des connexions pour les :

• applications utilisant directement IWA ;
• applications utilisant OAuth ;
• domaines non fédérés à une instance AD FS.

Octobre 2021

L’erreur 50105 a été corrigée pour ne pas renvoyer interaction_required pendant l’authentification interactive

Date d’effet : octobre 2021

Points de terminaison impactés : v2.0 et v1.0

Protocole concerné : Tous les flux d’utilisateur pour les applications nécessitant une attribution d’utilisateurs

Changement

L’erreur 50105 (la désignation actuelle) est émise lorsqu’un utilisateur non attribué tente de se connecter à une application qu’un administrateur a marqué comme nécessitant une attribution d’utilisateurs. Il s’agit d’un modèle de contrôle d’accès courant, et les utilisateurs doivent souvent trouver un administrateur pour demander une attribution afin de débloquer l’accès. L’erreur comportait un bogue qui provoquait des boucles infinies dans les applications bien codées qui traitaient correctement la réponse d’erreur interaction_required. interaction_required indique à une application d’effectuer une authentification interactive, mais, même après avoir effectué cette opération, Microsoft Entra ID renvoie toujours une réponse d’erreur interaction_required.

Le scénario d’erreur a été mis à jour. Ainsi, lors de l’authentification non interactive (où prompt=none est utilisé pour masquer l’expérience utilisateur), l’application est invitée à effectuer une authentification interactive à l’aide d’une réponse d’erreur interaction_required. Lors de l’authentification interactive suivante, Microsoft Entra ID retiendra désormais l’utilisateur et affichera directement un message d’erreur, empêchant ainsi une boucle de se produire.

Rappel : Votre code d’application ne doit pas prendre de décisions basées sur des chaînes de code d’erreur comme AADSTS50105. Suivez plutôt nos conseils de gestion des erreurs et utilisez les réponses d’authentification standardisées comme interaction_required et login_required qui se trouvent dans le champ error standard de la réponse. Les autres champs de réponse sont destinés uniquement à la consommation par les humains qui résolvent leurs problèmes.

Vous pouvez consulter le texte actuel de l’erreur 50105 et d’autres informations sur le service de recherche d’erreurs : https://login.microsoftonline.com/error?code=50105.

Dans les applications à locataire unique, l’URI AppId nécessite l’utilisation du schéma par défaut ou des domaines vérifiés

Date d’effet : octobre 2021

Points de terminaison impactés : v2.0 et v1.0

Protocole impacté : Tous les flux

Changer

Pour les applications à locataire unique, l’ajout ou la mise à jour de l’URI AppId confirme que le domaine de l’URI de schéma HTTPS est répertorié dans la liste des domaines vérifiés dans le locataire client ou que la valeur utilise le schéma par défaut (api://{appId}) fourni par Microsoft Entra ID. Ceci pourrait empêcher les applications d’ajouter un URI AppId si le domaine ne se trouve pas dans la liste des domaines vérifiés ou si la valeur n’utilise pas le schéma par défaut. Pour plus d’informations sur les domaines vérifiés, reportez-vous à la documentation sur les domaines personnalisés.

Le changement n’affecte pas les applications existantes qui utilisent des domaines non vérifiés dans leur URI AppId. Il valide uniquement les nouvelles applications ou quand une application existante met à jour un URI d’identificateur ou en ajoute un nouveau à la collection identifierUri. Les nouvelles restrictions s’appliquent uniquement aux URI ajoutés à la collection identifierUris d’une application après le 15 octobre 2021. Les URI AppId qui se trouvent déjà dans la collection identifierUris d’une application quand la restriction prend effet le 15 octobre 2021 continueront de fonctionner même si vous ajoutez de nouveaux URI à cette collection.

Si la vérification de validation d’une demande échoue, l’API d’application pour créer/mettre à jour retourne 400 badrequest au client, indiquant HostNameNotOnVerifiedDomain.

L’API et les formats d’URI d’ID d’application basée sur le schéma HTTP suivants sont pris en charge. Remplacez les valeurs d’espace réservé comme décrit dans la liste qui suit le tableau.

ID d’application pris en charge Formats d’URI	Exemples d’URI d’ID d’application
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> : propriété d’identificateur d’application (appId) de l’objet application.
• <string> : valeur de chaîne pour l’hôte ou le segment de chemin d’accès de l’API.
• <tenantId> : GUID généré par Azure pour représenter le locataire dans Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, où <tenantInitialDomain> est le nom de domaine initial que le créateur du locataire a spécifié lors de la création du locataire.
• <verifiedCustomDomain> : domaine personnalisé vérifié configuré pour votre tenant Microsoft Entra.

Août 2021

L’accès conditionnel se déclenchera uniquement pour les étendues demandées explicitement

Date d’effet : août 2021, avec un lancement progressif à partir d’avril.

Points de terminaison impactés : v2.0

Protocole impacté : tous les flux utilisant le consentement dynamique

Les applications qui utilisent le consentement dynamique bénéficient aujourd’hui de toutes les autorisations pour lesquelles elles ont reçu un consentement, même si elles n’ont pas été demandées nominativement dans le paramètre scope. Une application demandant uniquement user.read mais avec un consentement à files.read peut être forcée à répondre à l’exigence d’accès conditionnel affectée pour files.read, par exemple.

Afin de réduire le nombre d’invites d’accès conditionnel inutiles, Microsoft Entra ID change la façon dont les étendues sont fournies aux applications pour que seules les étendues demandées explicitement déclenchent l’accès conditionnel. Les applications qui se basent sur le comportement précédent de Microsoft Entra ID consistant à inclure toutes les étendues dans le jeton, qu’elles soient demandées ou non, peuvent se casser en raison d’étendues manquantes.

Les applications recevront désormais des jetons d’accès avec une combinaison d’autorisations : les jetons demandés et celles qui ont le consentement adéquat qui n’exigent pas d’invite d’accès conditionnel. L’étendue de l’accès du jeton est reflétée dans le paramètre scope de la réponse du jeton.

Cette modification sera appliquée à toutes les applications, à l’exception de celles qui dépendent de ce comportement. Les développeurs recevront une sensibilisation s'ils sont exemptés de ce changement, car ils peuvent dépendre des invites d'accès conditionnel supplémentaires.

Exemples

Une application a le consentement pour user.read, files.readwrite et tasks.read. Des stratégies d’accès conditionnel sont appliquées à files.readwrite, mais pas aux deux autres. Si une application émet une demande de jeton pour scope=user.read et que l’utilisateur actuellement connecté n’a pas passé de stratégie d’accès conditionnel, le jeton obtenu sera valable pour les autorisations user.read et tasks.read. tasks.read est inclus parce que l’application a le consentement pour cette autorisation et ne nécessite pas la mise en application d’une stratégie d’accès conditionnel.

Si l’application demande ensuite scope=files.readwrite, l’accès conditionnel requis par le locataire se déclenche, forçant l’application à afficher une invite d’authentification interactive permettant de satisfaire la stratégie d’accès conditionnel. Le jeton retourné inclura les trois étendues.

Si l’application émet ensuite une dernière demande pour l’une des trois étendues (par exemple, scope=tasks.read), Microsoft Entra ID déterminera que l’utilisateur a déjà satisfait aux stratégies d’accès conditionnel nécessaires pour files.readwrite et émettra de nouveau un jeton incluant les trois autorisations.

Juin 2021

L’expérience utilisateur du flux de code d’appareil inclut désormais une invite de confirmation d’application

Date d’effet : juin 2021

Points de terminaison impactés : v2.0 et v1.0

Protocole affecté: le flux de code d’appareil

Pour éviter les attaques par hameçonnage, le flux de code d’appareil inclut désormais une invite qui valide que l’utilisateur se connecte à l’application attendue.

L’invite qui s’affiche ressemble à ceci :

Mai 2020

Résolution de bogue : Microsoft Entra ID n’encodera plus le paramètre d’état dans l’URL à deux reprises

Date d’effet : mars 2021

Points de terminaison impactés : v1.0 et v2.0

Protocole impacté : Tous les flux qui visitent le point de terminaison /authorize (flux de code d’autorisation et flux implicite)

Un bogue a été trouvé et résolu dans la réponse d’autorisation Microsoft Entra ID. Lors de l’étape /authorize de l’authentification, le paramètre state de la demande est inclus dans la réponse pour préserver l’état de l’application et empêcher les attaques CSRF. Microsoft Entra ID a incorrectement codé l’URL du paramètre state avant de l’insérer dans la réponse, où elle a été encodée une fois de plus. En conséquence, les applications ne rejetaient pas correctement la réponse de Microsoft Entra ID.

Microsoft Entra ID ne codera plus ce paramètre deux fois, ce qui permettra aux applications d’analyser correctement le résultat. Cette modification sera appliquée à toutes les applications.

Les points de terminaison Azure Government changent

Date d’effet : 5 mai 2020 (fin en juin 2020)

Points de terminaison impactés : Tous

Protocole impacté : Tous les flux

Le 1er juin 2018, l’adresse de l’autorité officielle Microsoft Entra pour Azure Government est passée de https://login-us.microsoftonline.com à https://login.microsoftonline.us. Cette modification s’applique également à Microsoft 365 GCC High et DoD, également gérés par Azure Government Microsoft Entra ID. Si vous possédez une application au sein d’un locataire US Government, vous devez mettre à jour votre application pour qu’elle connecte les utilisateurs sur le point de terminaison .us.

Le 5 mai 2020, Microsoft Entra ID commence à appliquer le changement de point de terminaison en empêchant les utilisateurs gouvernementaux de se connecter à des applications hébergées dans des locataires US Government à l’aide du point de terminaison public (microsoftonline.com). Les applications impactées commenceront à afficher une erreur AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Cette erreur indique que l’application tente de se connecter à un utilisateur US Government sur le point de terminaison du cloud public. Si votre application se trouve dans un locataire de cloud public et est destinée à prendre en charge les utilisateurs US Government, vous devrez mettre à jour votre application pour les prendre en charge explicitement. Cela peut nécessiter la création d’une nouvelle inscription d’application dans le cloud US Government.

L’application de cette modification sera effectuée à l’aide d’un déploiement progressif en fonction de la fréquence à laquelle les utilisateurs du cloud US Government se connectent à l’application : les applications connectant rarement des utilisateurs US Government verront la mise en œuvre d’abord, et les applications fréquemment utilisées par les utilisateurs US Government seront les dernières à voir l’application de la mise en œuvre. Nous nous attendons à ce que la mise en œuvre soit terminée sur toutes les applications en juin 2020.

Pour plus d’informations, consultez le billet de blog Azure Government sur cette migration.

Mars 2020

Les mots de passe utilisateur sont limités à 256 caractères.

Date d’effet : 13 mars 2020

Points de terminaison impactés : Tous

Protocole impacté : Tous les flux d’utilisateur.

Les utilisateurs avec des mots de passe de plus de 256 caractères qui se connectent directement à Microsoft Entra ID (pas un fournisseur d’identité fédéré, comme AD FS) sont invités à changer leur mot de passe avant de pouvoir se connecter. Les administrateurs peuvent recevoir des requêtes d’aide concernant la réinitialisation des mots de passe utilisateur.

L’erreur qui s’affiche dans les journaux de connexion ressemble à : AADSTS 50052: InvalidPasswordExceedsMaxLength.

Message : The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Correction :

L’utilisateur ne peut pas se connecter, car son mot de passe dépasse la longueur maximale autorisée. Il doit contacter son administrateur pour réinitialiser son mot de passe. Si le SSPR est activé pour son locataire, il peut réinitialiser son mot de passe en suivant le lien « Mot de passe oublié ? ».

Février 2020

Les fragments vides sont ajoutés à chaque redirection HTTP à partir du point de terminaison de connexion.

Date d’effet : 8 février 2020

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Les flux OAuth et OIDC qui utilisent response_type=query - cela couvre le flux du code d’autorisation dans certains cas, ainsi que le flux implicite.

Quand une réponse d’authentification est envoyée à partir de login.microsoftonline.com à une application via la redirection HTTP, le service ajoute un fragment vide à l’URL de réponse. Cela évite une classe d’attaques de redirection en garantissant que le navigateur efface tous les fragments existants dans la demande d’authentification. Aucune application ne doit dépendre de ce comportement.

Août 2019

La sémantique de formulaire POST sera appliquée plus rigoureusement, les espaces et les guillemets seront ignorés

Date d’effet : 2 septembre 2019

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Partout où POST est utilisé (informations d’identification du client, utilisation de code d’autorisation, ROPC, OBO et utilisation de jeton d’actualisation)

Depuis la semaine du 2 septembre 2019, les demandes d’authentification qui utilisent la méthode POST sont validées à l’aide de normes HTTP plus strictes. Plus précisément, les espaces et les guillemets doubles (") ne seront plus supprimés des valeurs du formulaire de demande. Ces modifications ne devraient pas bloquer les clients existants et permettent de s’assurer que les demandes envoyées à Microsoft Entra ID sont gérées de manière fiable à chaque fois. À l’avenir (voir ci-dessus), nous prévoyons également de rejeter les paramètres dupliqués et d’ignorer la marque d’ordre d'octet dans les demandes.

Exemple :

Aujourd’hui, ?e= "f"&g=h est analysé de la même façon que ?e=f&g=h, donc e == f. Avec ce changement, il est maintenant analysé comme e == "f". Il est peu probable que ce soit un argument valide, et la demande devrait maintenant échouer.

Juillet 2019

Les jetons d’application pour applications à locataire unique sont émis uniquement si l’application cliente existe dans le locataire de ressources

Date d’effet : 26 juillet 2019

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Informations d’identification du client (jetons d’application uniquement)

Une modification de sécurité a pris effet le 26 juillet 2019 qui change la façon dont sont émis les jetons d’application (via l’octroi d’informations d’identification du client). Auparavant, les applications étaient autorisées à obtenir des jetons pour appeler une autre application, quelle que soit la présence dans le locataire ou les rôles consentis pour cette application. Ce comportement a été mis à jour de sorte que, pour les ressources (parfois appelées API web) définies sur un locataire unique (valeur par défaut), l’application cliente doit exister dans le locataire de la ressource. Le consentement existant entre le client et l’API n’est toujours pas nécessaire, et les applications doivent toujours effectuer leurs propres vérifications d’autorisation pour s’assurer qu’une revendication roles est présente et contient la valeur attendue pour l’API.

Le message d’erreur de ce scénario indique actuellement :

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Pour résoudre ce problème, utilisez l’expérience de consentement de l’administrateur pour créer le principal du service de l’application cliente dans votre locataire, ou créez-le manuellement. Cette exigence garantit que le locataire a donné l’autorisation d’exécuter l’application au sein du locataire.

Exemple de requête

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... Dans cet exemple, le locataire de ressource (autorité) est contoso.com, l’application de ressource est une application à locataire unique appelée gateway.contoso.com/api pour le locataire Contoso, et l’application cliente est 00001111-aaaa-2222-bbbb-3333cccc4444. Si l’application cliente a un principal de service dans Contoso.com, cette demande peut continuer. Toutefois, si ce n’est pas le cas, la demande échoue avec l’erreur ci-dessus.

Si l’application de la passerelle Contoso était une application multilocataire, la requête continue, peu importe si l’application cliente a un principal de service ou non dans Contoso.com.

Les URI de redirection peuvent désormais contenir des paramètres de chaîne de requête

Date d’effet : 22 juillet 2019

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Tous les flux

Selon la norme RFC 6749, les applications Microsoft Entra ID peuvent désormais inscrire et utiliser des URI de redirection (de réponse) avec des paramètres de requêtes statiques (par exemple, https://contoso.com/oauth2?idp=microsoft) pour les requêtes OAuth 2.0. Les URI de redirection dynamiques sont toujours interdites, car elles représentent un risque pour la sécurité, et cela ne peut pas être utilisé pour conserver les informations d’état sur une demande d’authentification. Pour cela, utilisez le paramètre state.

Le paramètre de requête statique est soumis à la correspondance de chaînes pour les URI de redirection comme toute autre partie de l’URI de redirection. Si aucune chaîne n’est inscrite correspondant à la valeur redirect_uri décodée par l’URI, la demande est rejetée. Si l’URI est trouvée dans l’inscription de l’application, la chaîne entière sera utilisée pour rediriger l’utilisateur, y compris le paramètre de requête statique.

À ce jour (fin juillet 2019), l’expérience utilisateur de l’inscription d’applications dans le portail Azure bloque toujours les paramètres de requête. Toutefois, vous pouvez modifier le manifeste d’application manuellement pour ajouter des paramètres de requête et effectuer le test dans votre application.

Mars 2019

Le bouclage des clients sera interrompu

Date d’effet : 25 mars 2019

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Tous les flux

Les applications clientes peuvent parfois ne pas se comporter de manière adéquate, ce qui provoque l’envoi de centaines de demandes pour la même connexion pendant un bref laps de temps. Ces demandes peuvent réussir ou échouer, mais elles nuisent toutes à l’expérience utilisateur et alourdissent les charges de travail pour l’IDP, ce qui augmente la latence pour tous les utilisateurs et réduit la disponibilité de l’IDP. Ces applications fonctionnent hors des limites d’une utilisation normale et doivent être mises à jour pour qu’elles se comportent correctement.

Les clients qui émettent plusieurs fois des demandes dupliquées recevront une erreur invalid_grant : AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

La plupart des clients n’auront pas besoin de changer ce comportement pour éviter cette erreur. Seuls les clients mal configurés (ceux ne disposant pas d’une mise en cache des jetons ou présentant déjà des boucles d’invites) seront affectés par cette erreur. Les clients sont suivis localement (via des cookies) pour chaque instance individuelle en fonction des facteurs suivants :

• Conseils pour les utilisateurs, le cas échéant

• Étendues ou ressources demandées

• ID client

• URI de redirection

• Mode et type de réponse

Les applications émettant de nombreuses demandes (15 ou plus) dans un bref laps de temps (5 minutes) recevront l’erreur invalid_grant leur expliquant qu’elles rencontrent un problème de bouclage. Les jetons demandés disposent d’une durée de vie suffisamment longue (au moins 10 minutes, 60 minutes par défaut), il n’est donc pas nécessaire de réitérer des demandes pendant la période indiquée.

Toutes les applications doivent gérer l’erreur invalid_grant en affichant une invite interactive au lieu de demander un jeton en mode silencieux. Pour éviter cette erreur, les clients doivent s’assurer de mettre correctement en cache les jetons qu’ils reçoivent.

Octobre 2018

Impossible de réutiliser les codes d’autorisation

Date d’effet : 15 novembre 2018

Points de terminaison impactés : V1.0 et v2.0

Protocole impacté : Flux de code

À compter du 15 novembre 2018, Microsoft Entra ID n’acceptera plus les codes d’authentification utilisés pour les applications. Cette modification de sécurité a pour but d’assurer la conformité de Microsoft Entra ID avec la spécification OAuth et s’appliquera aux points de terminaison v1 et v2.

Si votre application réutilise des codes d’autorisation pour obtenir des jetons pour différentes ressources, nous vous recommandons d’utiliser le code pour obtenir un jeton d’actualisation, puis d’utiliser ce jeton d’actualisation pour acquérir des jetons supplémentaires pour d’autres ressources. Les codes d’autorisation ne peuvent être utilisés qu’une seule fois, tandis que les jetons d’actualisation peuvent être utilisés plusieurs fois sur différentes ressources. Toute nouvelle application qui tente de réutiliser un code d’authentification pendant le flux de code OAuth obtiendra une erreur invalid_grant.

Pour plus d’informations sur les jetons d’actualisation, voir Actualisation des jetons d’accès. Si vous utilisez la bibliothèque ADAL ou MSAL, ceci est géré pour vous par la bibliothèque : remplacez la deuxième instance de AcquireTokenByAuthorizationCodeAsync par AcquireTokenSilentAsync.

Mai 2018

Impossible d’utiliser les jetons d’ID pour le flux OBO

Date : 1er mai 2018

Points de terminaison impactés : V1.0 et v2.0

Protocoles impactés : Flux implicite et flux On-Behalf-Of

Depuis le 1er mai 2018, id_tokens ne peut pas être utilisé en tant qu’assertion dans un flux OBO pour les nouvelles applications. Désormais, des jetons d’accès servent à sécuriser les API, même entre un client et le niveau intermédiaire de la même application. Les applications inscrites avant le 1er mai 2018 continueront à fonctionner et à pouvoir échanger des id_tokens pour un jeton d’accès, mais ce n’est pas considéré comme une bonne pratique.

Pour contourner cette modification, vous pouvez procéder comme suit :

1. Créez une API web pour votre application, avec une ou plusieurs étendues. Ce point d’entrée explicite permet d’obtenir un niveau de sécurité et de contrôle plus détaillé.
2. Dans le manifeste de votre application, le Portail Azure ou le portail d’inscription d’application, assurez-vous que l’application est autorisée à émettre des jetons d’accès via le flux implicite. Cela est contrôlé par la clé oauth2AllowImplicitFlow.
3. Quand votre application cliente demande un id_token via response_type=id_token, demandez également un jeton d’accès (response_type=token) pour l’API web créée précédemment. Par conséquent, lorsque vous utilisez le point de terminaison v2.0, le paramètre scope doit ressembler à api://GUID/SCOPE. Sur le point de terminaison v1.0, le paramètre resource doit être l’URI d’application de l’API web.
4. Transmettez ce jeton d’accès au niveau intermédiaire à la place d’id_token.