Authentification OAuth pour les e-mails à volume élevé pour Microsoft 365

Découvrez comment utiliser l’authentification OAuth pour vous connecter aux protocoles SMTP et accéder aux données de messagerie pour les utilisateurs Office 365.

La prise en charge d’OAuth2 pour les protocoles SMTP, comme décrit ci-dessous, est disponible pour Microsoft 365 (qui inclut Office sur le Web) et pour les utilisateurs Outlook.com.

Si vous n’êtes pas familiarisé avec le protocole OAuth 2.0, consultez Protocole OAuth 2.0 sur Plateforme d'identités Microsoft vue d’ensemble. Pour plus d’informations sur les bibliothèques d’authentification Microsoft (MSAL), qui implémentent le protocole OAuth 2.0 pour authentifier les utilisateurs et accéder aux API sécurisées, consultez Vue d’ensemble de MSAL.

Inscription de votre application

Pour utiliser OAuth, une application doit être inscrite auprès de Microsoft Entra.

Suivez les instructions indiquées dans Inscrire une application auprès du Plateforme d'identités Microsoft pour créer une application.

Connectez-vous au centre d’administration Microsoft Entra au moins en tant qu’administrateur d’application cloud.
Accédez àApplications>d’identité>inscriptions d'applications et sélectionnez Nouvelle inscription.
Entrez un nom d’affichage pour votre application. Les utilisateurs de votre application peuvent voir le nom d’affichage lorsqu’ils utilisent l’application, par exemple lors de la connexion. Vous pouvez modifier le nom d’affichage à tout moment et plusieurs inscriptions d’applications peuvent partager le même nom. L’ID d’application (client) généré automatiquement par l’inscription de l’application, et non son nom d’affichage, identifie de manière unique votre application au sein de la plateforme d’identité.
Après l’inscription, plusieurs ID sont créés, dont certains sont nécessaires ultérieurement pour obtenir un jeton OAuth 2.0.

Ajouter des autorisations d'API

Dans le menu de gauche, sélectionnez Autorisations d’API , puis Sélectionnez Ajouter une autorisation.
Accédez aux API que mon organization utilise et recherchez Office 365 Exchange Online.
Sous Demander des autorisations d’API, choisissez Autorisations d’application, sélectionnez Mail.Send, puis Ajouter des autorisations.

Remarque

L’autorisation d’application Mail.Send n’accorde pas la possibilité d’envoyer des e-mails à partir de tous les utilisateurs de messagerie Exchange. Suivant la configuration décrite, seuls les utilisateurs de messagerie de type compte HVE pourront envoyer des e-mails, sauf si l’application est explicitement autorisée pour les autres utilisateurs de messagerie via les contrôles d’accès à l’application Exchange. Selon votre configuration, cela est appliqué à l’aide des stratégies d’accès aux applications (héritées) ou des Access Control basées sur les rôles pour les applications dans Exchange Online.
Après avoir ajouté l’autorisation d’API, l’administrateur doit sélectionner Accorder le consentement administrateur pour.

Nous prenons en charge les deux : autorisation déléguée et autorisation d’application pour autoriser des applications tierces OAuth héritées, car elles utilisent des autorisations d’application avec des secrets d’application.

Autorisations déléguées :

Sous l’onglet Autorisations de l’API, ajoutez l’autorisation API Mail.Send à partir de Office 365 Exchange Online\Autorisations déléguées.
Sous l’onglet Autorisations de l’API , sélectionnez Accorder le consentement administrateur.
Sous l’onglet Authentification , activez Autoriser les flux clients publics.
Utilisez les informations d’identification de l’utilisateur de messagerie HVE pour demander un jeton pour l’audience https://outlook.office.com/.default.

Autorisations d’application :

Sous l’onglet Autorisations de l’API, ajoutez l’autorisation API Mail.Send à partir de Office 365 Exchange Online\Autorisations d’application.
Sous l’onglet Autorisations de l’API , sélectionnez Accorder le consentement administrateur.
Sous l’onglet Certificat & secrets , ajoutez une nouvelle clé secrète client.
Utilisez la clé secrète client pour demander un jeton pour l’audience https://outlook.office.com/.default.

Restreindre l’accès OAuth aux applications autorisées

