Authentifier une connexion IMAP, POP ou SMTP à l’aide d’OAuth
Découvrez comment utiliser l’authentification OAuth pour vous connecter aux protocoles IMAP, POP ou SMTP et accéder aux données de messagerie pour Office 365 utilisateurs.
La prise en charge d’OAuth2 pour les protocoles IMAP, POP et SMTP, comme décrit ci-dessous, est disponible pour Microsoft 365 (qui inclut Office sur le Web) et pour les utilisateurs Outlook.com.
Importante
Cette documentation utilise l’étendue de l’API REST Outlook déconseillée. Les nouvelles applications doivent utiliser le point de terminaison de l’API REST Graph à la place.
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.
Vous pouvez utiliser le service d’authentification OAuth fourni par Microsoft Entra (Microsoft Entra) pour permettre à votre application de se connecter avec les protocoles IMAP, POP ou SMTP pour accéder à Exchange Online dans Office 365. Pour utiliser OAuth avec votre application, vous devez :
- Inscrivez votre application auprès de Microsoft Entra.
- Obtenir un jeton d’accès à partir d’un serveur de jetons.
- Authentifier les demandes de connexion avec un jeton d’accès.
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.
Obtenir un jeton d’accès
Vous pouvez utiliser l’une de nos bibliothèques clientes MSAL pour récupérer un jeton d’accès à partir de votre application cliente.
Vous pouvez également sélectionner un flux approprié dans la liste suivante et suivre les étapes correspondantes pour appeler les API REST de plateforme d’identité sous-jacentes et récupérer un jeton d’accès.
- Flux de code d’autorisation OAuth2
- Flux d’octroi d’autorisation d’appareil OAuth2
- Flux d’octroi des informations d’identification du client OAuth2
Veillez à spécifier les étendues complètes, y compris les URL de ressources Outlook, lors de l’autorisation de votre application et de la demande d’un jeton d’accès.
| Protocole | Chaîne d’étendue d’autorisation |
|---|---|
| IMAP | https://outlook.office.com/IMAP.AccessAsUser.All |
| POP | https://outlook.office.com/POP.AccessAsUser.All |
| AUTHENTIFICATION SMTP | https://outlook.office.com/SMTP.SendAsApp |
En outre, vous pouvez demander offline_access étendue. Lorsqu’un utilisateur approuve l’étendue offline_access, votre application peut recevoir des jetons d’actualisation à partir du point de terminaison de jeton de Plateforme d'identités Microsoft. Les jetons d’actualisation sont de longue durée. Votre application peut obtenir de nouveaux jetons d’accès à mesure que les anciens arrivent à expiration.
Authentifier les demandes de connexion
Vous pouvez établir une connexion à Office 365 serveurs de messagerie à l’aide des paramètres de messagerie IMAP et POP pour Office 365.
SASL XOAUTH2
L’intégration OAuth nécessite que votre application utilise le format XOAUTH2 SASL pour encoder et transmettre le jeton d’accès. SASL XOAUTH2 encode le nom d’utilisateur et le jeton d’accès au format suivant :
base64("user=" + userName + "^Aauth=Bearer " + accessToken + "^A^A")
^A représente un contrôle + A (%x01).
Par exemple, le format de XOAUTH2 SASL pour accéder test@contoso.onmicrosoft.com avec un jeton EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA d’accès est le suivant :
base64("user=test@contoso.onmicrosoft.com^Aauth=Bearer EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA^A^A")
Après l’encodage en base64, ce format se traduit par la chaîne suivante. Les sauts de ligne sont insérés pour plus de lisibilité.
dXNlcj10ZXN0QGNvbnRvc28ub25taWNyb3NvZnQuY29tAWF1dGg9QmVhcmVy
IEV3QkFBbDNCQUFVRkZwVUFvN0ozVmUwYmpMQldaV0NjbFJDM0VvQUEBAQ==
Authentification XOAUTH2 SASL pour les boîtes aux lettres partagées dans Office 365
En cas d’accès aux boîtes aux lettres partagé à l’aide d’OAuth, une application doit obtenir le jeton d’accès pour le compte d’un utilisateur, mais remplacer le champ userName dans la chaîne sasL XOAUTH2 encodée par l’adresse e-mail de la boîte aux lettres partagée.
Exchange du protocole IMAP
Pour authentifier une connexion de serveur IMAP, le client doit répondre avec une AUTHENTICATE commande au format suivant :
AUTHENTICATE XOAUTH2 <base64 string in XOAUTH2 format>
Exemple d’échange de messages client-serveur qui aboutit à une authentification réussie :
[connection begins]
C: C01 CAPABILITY
S: * CAPABILITY … AUTH=XOAUTH2
S: C01 OK Completed
C: A01 AUTHENTICATE XOAUTH2 dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0Q2cBAQ==
S: A01 OK AUTHENTICATE completed.
Exemple d’échange de messages client-serveur qui entraîne un échec d’authentification :
[connection begins]
S: * CAPABILITY … AUTH=XOAUTH2
S: C01 OK Completed
C: A01 AUTHENTICATE XOAUTH2 dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0Q2cBAQ==
S: A01 NO AUTHENTICATE failed.
Échange de protocole POP
Pour authentifier une connexion de serveur POP, le client doit répondre avec une AUTH commande divisée en deux lignes au format suivant :
AUTH XOAUTH2
<base64 string in XOAUTH2 format>
Exemple d’échange de messages client-serveur qui aboutit à une authentification réussie :
[connection begins]
C: AUTH XOAUTH2
S: +
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYX
JlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0
Q2cBAQ==
S: +OK User successfully authenticated.
[connection continues...]
Exemple d’échange de messages client-serveur qui entraîne un échec d’authentification :
[connection begins]
C: AUTH XOAUTH2
S: +
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ=
S: -ERR Authentication failure: unknown user name or bad password.
Échange de protocole SMTP
Pour authentifier une connexion de serveur SMTP, le client doit répondre avec une AUTH commande au format suivant :
AUTH XOAUTH2 <base64 string in XOAUTH2 format>
Exemple d’échange de messages client-serveur qui aboutit à une authentification réussie :
[connection begins]
C: auth xoauth2
S: 334
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ==
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: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ==
S: 535 5.7.3 Authentication unsuccessful [SN2PR00CA0018.namprd00.prod.outlook.com]
Utiliser le flux d’octroi des informations d’identification du client pour authentifier les connexions SMTP, IMAP et POP
Les principaux de service dans Exchange sont utilisés pour permettre aux applications d’accéder aux boîtes aux lettres Exchange via le flux des informations d’identification du client avec les protocoles SMTP, POP et IMAP.
Ajouter les autorisations POP, IMAP ou SMTP à votre application Entra AD
Dans le Portail Azure, choisissez le panneau Autorisations de l’API dans la vue de gestion de votre application Microsoft Entra.
Sélectionnez Ajouter une autorisation.
Sélectionnez l’onglet API que mon organization utilise et recherchez « Office 365 Exchange Online ».
Cliquez sur Autorisations d’application.
Pour l’accès POP, choisissez le POP. Autorisation AccessAsApp . Pour l’accès IMAP, choisissez imap. Autorisation AccessAsApp . Pour l’accès SMTP, choisissez le SMTP. Autorisation SendAsApp .
Une fois que vous avez choisi le type d’autorisation, sélectionnez Ajouter des autorisations.
Les autorisations d’application SMTP, POP ou IMAP doivent maintenant être ajoutées aux autorisations de votre application Entra AD.
Obtenir le consentement de l’administrateur du locataire
Pour accéder aux boîtes aux lettres Exchange via POP ou IMAP, votre application Entra AD doit obtenir le consentement de l’administrateur client pour chaque locataire. Pour plus d’informations, consultez Processus de consentement de l’administrateur du locataire.
Comment accorder un consentement si l’application est inscrite/configurée pour l’utilisation de plusieurs locataires, par exemple, pour une application développée par un partenaire/un éditeur de logiciels indépendant développé de manière centralisée
Si votre éditeur de logiciels indépendant/partenaire a inscrit l’application Microsoft Entra avec l’option « Comptes dans n’importe quel annuaire organisationnel », vous devez ajouter cette application et l’accepter en suivant les étapes suivantes en tirant parti de l’URL de la demande d’autorisation.
Conseils POP et IMAP
Dans votre demande d’autorisation de locataire OAuth 2.0, le scope paramètre de requête doit être https://ps.outlook.com/.default pour les étendues d’application POP et IMAP.
L’URL de demande d’autorisation OAuth 2.0 est indiquée dans l’exemple suivant :
https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&scope=https://ps.outlook.com/.default
Conseils smtp
Dans votre demande d’autorisation de locataire OAuth 2.0, le scope paramètre de requête doit être https://outlook.office365.com/.default uniquement pour SMTP. L’URL de demande d’autorisation OAuth 2.0 est indiquée dans l’exemple suivant :
https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&scope=https://outlook.office365.com/.default
Comment accorder le consentement si vous avez inscrit l’application pour votre propre locataire
Si vous avez inscrit votre application dans votre propre locataire à l’aide de « Comptes de cet annuaire organisationnel uniquement », vous pouvez continuer et utiliser la page de configuration de l’application dans le centre d'administration Microsoft Entra pour accorder le consentement de l’administrateur, et vous n’avez pas besoin d’utiliser l’approche d’URL de demande d’autorisation.
Inscrire des principaux de service dans Exchange
Une fois qu’un administrateur client a donné son consentement à votre application Microsoft Entra, il doit inscrire le principal de service de votre application Entra AD dans Exchange via Exchange Online PowerShell. Cette inscription est activée par l’applet de New-ServicePrincipal commande .
Pour utiliser l’applet de commande New-ServicePrincipal , installez ExchangeOnlineManagement et connectez-vous à votre locataire, comme indiqué dans l’extrait de code suivant :
Install-Module -Name ExchangeOnlineManagement -allowprerelease
Import-module ExchangeOnlineManagement
Connect-ExchangeOnline -Organization <tenantId>
Si vous recevez toujours une erreur lors de l’exécution de l’applet de commande New-ServicePrincipal après avoir effectué ces étapes, cela est probablement dû au fait que l’utilisateur ne dispose pas des autorisations suffisantes dans Exchange Online pour effectuer l’opération.
L’inscription du principal de service d’une application Microsoft Entra dans Exchange est illustrée dans l’exemple suivant :
New-ServicePrincipal -AppId <APPLICATION_ID> -ObjectId <OBJECT_ID> [-Organization <ORGANIZATION_ID>]
L’administrateur client peut trouver les identificateurs de principal de service référencés ci-dessus dans l’application d’entreprise de votre application Entra AD instance sur le locataire. Vous trouverez la liste des instances d’application d’entreprise sur le locataire dans le panneau Applications d’entreprise de la vue Microsoft Entra du portail Azure.
Vous pouvez obtenir l’identificateur de votre principal de service inscrit à l’aide de l’applet de Get-ServicePrincipal commande .
Get-ServicePrincipal | fl
Le OBJECT_ID est l’ID d’objet de la page Vue d’ensemble du nœud Application d’entreprise (portail Azure) pour l’inscription de l’application. Il ne s’agit pas de 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.
L’administrateur du locataire peut maintenant ajouter les boîtes aux lettres spécifiques dans le locataire qui seront autorisées à être accessibles par votre application. Cette configuration est effectuée avec l’applet de Add-MailboxPermission commande .
L’exemple suivant montre comment accorder au principal de service de votre application l’accès à une boîte aux lettres :
Add-MailboxPermission -Identity "john.smith@contoso.com" -User
<SERVICE_PRINCIPAL_ID> -AccessRights FullAccess
Différents ID sont utilisés lors de la création du principal de service Exchange et ultérieurement lors de l’octroi d’autorisations de boîte aux lettres. L’exemple suivant peut vous aider à utiliser l’ID correct pour les différentes étapes. Cet exemple utilise Microsoft Entra applets de commande . Vous devez donc installer le module PowerShell Microsoft Entra, si ce n’est déjà fait. Pour plus d’informations, consultez Installer Microsoft Entra PowerShell pour Graph.
$AADServicePrincipalDetails = Get-AzureADServicePrincipal -SearchString YourAppName
New-ServicePrincipal -AppId $AADServicePrincipalDetails.AppId -ObjectId $AADServicePrincipalDetails.ObjectId -DisplayName "EXO Serviceprincipal for EntraAD App $($AADServicePrincipalDetails.Displayname)"
$EXOServicePrincipal = Get-ServicePrincipal -Identity "EXO Serviceprincipal for EntraAD App YourAppName"
Add-MailboxPermission -Identity "john.smith@contoso.com" -User $EXOServicePrincipal.Identity -AccessRights FullAccess
Votre application Microsoft Entra peut désormais accéder aux boîtes aux lettres autorisées via les protocoles SMTP, POP ou IMAP à l’aide du flux d’octroi des informations d’identification du client OAuth 2.0. Pour plus d’informations, consultez les instructions dans Autorisations et consentement dans la Plateforme d'identités Microsoft.
Vous devez utiliser https://outlook.office365.com/.default dans la scope propriété dans la charge utile du corps pour la demande de jeton d’accès.
Les jetons d’accès générés peuvent être utilisés comme jetons pour authentifier les connexions SMTP, POP et IMAP via le format XOAUTH2 SASL, comme décrit précédemment.
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour