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

Article
2025-03-13

Les jetons d’identité utilisateur Exchange et les jetons de rappel sont déconseillés et seront désactivés à partir du 17 février 2025. 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 ?

Microsoft commence à désactiver les jetons exchange en ligne hérités à partir du 17 février 2025. D’ici le 17 février 2025, les locataires existants et nouveaux ne seront pas affectés. Nous avons fourni 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. Pour plus d’informations, consultez Puis-je réactiver les jetons hérités ?

Date	Jetons hérités status
17 février 2025	Jetons hérités désactivés pour tous les locataires. Les administrateurs peuvent réactiver les jetons hérités via PowerShell.
Juin 2025	Jetons hérités désactivés pour tous les locataires. Les administrateurs ne peuvent plus réactiver les jetons hérités via PowerShell et doivent contacter Microsoft pour toute exception.
Octobre 2025	Jetons hérités désactivés pour tous les locataires. Les exceptions ne sont plus autorisées.

Que se passe-t-il le 17 février ?

Microsoft va commencer à déployer une modification pour tous les utilisateurs du monde entier dans les locataires Microsoft 365 qui désactivera l’émission de jetons exchange en ligne hérités. Le déploiement prendra plusieurs semaines pour tous les utilisateurs. Si un complément Outlook demande un jeton Exchange hérité et que l’émission de jeton est désactivée, le complément reçoit une erreur. Les compléments Outlook qui demandent toujours des jetons de Exchange Online hérités seront rompus par cette modification. Notez que même une fois les jetons hérités désactivés, les jetons hérités précédemment émis continueront d’être valides pendant une heure maximum.

Notez que étant donné que la modification est appliquée par utilisateur et déployée sur plusieurs semaines, vous pouvez voir certains utilisateurs affectés alors que d’autres ne le sont pas. Si vous devez refuser cette modification, consultez Puis-je réactiver les jetons hérités ?

Quand NAA est-il en disponibilité générale pour mon canal ?

La date de disponibilité générale (GA) pour NAA dépend du canal que vous utilisez.

Date	Disponibilité générale naa (GA)
Octobre 2024	NAA est en disponibilité générale dans le canal actuel.
Nov 2024	NAA est en disponibilité générale dans le canal Entreprise mensuel.
Jan 2025	NAA est ga dans Semi-Annual Channel build 16.0.17928.20392.
Juin 2025	NAA sera en disponibilité générale dans Semi-Annual canal étendu.

Comment faire avez géré les jetons hérités désactivés dans Semi-Annual canal étendu, qui ne prend pas encore en charge NAA ?

Semi-Annual canal étendu ne prendra pas en charge NAA avant juin 2025. Cela signifie que même si les compléments sont mis à jour pour prendre en charge NAA et n’utilisent plus de jetons Exchange Online hérités, ils ne fonctionneront pas sur ce canal. Si vous utilisez Semi-Annual canal étendu en tant qu’administrateur, nous vous recommandons ce qui suit.

Vérifiez si votre locataire utilise des compléments qui nécessitent des jetons de Exchange Online hérités. Pour plus d’informations, voir Rechercher des compléments Outlook qui utilisent des jetons de Exchange Online hérités.
Si vous avez déployé des compléments qui nécessitent des jetons de Exchange Online hérités et que les compléments sont nécessaires pour votre organization, nous vous recommandons d’activer les jetons dès maintenant afin qu’ils ne soient pas désactivés après le 17 février 2025. Pour activer les jetons, consultez Activer ou désactiver les jetons de Exchange Online hérités.

Les compléments COM sont-ils affectés par la dépréciation des jetons de Exchange Online hérités ?

