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 des utilisateurs Office 365.

La prise en charge d’OAuth2 pour les protocoles IMAP, POP et SMTP, comme décrit ci-dessous, est prise en charge 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, commencez par lire le protocole OAuth 2.0 sur Plateforme d'identités Microsoft vue d’ensemble. Pour en savoir plus 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 la vue d’ensemble de MSAL.

Vous pouvez utiliser le service d’authentification OAuth fourni par Azure Active Directory (Azure AD) pour permettre à votre application de se connecter aux protocoles IMAP, POP ou SMTP pour accéder à Exchange Online dans Office 365. Pour utiliser OAuth avec votre application, vous devez :

  1. Inscrivez votre application auprès d’Azure AD.
  2. Obtenir un jeton d’accès à partir d’un serveur de jetons.
  3. 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 d’Azure Active Directory.

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.

  1. Flux de code d’autorisation OAuth2
  2. Flux d’octroi d’autorisation d’appareil OAuth2
  3. 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 SASL XOAUTH2 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 SASL XOAUTH2 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, cela se traduit par la chaîne suivante. Notez que les sauts de ligne sont insérés pour plus de lisibilité.

dXNlcj10ZXN0QGNvbnRvc28ub25taWNyb3NvZnQuY29tAWF1dGg9QmVhcmVy
IEV3QkFBbDNCQUFVRkZwVUFvN0ozVmUwYmpMQldaV0NjbFJDM0VvQUEBAQ==

Authentification SASL XOAUTH2 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, l’application doit obtenir le jeton d’accès au nom d’un utilisateur, mais remplacer le champ userName dans la chaîne encodée SASL XOAUTH2 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 d’informations d’identification du client avec les protocoles SMTP, POP et IMAP.

Remarque

Actuellement, Exchange Online ne prend pas en charge le flux d’informations d’identification du client SMTP Oauth 2.0 avec une connexion non interactive. Nous y travaillons et il sera disponible d’ici la fin de 2023.

Ajouter les autorisations POP, IMAP ou SMTP à votre application AAD

  1. Dans la Portail Azure, choisissez le panneau Autorisations d’API dans la vue de gestion de votre application Azure AD.

  2. Sélectionnez Ajouter une autorisation.

  3. Sélectionnez l’onglet API que mon organization utilise et recherchez « Office 365 Exchange Online ».

  4. Cliquez sur Autorisations d’application.

  5. 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 .

    pop-imap-permission

  6. 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 AAD.

Pour accéder aux boîtes aux lettres Exchange via POP ou IMAP, votre application AAD doit obtenir le consentement de l’administrateur client pour chaque locataire. Pour plus d’informations, consultez Processus de consentement de l’administrateur du locataire.

Si votre éditeur de logiciels indépendant/partenaire a inscrit l’application Azure AD 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. Voici un exemple d’URL de demande d’autorisation OAuth 2.0 :

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. Voici un exemple d’URL de demande d’autorisation OAuth 2.0 :

https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&scope=https://outlook.office365.com/.default 

Si vous avez inscrit votre application dans votre propre locataire à l’aide de « Comptes dans cet annuaire organisationnel uniquement », vous pouvez simplement continuer et utiliser la page de configuration de l’application dans le centre d’administration Azure AD pour accorder le consentement de l’administrateur, et vous n’avez pas besoin d’utiliser l’URL de demande d’autorisation approch.

Image

Inscrire des principaux de service dans Exchange

Une fois que votre application Azure AD est autorisée par un administrateur de locataire, l’administrateur locataire doit inscrire le principal de service de votre application AAD dans Exchange via Exchange Online PowerShell. Cette option est activée par l’applet deNew-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.

Voici un exemple d’inscription du principal de service d’une application Azure AD dans Exchange :

New-ServicePrincipal -AppId <APPLICATION_ID> -ServiceId <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 AAD 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 Azure Active Directory dans le 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 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 désormais ajouter les boîtes aux lettres spécifiques dans le locataire qui seront autorisées à être accessibles par votre application. Cette opération s’effectue avec l’applet de Add-MailboxPermission commande .

Voici un exemple montrant 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 ServicePrincipal 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. L’exemple utilise des commandes Azure AD. Vous devez donc installer le module Azure AD PowerShell, si ce n’est déjà fait. Pour plus d’informations, consultez Installer Azure Active Directory PowerShell pour Graph.

$AADServicePrincipalDetails = Get-AzureADServicePrincipal -SearchString YourAppName

New-ServicePrincipal -AppId $AADServicePrincipalDetails.AppId -ServiceId $AADServicePrincipalDetails.ObjectId -DisplayName "EXO Serviceprincipal for AzureAD App $($AADServicePrincipalDetails.Displayname)"

$EXOServicePrincipal = Get-ServicePrincipal -Identity "EXO Serviceprincipal for AzureAD App YourAppName"

Add-MailboxPermission -Identity "john.smith@contoso.com" -User $EXOServicePrincipal.Identity -AccessRights FullAccess

Votre application Azure AD 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 SASL XOAUTH2, comme décrit précédemment.

Voir aussi