High Volume Email prend en charge la restriction de l’authentification OAuth à un ensemble spécifique d’applications Microsoft Entra ID. Cela permet d’empêcher les applications non autorisées ou involontaires d’utiliser un compte HVE et réduit le risque d’utilisation incorrecte ou de facturation inattendue. Par défaut, toute application disposant d’informations d’identification OAuth valides et des autorisations Exchange Online requises peut s’authentifier auprès de HVE. Avec les applications autorisées, vous pouvez définir explicitement quelles applications sont autorisées à envoyer des e-mails à l’aide d’un compte HVE spécifique.

Fonctionnement des applications autorisées

Lorsque les applications autorisées sont configurées pour un compte HVE :

Lors de l’authentification OAuth, HVE valide l’identité de l’application dans le jeton d’accès.
Seules les applications explicitement autorisées pour le compte HVE peuvent s’authentifier correctement.
Les demandes d’authentification provenant d’autres applications sont rejetées. La validation est basée sur l’ID de principal de service (ID d’objet) de l’application Microsoft Entra ID utilisée pour obtenir le jeton OAuth.

Remarque

Les applications autorisées s’appliquent uniquement à l’authentification OAuth. Elles n’affectent pas l’authentification SMTP de base à l’aide de mots de passe.

Configurer les applications autorisées

Les applications autorisées sont configurées par compte HVE à l’aide de Exchange Online PowerShell. Vous pouvez ajouter ou supprimer Microsoft Entra ID applications en spécifiant leurs GUID de principal de service.

Remarque

Pour spécifier les ID d’application autorisés, vous devez utiliser l’ID d’objet du principal de service de la page Vue d’ensemble du nœud Application d’entreprise (Portail Azure) pour l’inscription de l’application. N’utilisez pas l’ID d’objet de la page Vue d’ensemble du nœud Inscriptions d’applications. L’utilisation de l’ID d’objet incorrect entraîne un échec d’authentification. En savoir plus sur l’authentification d’une connexion IMAP, POP ou SMTP à l’aide d’OAuth.

Ajouter des applications autorisées

Add-HVEAppAccess -Identity HVEaccount@contoso.com -AppIds <service-principal-id-1>,<service-principal-id-2>

Supprimer les applications autorisées

Remove-HVEAppAccess -Identity HVEaccount@contoso.com -AppIds <service-principal-id-1>,<service-principal-id-2>

Afficher les applications autorisées

Get-HVEAccountSettings -Identity HVEaccount@contoso.com | Format-List *AllowedApps*

Limites et comportement

Chaque compte HVE peut avoir un maximum de 10 applications autorisées configurées.
Si aucune application autorisée n’est configurée pour un compte HVE, aucune restriction supplémentaire au niveau de l’application n’est appliquée.

Échange de protocole SMTP HVE

Pour authentifier une connexion de serveur SMTP, le client doit répondre avec une AUTH commande au SASL XOAUTH2 format . SASL XOAUTH2 encode le nom d’utilisateur et le jeton d’accès ensemble au format suivant :

base64("user=" + userName + "^Aauth=Bearer " + accessToken + "^A^A")

^A représente un contrôle + A (%x01).

Par exemple, le format d’accès SASL XOAUTH2application@contoso.onmicrosoft.com avec un jeton EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA d’accès est le suivant :

base64("user=application@contoso.onmicrosoft.com^Aauth=Bearer EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA^A^A")

Exemple d’échange de messages client-serveur qui aboutit à une authentification réussie :

[connection begins]

C: auth xoauth2

S: 334

C: dXNlcj1hcHBsaWNhdGlvbkBjb250b3NvLm9ubWljcm9zb2Z0LmNvbQFBdXRoPUJlYXJlciBFd0JBQWwzQkFBVUZGcFVBbzdKM1ZlMGJqTEJXWldDY2xSQzNFb0FBAQE=

S: 235 2.7.0 Authentication successful

[connection continues...]

Exemple d’échange de messages client-serveur qui entraîne un échec d’authentification :

[connection begins]

C: auth xoauth2

S: 334

C: dXNlcj1hcHBsaWNhdGlvbkBjb250b3NvLm9ubWljcm9zb2Z0LmNvbQFBdXRoPUJlYXJlciBFd0JBQWwzQkFBVUZGcFVBbzdKM1ZlMGJqTEJXWldDY2xSQzNFb0FBAQE=

S: 535 5.7.3 Authentication unsuccessful

Last updated on 2026-04-15