Il est très peu probable que les compléments COM soient affectés par la dépréciation des jetons de Exchange Online hérités. Les compléments web Outlook sont principalement affectés, car ils peuvent utiliser des API Office.js qui s’appuient sur des jetons Exchange. Pour plus d’informations, consultez Comment savoir si mon complément Outlook s’appuie sur des jetons hérités. Les jetons Exchange sont utilisés pour accéder aux SERVICES Web Exchange (EWS) ou aux API REST Outlook, qui sont également déconseillées. Si vous pensez qu’un complément COM est affecté, vous pouvez le tester en l’utilisant sur un locataire avec des jetons Exchange désactivés. Pour plus d’informations, consultez Activer ou désactiver les jetons Exchange Online hérités.

Questions de l’administrateur Microsoft 365

Puis-je réactiver Exchange Online jetons hérités ?

Oui, il existe des commandes PowerShell que vous pouvez utiliser pour activer ou désactiver les jetons hérités dans n’importe quel locataire. Pour plus d’informations sur l’activation ou la désactivation des jetons hérités, consultez Activer ou désactiver les jetons de Exchange Online hérités. Si vous utilisez les commandes pour activer les jetons Exchange Online hérités, ils ne seront pas désactivés en février 2025. Ils resteront activés jusqu’en juin 2025, ou jusqu’à ce que vous utilisiez les outils pour les désactiver.

En juin 2025, les jetons 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 hérités et ils seront désactivés pour tous les locataires. Nous allons mettre à jour ce FAQ avec des informations supplémentaires une fois le processus d’exception prêt.

Les éditeurs de logiciels indépendants mettent à jour leurs compléments pour utiliser des jetons Entra ID et des étendues Microsoft Graph. Lorsque le complément demande un jeton d’accès, il doit avoir le consentement de l’administrateur ou de l’utilisateur. Si l’administrateur donne son consentement, tous les utilisateurs du locataire peuvent utiliser le complément pour les étendues requises par le complément. Sinon, chaque utilisateur final sera invité à donner son consentement, si le consentement de l’utilisateur est activé. Pour une meilleure expérience, car les utilisateurs ne sont pas invités, complétez le consentement de l’administrateur.

L’une des options de consentement est que l’éditeur de logiciels indépendant vous fournit un URI de consentement administrateur.

Le développeur du complément fournit un URI de consentement administrateur. Si ce n’est pas le cas dans la documentation qu’ils fournissent, vous devez les contacter pour plus d’informations.
L’administrateur accède à l’URI de consentement de l’administrateur.
L’administrateur est invité à se connecter et à donner son consentement à une liste d’étendues requises par le complément.
Une fois l’opération terminée, le navigateur redirige vers une page web à partir de l’éditeur de logiciels indépendant, ce qui doit indiquer que le consentement a réussi.

En guise d’alternative, l’éditeur de logiciels indépendant peut fournir un manifeste d’application mis à jour qui demandera le consentement de l’administrateur dans le cadre du déploiement central. Dans ce scénario, lorsque vous déployez le manifeste d’application mis à jour, vous êtes invité à donner votre consentement avant que le déploiement puisse se terminer. Il n’est pas nécessaire d’utiliser un URI de consentement administrateur.

Enfin, si le complément est publié dans le magasin Microsoft 365, la mise à jour est déployée automatiquement et l’administrateur est invité à donner son consentement pour les étendues. Si l’administrateur ne donne pas son consentement, les utilisateurs ne pourront pas utiliser le complément mis à jour.

Veillez à ne pas désactiver les fonctionnalités ou à révoquer les autorisations requises par le complément. Pour obtenir un exemple, consultez Modification des propriétés de stratégie de boîte aux lettres. Le complément utilise des autorisations déléguées et a donc accès aux mêmes ressources que l’utilisateur connecté. Toutefois, si une stratégie ou un paramètre bloque l’utilisateur d’une ressource ou d’une action particulière, le complément est également bloqué.

Comment faire déployer des mises à jour de complément à partir d’un éditeur de logiciels indépendants ?

