FAQ sur l’authentification des applications imbriquées et la dépréciation des jetons hérités Outlook

Les jetons d’identité utilisateur Exchange et les jetons de rappel sont déconseillés et seront désactivés à partir d’octobre 2024. Nous vous recommandons de déplacer les compléments Outlook qui utilisent des jetons Exchange hérités vers l’authentification d’application imbriquée.

Questions fréquentes (FAQ)

Qu’est-ce que l’authentification d’application imbriquée (NAA) ?

L’authentification d’application imbriquée permet l’authentification unique (SSO) pour les applications imbriquées dans les applications Microsoft prises en charge telles qu’Outlook. Par rapport aux modèles d’authentification de confiance totale existants et au flux on-behalf-of, NAA offre une meilleure sécurité et une plus grande flexibilité dans l’architecture des applications, ce qui permet la création d’applications riches et pilotées par le client. Pour plus d’informations, voir Activer l’authentification unique dans un complément Office à l’aide de l’authentification d’application imbriquée.

Quelle est la chronologie pour arrêter les jetons Exchange online hérités ?

Le tableau suivant répertorie les jalons clés en fonction du canal utilisé par les clients. Notez que la date de disponibilité générale (GA) pour NAA varie en fonction du canal. Nous fournirons des outils permettant aux administrateurs de réactiver les jetons Exchange pour les locataires et les compléments si ces compléments ne sont pas encore migrés vers NAA.

Date Canal(s) de mise en production Jetons hérités status et disponibilité générale NAA
Octobre 2024 Tous les canaux Nouvelles options PowerShell pour activer/désactiver les jetons hérités pour l’ensemble du locataire ou des AppID spécifiques.
Octobre 2024 Canal actuel Jetons hérités désactivés pour les locataires qui ne les utilisent pas ; NAA sera en disponibilité générale dans le canal actuel.
Nov 2024 Canal mensuel des entreprises Jetons hérités désactivés pour les locataires qui ne les utilisent pas ; NAA sera en disponibilité générale dans le canal Entreprise mensuel.
Jan 2025 Canaux actuels et Semi-Annual Jetons hérités désactivés pour tous les locataires dans Canaux actuels et Semi-Annual. Les administrateurs peuvent réactiver via PowerShell. NAA sera en disponibilité générale dans les canaux Semi-Annual.
Fév 2025 Canal mensuel des entreprises Jetons hérités désactivés pour tous les locataires dans Monthly Enterprise. Les administrateurs peuvent réactiver via PowerShell.
Juin 2025 canal étendu Semi-Annual Jetons hérités désactivés pour tous les locataires dans Semi-Annual canal étendu. NAA sera en disponibilité générale dans Semi-Annual canal étendu.
Juin 2025 Tous les canaux Les administrateurs ne peuvent plus réactiver les jetons hérités via PowerShell ; contactez Microsoft.
Octobre 2025 Tous les canaux Jetons hérités désactivés pour tous les locataires, il n’y aura aucune option de réactivation.

Remarque

Si un seul locataire utilise plusieurs applications Microsoft 365 via des canaux de publication Office, les jetons de Exchange Online hérités sont désactivés en fonction du canal de publication « le plus lent ».

FAQ sur la migration des compléments Outlook

Pourquoi Microsoft effectue-t-il la migration des compléments Outlook ?

Le passage à Microsoft Graph à l’aide de jetons d’ID Entra est une grande amélioration de la sécurité pour les clients Outlook et Exchange. Entra ID (anciennement Azure Active Directory) est un service cloud de premier plan de gestion des identités et des accès. Les clients peuvent tirer parti des fonctionnalités de confiance zéro, telles que l’accès conditionnel, les exigences MFA, la surveillance continue des jetons, l’heuristique de sécurité en temps réel, etc. qui ne sont pas disponibles avec les jetons Exchange hérités. Les clients stockent des données professionnelles importantes stockées dans Exchange. Il est donc essentiel de veiller à ce que ces données soient protégées. La migration de l’ensemble de l’écosystème Outlook pour utiliser des jetons d’ID Entra avec Microsoft Graph améliore considérablement la sécurité des données client.

Puis-je refuser ?

Nous fournirons des outils via PowerShell aux administrateurs Microsoft 365 en octobre 2024 pour activer ou désactiver les jetons Exchange hérités dans votre locataire. Vous pouvez l’utiliser pour vous assurer que les compléments ne sont pas rompus s’ils n’ont pas encore été mis à jour pour utiliser NAA. Toutefois, en juin 2025, les jetons de Exchange Online hérités seront désactivés et vous ne pourrez pas les réactiver sans une exception spécifique accordée par Microsoft. En octobre 2025, il ne sera pas possible d’activer les jetons Exchange Online hérités et ils seront désactivés pour tous les locataires. Nous allons mettre à jour ce FAQ lorsque plus d’informations sur ces outils seront disponibles.

Mon complément Outlook doit-il migrer vers NAA ?