Si vous avez un complément qui utilise des jetons Exchange hérités, vous devez contacter votre éditeur de logiciels indépendant pour obtenir des informations sur ses chronologie de migrer son complément pour utiliser NAA. Une fois que l’éditeur de logiciels indépendant a migré son complément, il fournit probablement une URL de consentement administrateur. Pour plus d’informations, consultez Comment fonctionne le flux de consentement administrateur ? .

L’éditeur de logiciels indépendant peut également vous fournir un manifeste d’application mis à jour à déployer via un déploiement centralisé. Pendant le déploiement centralisé, cela peut vous inviter à donner votre consentement aux étendues Microsoft Graph requises par le complément. Dans ce scénario, vous n’avez pas besoin d’utiliser un URI de consentement administrateur.

Si le complément est déployé à partir de Microsoft AppSource, vous serez probablement invité à donner votre consentement aux étendues Microsoft Graph lorsque l’éditeur de logiciels indépendant déploiera les mises à jour du complément. Tant que vous n’avez pas donné votre consentement, les utilisateurs du locataire ne pourront pas utiliser la nouvelle version du complément avec NAA.

Quels sont les compléments de mon organization concernés ?

Nous avons publié une liste de tous les compléments Outlook publiés dans le Microsoft Store qui utilisent des jetons hérités à compter d’octobre 2024. Pour plus d’informations sur l’utilisation de la liste et la création d’un rapport sur les compléments Outlook qui utilisent potentiellement des jetons hérités, voir Rechercher des compléments Outlook qui utilisent des jetons de Exchange Online hérités.

Les compléments peuvent utiliser les jetons hérités pour obtenir des ressources à partir 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 appuyez sur un éditeur de logiciels indépendant 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, il doit consulter ce FAQ et l’article Activer l’authentification unique dans un complément Office à l’aide de l’authentification d’application imbriquée. Toutes les questions doivent être posées sur le site des problèmes GitHub OfficeDev/office-js.

Remarque

Nous avons travaillé pour fournir une mise à jour de commande à Exchange Online PowerShell qui signale tous les compléments utilisant des jetons de Exchange Online hérités. Malheureusement, nous avons eu des difficultés à déployer cette mise à jour en raison de la complexité de la capture de l’utilisation spécifique des jetons dans l’écosystème Microsoft 365. Nous continuons à travailler sur cette mise à jour et fournirons de nouvelles informations dans ce FAQ lorsqu’elles seront disponibles.

Une fois que l’administrateur ou un utilisateur a donné son consentement, il est répertorié dans la centre d’administration Microsoft Entra. Vous pouvez trouver des inscriptions d’applications en procédant comme suit.

Accédez à https://entra.microsoft.com/#home et connectez-vous en tant qu’administrateur sur votre locataire.
Dans le volet de navigation gauche, sélectionnez Applications>Applications Applications d’entreprise.
Dans la page Applications d’entreprise , dans la section Gérer , sélectionnez Toutes les applications.
Sélectionnez le complément. Une page de vue d’ensemble s’ouvre. Dans la page de vue d’ensemble, sélectionnez Autorisations. Il existe deux affichages pour les autorisations ; Administration le consentement et le consentement de l’utilisateur. Sélectionnez Consentement de l’utilisateur pour afficher les consentements individuels.

Existe-t-il une liste des éditeurs qui ont mis à jour leurs compléments ?

Certains éditeurs de compléments Outlook largement utilisés ont déjà mis à jour leurs compléments, comme indiqué ci-dessous.

Si l’éditeur a mis à jour son manifeste et que le complément est déployé via le Microsoft Store, vous êtes invité en tant qu’administrateur à mettre à niveau et à déployer les mises à jour. Si l’éditeur a mis à jour son manifeste et que le complément est déployé via un déploiement central, vous devez déployer le nouveau manifeste en tant qu’administrateur. Dans certains cas, l’éditeur peut avoir un URI de consentement administrateur que vous devez utiliser pour donner son consentement à de nouvelles étendues pour le complément. Contactez les éditeurs si vous avez besoin d’informations supplémentaires sur la mise à jour d’un complément.

Certains compléments sont cassants. Puis-je savoir si cela est dû au fait que les jetons Exchange ont été désactivés ?

À compter du 17 février 2025, Microsoft déploie une mise à jour pour désactiver progressivement les jetons Exchange Online hérités pour tous les utilisateurs. La mise à jour ne désactive pas les jetons Exchange dans votre locataire si vous avez déjà activé les jetons Exchange Online hérités.

Si votre locataire utilise un complément qui s’appuie toujours sur des jetons Exchange, le complément interrompt ou perd ses fonctionnalités. La mise à jour est déployée par utilisateur. Cela signifie qu’un ou plusieurs utilisateurs peuvent avoir un complément affecté lorsque les jetons Exchange sont désactivés, mais que d’autres utilisateurs disposent toujours d’un complément opérationnel. Si vous remarquez qu’un complément rencontre des problèmes et que vous pensez qu’il peut être affecté par des jetons Exchange désactivés, effectuez les actions suivantes.

Consulter la liste des compléments connus

Nous avons publié une liste de compléments connus pour utiliser des jetons Exchange hérités en octobre 2024. Si un complément figure dans cette liste, vous devez contacter l’éditeur pour voir s’il existe des mises à jour disponibles. Pour plus d’informations, voir Rechercher des compléments Outlook qui utilisent des jetons de Exchange Online hérités.

Vérifiez si les jetons sont désactivés à l’aide de Script Lab

Vérifiez si les jetons de Exchange Online hérités sont désactivés pour un utilisateur à l’aide du complément Script Lab.

Installez Script Lab pour Outlook.
Connectez-vous à Outlook avec le compte d’utilisateur/la boîte aux lettres qui est affecté. Les jetons Exchange peuvent être désactivés pour un utilisateur, mais pas pour un autre jusqu’à ce que le déploiement soit terminé.
À partir d’un e-mail existant ou nouveau, ouvrez Script Lab dans le menu Applications, puis choisissez Code dans le menu Script Lab.
Dans le volet Office Script Lab, sélectionnez l’icône backstage (elle comporte trois lignes).
Sélectionnez Exemples , puis recherchez l’exemple Obtenir un jeton d’identité utilisateur . Sélectionnez cet exemple pour l’ouvrir dans l’éditeur de code.
Une fois le code de l’exemple chargé, sélectionnez Exécuter>exécuter dans ce volet.
Une fois le code exécuté, sélectionnez Obtenir le jeton.

Si les jetons de Exchange Online hérités sont activés, un jeton s’affiche dans la console sous la forme d’une chaîne encodée en Base64.

Capture d’écran d’un jeton affiché dans la fenêtre de console.

Si les jetons de Exchange Online hérités sont désactivés, une erreur s’affiche dans la console, comme indiqué ci-dessous.

Capture d’écran d’une erreur dans la fenêtre de console.

L’erreur et le code réels peuvent varier, mais vous verrez souvent le code d’erreur 9017 ou 9018 ainsi que les descriptions d’erreur suivantes.

GenericTokenError: An internal error has occurred.
InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Si un complément est affecté par des jetons Exchange désactivés, vous pouvez les réactiver. Pour plus d’informations, consultez Puis-je réactiver Exchange Online jetons hérités ?.

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 Entra ID 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 Entra ID avec Microsoft Graph améliore considérablement la sécurité des données client.

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 Entra ID 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 Entra ID pour accéder à Microsoft Graph à la place.

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, 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. Lorsque votre complément appelle une API qui demande un jeton Exchange, tel que getUserIdentityTokenAsync, il obtient une erreur générique similaire à ce qui suit avec des codes d’erreur tels que 9017 ou 9018.