Non. Les compléments Outlook n’ont pas besoin d’utiliser NAA, bien que NAA offre la meilleure expérience d’authentification pour les utilisateurs et la meilleure posture de sécurité pour les organisations. Si les compléments n’utilisent pas de jetons Exchange hérités, ils ne seront pas affectés par la dépréciation des jetons Exchange. Les compléments utilisant MSAL.js ou d’autres méthodes d’authentification unique qui s’appuient sur l’ID Entra continueront de fonctionner.

Comment faire savoir si mon complément Outlook s’appuie sur des jetons hérités ?

Pour savoir si votre complément utilise des jetons d’identité utilisateur Exchange hérités et des jetons de rappel, recherchez dans votre code les appels aux API suivantes.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si votre complément appelle l’une de ces API, vous devez adopter NAA et migrer vers l’utilisation de jetons d’ID Entra pour accéder à Microsoft Graph à la place.

Nous fournirons des outils via PowerShell aux administrateurs Microsoft 365 en octobre 2024 pour activer ou désactiver les jetons Exchange hérités dans votre locataire. Cela vous permet de tester si des compléments utilisent des jetons Exchange. Nous fournirons plus d’informations lorsque les outils seront prêts dans ce FAQ.

Quels sont les compléments Outlook dans l’étendue ?

De nombreux compléments principaux sont dans l’étendue. Si votre complément utilise EWS ou Outlook REST pour accéder à Exchange Online ressources, il doit certainement migrer des jetons Outlook hérités vers NAA. Si votre complément est destiné à Exchange en local uniquement (par exemple, Exchange 2019), il n’est pas affecté par cette modification.

Qu’adviendra-t-il de mes compléments Outlook si je ne migre pas vers NAA ?

Si vous ne migrez pas vos compléments Outlook vers NAA, ils cesseront de fonctionner comme prévu dans Exchange Online. Lorsque les jetons Exchange sont désactivés (conformément au tableau précédent), Exchange Online bloque l’émission de jetons hérités. Tout complément qui utilise des jetons hérités ne pourra pas accéder aux ressources Exchange Online. Si votre complément fonctionne uniquement en local ou si votre complément se trouve sur un chemin d’accès déconseillé, vous n’aurez peut-être pas besoin de le mettre à jour. Toutefois, la plupart des compléments qui accèdent aux ressources Exchange via EWS ou Outlook REST doivent migrer pour continuer à fonctionner comme prévu.

Comment faire migrer mes compléments Outlook vers NAA ?

Pour prendre en charge NAA dans votre complément Outlook, reportez-vous à la documentation et à l’exemple suivants.

En tant qu’administrateur, comment savoir quels compléments de mon organisation doivent être mis à jour ?

Les compléments peuvent utiliser les jetons Exchange hérités pour obtenir des ressources d’Exchange via les API REST EWS ou Outlook. Parfois, un complément nécessite des ressources Exchange pour certains cas d’usage et non pour d’autres, ce qui rend difficile de déterminer si le complément nécessite une mise à jour. Nous vous recommandons de contacter les développeurs et les propriétaires de compléments pour leur demander si leur code de complément fait référence aux API suivantes.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Si vous vous fiez à un éditeur de logiciels indépendant (ISV) pour votre complément, nous vous recommandons de le contacter dès que possible pour confirmer qu’il dispose d’un plan et d’un chronologie pour le déplacement des jetons Exchange hérités. Les développeurs d’éditeurs de logiciels indépendants doivent contacter directement leurs contacts Microsoft pour s’assurer qu’ils sont prêts pour la fin des jetons exchange hérités. Si vous vous fiez à un développeur au sein de votre organization, nous vous recommandons de lui demander de consulter le blog Mises à jour sur la dépréciation des jetons de Exchange Online hérités pour les compléments Outlook et de poser des questions à l’équipe PM d’extensibilité Outlook sur le site des problèmes GitHub OfficeDev/office-js.

Comment faire suivre les dernières recommandations ?

Nous allons partager des conseils supplémentaires à l’avenir sur l’appel de la communauté des compléments Office et le blog du développeur M365. Enfin, vous pouvez poser des questions sur NAA et la dépréciation des jetons de Exchange Online hérités sur le site des problèmes GitHub OfficeDev/office-js. Veuillez placer « NAA » dans le titre afin que nous puissions regrouper et hiérarchiser les problèmes.

Questions de résolution des problèmes pour les développeurs

NAA ne fournit pas d’authentification unique et invite les utilisateurs à se connecter

Cela peut se produire lorsque NAA n’est pas disponible dans le client Outlook. Si vous utilisez Windows, case activée que vous utilisez le canal bêta ou le canal actuel (préversion). Vous devez rejoindre le programme Microsoft 365 Insider pour basculer vers ces canaux. Un bon moyen de case activée si NAA est disponible consiste à case activée l’ensemble de conditions requises à l’aide de l’extrait de code suivant. Office.context.requirements.isSetSupported("NestedAppAuth")

Comment faire obtenir plus d’informations de débogage auprès de MSAL et NAA ?

Utilisez le code suivant pour activer les informations de débogage dans msalConfig lorsque vous initialisez l’application cliente publique imbriquée. Cela permet d’enregistrer des détails supplémentaires dans la console.

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};