« GenericTokenError : une erreur interne s’est produite. »
« InternalServerError : le serveur Exchange a retourné une erreur. Pour plus d’informations, consultez l’objet diagnostics. »

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.

Comment faire suivre les dernières recommandations ?

Nous allons mettre à jour ce FAQ dès que de nouvelles informations seront disponibles. 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.

Si vous soumettez un problème, veuillez inclure les informations suivantes.

Version du client Outlook.
Audience du canal de mise en production Outlook (pour le client).
Capture d’écran du problème.
Plateforme où le problème se produit (Windows, Outlook (nouveau), Mac, iOS, Android).
ID de session où le problème est rencontré.
Type de compte utilisé.
Version de msal-browser.
Journaux à partir de msal-browser.

Questions du développeur

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;
        }
      },
    }
  }
};

Tester votre complément mis à jour

Une fois que vous avez mis à jour votre complément pour utiliser NAA, vous devez le tester sur toutes les plateformes que vous prenez en charge, telles que Mac, mobile, web et Outlook sur Windows.

Tester quand les jetons Exchange sont désactivés

Pour vérifier que votre complément fonctionne correctement lorsque les jetons Exchange sont désactivés, déployez votre complément sur un locataire avec des jetons désactivés et testez-le. Pour désactiver les jetons, consultez Activer ou désactiver les jetons Exchange Online hérités.

Si vous avez implémenté un modèle dans lequel votre code utilise des jetons Exchange, mais tombe ensuite s’ils ne sont pas disponibles, vérifiez que vous recherchez les erreurs correctes. Lorsqu’un appel pour obtenir un jeton Exchange échoue, case activée le fichier asyncResult.diagnostics. Si l’une des erreurs suivantes est retournée, basculez vers NAA.

GenericTokenError: An internal error has occurred.
InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Code de secours de test pour la vue web Trident+

Si votre complément Outlook prend en charge Outlook 2016 ou Outlook 2019 sur Windows, vérifiez qu’il fonctionne correctement lorsque la vue web Trident+ (Internet Explorer 11) est utilisée. Lorsque la vue web Trident+ est utilisée, votre code doit revenir à MSAL v2 pour ouvrir une boîte de dialogue et connecter l’utilisateur. Pour plus d’informations sur la façon d’implémenter le modèle de secours, consultez Complément Outlook avec authentification unique à l’aide de l’authentification d’application imbriquée, y compris Internet Explorer de secours.

Test dans Trident+ et WebView2

Outlook 2016 et Outlook 2019 sur Windows utilisent Trident+ ou WebView2 en fonction de différentes conditions de système d’exploitation.

Pour plus d’informations sur l’utilisation de Trident+ ou Webview2, voir Navigateurs et contrôles d’affichage web utilisés par les compléments Office.
Pour plus d’informations sur la façon de déterminer quelle vue web est en cours d’exécution, voir Prise en charge des vues web Microsoft plus anciennes et des versions d’Office

Quels jetons MSAL retourne-t-il et y a-t-il des étendues minimales à demander ?

Lorsque vous demandez un jeton via MSAL, il retourne toujours trois jetons.

Jeton	Objectif	Étendues	`AuthencationResult` propriété
Jeton d’ID	Fournit des informations sur l’utilisateur au client (volet Office).	`profile` et `openid`	`authResult.idToken`
Jeton d’actualisation	Actualise l’ID et les jetons d’accès lorsqu’ils expirent.	`offline_access`	Non disponible.
Access token (Jeton d’accès)	Authentifie l’utilisateur pour des étendues spécifiques auprès d’une ressource, telle que Microsoft Graph.	Toutes les étendues de ressources, telles que `user.read`.	`authResult.accessToken`

MSAL retourne toujours ces trois jetons. Il demande les profilevaleurs , openidet offline_access comme étendues par défaut, même si votre demande de jeton ne les inclut pas. Cela garantit que l’ID et les jetons d’actualisation sont demandés. Toutefois, vous devez inclure au moins une étendue de ressource, par exemple user.read pour obtenir un jeton d’accès. Si ce n’est pas le cas, la demande peut échouer.

Dois-je valider le jeton d’ID à partir de MSAL ?

Non. Il s’agit d’un modèle d’authentification hérité qui a été utilisé avec des jetons Exchange pour autoriser l’accès à vos propres ressources. Le passage du jeton d’ID via un appel réseau pour activer ou autoriser l’accès à un service est un anti-modèle de sécurité. Le jeton d’ID est destiné uniquement au client (volet Office) et il n’existe aucun moyen pour le service d’utiliser de manière fiable le jeton pour s’assurer que l’utilisateur dispose d’un accès autorisé. Pour plus d’informations sur les revendications de jeton d’ID, consultez Informations de référence sur les revendications de jeton d’ID.

Il est très important de toujours demander un jeton d’accès à vos propres services. Le jeton d’accès inclut également les mêmes revendications d’ID. Vous n’avez donc pas besoin de transmettre le jeton d’ID. Créez plutôt une étendue personnalisée pour votre service. Pour plus d’informations sur les paramètres d’inscription d’application pour vos propres services, consultez API web protégée : Inscription d’applications. Lorsque votre service reçoit le jeton d’accès, il peut le valider et utiliser des revendications d’ID à partir du jeton d’accès.

Pourquoi le jeton d’ID n’est-il pas actualisé ?

Il existe un problème connu où MSAL n’actualise parfois pas le jeton d’ID après son expiration. Cela ne devrait pas entraîner de problèmes dans votre complément, car le jeton d’ID est uniquement destiné à être utilisé dans votre volet Office pour obtenir des informations d’identité utilisateur de base, telles que le nom et l’adresse e-mail. Il n’y a aucune raison de valider le jeton d’ID ou de case activée la revendication d’expiration. Si vous devez authentifier l’utilisateur auprès de vos propres ressources, utilisez le jeton d’accès qui contient également les informations d’identité de l’utilisateur. Le jeton d’ID ne doit jamais être passé en dehors du code client qui l’a reçu.

Comment faire déterminer si l’utilisateur est un compte en ligne ou local ?

Vous pouvez déterminer si l’utilisateur connecté dispose d’un compte Exchange Online ou d’un compte Exchange local à l’aide de la propriété Office.UserProfile.accountType. Si la valeur de la propriété de type de compte est enterprise, la boîte aux lettres se trouve sur un serveur Exchange local. Notez que la Outlook 2016 perpétuelle sous licence en volume ne prend pas en charge la propriété accountType. Pour contourner ce problème, appelez l’opération ResolveNames dans le service Web Exchange (EWS) sur le serveur local Exchange pour obtenir les types de destinataires.

Comment faire déployer mon complément sur Microsoft AppSource

Si vous publiez un nouveau complément sur Microsoft AppSource, il doit passer par un processus de certification. Pour plus d’informations, voir Publier votre complément Office sur Microsoft AppSource. Si vous mettez à jour le manifeste d’un complément déjà publié sur Microsoft AppSource, vous devez à nouveau suivre le processus de certification. Vous pouvez mettre à jour le code source du complément sur votre serveur web à tout moment sans avoir à passer par le processus de certification.

Si vous utilisez l’authentification unique via NAA, votre complément doit être conforme aux instructions de publication suivantes.

Veillez à gérer correctement le consentement de l’administrateur. Consultez Publier un complément qui nécessite le consentement de l’administrateur pour les étendues Microsoft Graph.

Pour plus d’informations sur le déploiement, voir Rendre vos solutions disponibles dans Microsoft AppSource et dans Office. Si vous mettez à jour votre complément (modifiez le manifeste), vous devez à nouveau suivre le processus de certification. Vous pouvez mettre à jour le code de votre serveur web à tout moment sans avoir besoin d’être examiné.

Partager via