Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Erfahren Sie, wie Sie die OAuth-Authentifizierung verwenden, um eine Verbindung mit IMAP-, POP- oder SMTP-Protokollen herzustellen und auf E-Mail-Daten für Office 365-Benutzende zuzugreifen.
OAuth2-Unterstützung für IMAP-, POP- und SMTP-Protokolle wie unten beschrieben ist sowohl für Microsoft 365 (einschließlich Office im Web) als auch für Benutzende von Outlook.com verfügbar.
Wenn Sie mit dem OAuth 2.0-Protokoll nicht vertraut sind, finden Sie weitere Informationen unter OAuth 2.0-Protokoll unter Microsoft Identity Platform-Übersicht. Weitere Informationen zu den Microsoft-Authentifizierungsbibliotheken (MSAL), die das OAuth 2.0-Protokoll implementieren, um Benutzer zu authentifizieren und auf sichere APIs zuzugreifen, finden Sie unter MSAL-Übersicht.
Sie können den von Microsoft Entra bereitgestellten OAuth-Authentifizierungsdienst verwenden, um Ihrer Anwendung die Verbindung mit IMAP-, POP- oder SMTP-Protokollen für den Zugriff auf Exchange Online in Office 365 zu ermöglichen. Um OAuth mit Ihrer Anwendung zu verwenden, müssen Sie Folgendes ausführen:
Um OAuth verwenden zu können, muss eine Anwendung bei Microsoft Entra registriert werden.
Befolgen Sie die Anweisungen unter Registrieren einer Anwendung bei der Microsoft Identity Platform-, um eine neue Anwendung zu erstellen.
Sie können eine unserer MSAL-Clientbibliotheken verwenden, um ein Zugriffstoken aus Ihrer Clientanwendung abzurufen.
Alternativ können Sie aus der folgenden Liste einen geeigneten Flow auswählen und die entsprechenden Schritte befolgen, um die zugrunde liegenden REST-APIs der Identitätsplattform aufzurufen und ein Zugriffstoken abzurufen.
Stellen Sie sicher, dass Sie beim Autorisieren Ihrer Anwendung und Anfordern eines Zugriffstokens alle Bereiche angeben, einschließlich der Outlook-Ressourcen-URLs.
| Protokoll | Zeichenfolge des Berechtigungsbereichs |
|---|---|
| IMAP | https://outlook.office.com/IMAP.AccessAsUser.All |
| POP | https://outlook.office.com/POP.AccessAsUser.All |
| SMTP-AUTHENTIFIZIERUNG | https://outlook.office.com/SMTP.Send |
Darüber hinaus können Sie den Bereich offline_access anfordern. Wenn Benutzende den offline_access-Bereich genehmigen, kann Ihre App Aktualisierungstoken vom Tokenendpunkt der Microsoft Identity Platform empfangen. Aktualisierungstoken haben eine lange Lebensdauer. Ihre App kann neue Zugriffstoken abrufen, wenn ältere ablaufen.
Alternativ können Sie den OAuth2-Genehmigungsflow für Clientanmeldeinformationen anstelle des OAuth2-Autorisierungscode-Flows oder des OAuth2-Geräteautorisierungsgenehmigungsflows verwenden, um ein Zugriffstoken abzurufen.
Sie können eine Verbindung mit Office 365-E-Mail-Servern mithilfe der IMAP- und POP-E-Mail-Einstellungen für Office 365 initiieren.
Für die OAuth-Integration muss Ihre Anwendung das SASL XOAUTH2-Format zum Kodieren und Übertragen des Zugriffstokens verwenden. SASL XOAUTH2 codiert den Benutzername und das Zugriffstoken im folgenden Format:
base64("user=" + userName + "^Aauth=Bearer " + accessToken + "^A^A")
^A stellt ein Steuerelement + A (%x01) dar.
Beispielsweise lautet das SASL XOAUTH2-Format für den Zugriff auf test@contoso.onmicrosoft.com mit Zugriffstoken EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA wie folgt:
base64("user=test@contoso.onmicrosoft.com^Aauth=Bearer EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA^A^A")
Nach der Base64-Kodierung wird dieses Format in die folgende Zeichenfolge übersetzt. Die Zeilenumbrüche werden aus Gründen der Lesbarkeit eingefügt.
dXNlcj10ZXN0QGNvbnRvc28ub25taWNyb3NvZnQuY29tAWF1dGg9QmVhcmVy
IEV3QkFBbDNCQUFVRkZwVUFvN0ozVmUwYmpMQldaV0NjbFJDM0VvQUEBAQ==
Im Fall des Zugriffs auf freigegebene Postfächer mithilfe von OAuth muss eine Anwendung das Zugriffstoken im Namen eines Benutzenden abrufen, aber das Feld userName in der SASL XOAUTH2-codierten Zeichenfolge durch die E-Mail-Adresse des freigegebenen Postfachs ersetzen.
Um eine IMAP-Serververbindung zu authentifizieren, muss der Client mit einem AUTHENTICATE-Befehl im folgenden Format antworten:
AUTHENTICATE XOAUTH2 <base64 string in XOAUTH2 format>
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem erfolgreichen Authentifizierungserfolg führt:
[connection begins]
C: C01 CAPABILITY
S: * CAPABILITY … AUTH=XOAUTH2
S: C01 OK Completed
C: A01 AUTHENTICATE XOAUTH2 dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0Q2cBAQ==
S: A01 OK AUTHENTICATE completed.
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem Authentifizierungsfehler führt:
[connection begins]
S: * CAPABILITY … AUTH=XOAUTH2
S: C01 OK Completed
C: A01 AUTHENTICATE XOAUTH2 dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0Q2cBAQ==
S: A01 NO AUTHENTICATE failed.
Um eine POP-Serververbindung zu authentifizieren, muss der Client mit einem AUTH-Befehl antworten, der in zwei Zeilen im folgenden Format unterteilt ist:
AUTH XOAUTH2
<base64 string in XOAUTH2 format>
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem erfolgreichen Authentifizierungserfolg führt:
[connection begins]
C: AUTH XOAUTH2
S: +
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYX
JlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMjl0
Q2cBAQ==
S: +OK User successfully authenticated.
[connection continues...]
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem Authentifizierungsfehler führt:
[connection begins]
C: AUTH XOAUTH2
S: +
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ=
S: -ERR Authentication failure: unknown user name or bad password.
Um eine SMTP-Serververbindung zu authentifizieren, muss der Client mit einem AUTH-Befehl im folgenden Format antworten:
AUTH XOAUTH2 <base64 string in XOAUTH2 format>
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem erfolgreichen Authentifizierungserfolg führt:
[connection begins]
C: auth xoauth2
S: 334
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ==
S: 235 2.7.0 Authentication successful
[connection continues...]
Beispiel für einen Client-Server-Nachrichtenaustausch, der zu einem Authentifizierungsfehler führt:
[connection begins]
C: auth xoauth2
S: 334
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVRjMk52YjNSbGNrQmhkSFJoZG1semRHRXVZMj
l0Q2cBAQ==
S: 535 5.7.3 Authentication unsuccessful [SN2PR00CA0018.namprd00.prod.outlook.com]
Dienstprinzipale in Exchange werden verwendet, um Anwendungen den Zugriff auf Exchange-Postfächer über den Clientanmeldeinformationsfluss mit den SMTP-, POP- und IMAP-Protokollen zu ermöglichen.
Wählen Sie im Azure-Portal das Blatt API-Berechtigungen in der Verwaltungsansicht Ihrer Microsoft Entra-Anwendung aus.
Wählen Sie Berechtigung hinzufügen aus.
Wählen Sie die Registerkarte APIs, die meine Organisation verwendet aus und suchen Sie nach „Office 365 Exchange Online“.
Klicken Sie auf Anwendungsberechtigungen.
Wählen Sie für den POP-Zugriff die Berechtigung POP.AccessAsApp aus. Wählen Sie für den IMAP-Zugriff die Berechtigung IMAP.AccessAsApp aus. Wählen Sie für den SMTP-Zugriff die Berechtigung SMTP.SendAsApp aus.
Der folgende Screenshot zeigt die ausgewählten Berechtigungen:
Nachdem Sie den Berechtigungstyp ausgewählt haben, wählen Sie Berechtigungen hinzufügen aus.
Sie sollten nun über die Berechtigungen der SMTP-, POP- oder IMAP-Anwendung verfügen, die den Berechtigungen Ihrer Entra AD-Anwendung hinzugefügt wurden.
Um über POP oder IMAP auf Exchange-Postfächer zuzugreifen, muss Ihre Entra AD-Anwendung die Zustimmung des Mandantenadmins für jeden Mandanten einholen. Weitere Informationen finden Sie unter Mandantenadmin-Zustimmungsprozess.
Wenn Ihr ISV/Partner die Microsoft Entra-Anwendung mit der Option „Konten in jedem Organisationsverzeichnis“ registriert hat, müssen Sie diese Anwendung hinzufügen und ihr mithilfe der folgenden Schritte zustimmen, indem Sie die URL der Autorisierungsanforderung verwenden.
In Ihrer OAuth 2.0-Mandantenautorisierungsanforderung sollte der scope-Abfrageparameter „https://ps.outlook.com/.default“ sowohl für den POP- als auch den IMAP-Anwendungsbereich gelten.
Die OAuth 2.0-Autorisierungsanforderungs-URL wird im folgenden Beispiel gezeigt:
https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&scope=https://ps.outlook.com/.default
In Ihrer OAuth 2.0-Mandantenautorisierungsanforderung sollte der scope-Abfrageparameter „https://outlook.office365.com/.default“ nur für SMTP gelten. Die OAuth 2.0-Autorisierungsanforderungs-URL wird im folgenden Beispiel gezeigt:
https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?client_id=<CLIENT_ID>&redirect_uri=<REDIRECT_URI>&scope=https://outlook.office365.com/.default
Wenn Sie Ihre Anwendung in Ihrem eigenen Mandanten mit „Nur Konten in diesem Organisationsverzeichnis“ registriert haben, können Sie fortfahren und die Anwendungskonfigurationsseite im Microsoft Entra Admin Center verwenden, um die Adminzustimmung zu erteilen, und Sie müssen nicht den Ansatz mit der Autorisierungsanforderungs-URL verwenden.
Der folgende Screenshot zeigt, wie Sie über die Anwendungskonfigurationsseite im Microsoft Entra Admin Center die Adminzustimmung erteilen.
Sobald ein Mandantenadmin Ihrer Microsoft Entra-Anwendung zustimmt, muss er den Dienstprinzipal Ihrer Entra AD-Anwendung in Exchange über Exchange Online PowerShell registrieren. Diese Registrierung wird durch das New-ServicePrincipal Cmdlet aktiviert.
Um das Cmdlet New-ServicePrincipal zu verwenden, installieren Sie ExchangeOnlineManagement und stellen Sie eine Verbindung mit Ihrem Mandanten her, wie im folgenden Codeausschnitt gezeigt:
Install-Module -Name ExchangeOnlineManagement
Import-module ExchangeOnlineManagement
Connect-ExchangeOnline -Organization <tenantId>
Wenn beim Ausführen des Cmdlets New-ServicePrincipal nach dem Ausführen dieser Schritte immer noch ein Fehler auftritt, liegt dies wahrscheinlich daran, dass die benutzende Person nicht über ausreichende Berechtigungen in Exchange Online verfügt, um den Vorgang auszuführen.
Die Registrierung des Dienstprinzipals einer Microsoft Entra-Anwendung in Exchange wird im folgenden Beispiel gezeigt:
New-ServicePrincipal -AppId <APPLICATION_ID> -ObjectId <OBJECT_ID> [-Organization <ORGANIZATION_ID>]
Der Mandantenadmin kann die oben genannten Dienstprinzipalbezeichner in der Unternehmensanwendungsinstanz Ihrer Entra AD-Anwendung auf dem Mandanten finden. Die Liste der Unternehmensanwendungsinstanzen auf dem Mandanten finden Sie auf dem Blatt Unternehmensanwendungen in der Microsoft Entra-Ansicht im Azure-Portal.
Sie können den Bezeichner Ihres registrierten Dienstprinzipals mithilfe des Get-ServicePrincipal Cmdletsabrufen.
Get-ServicePrincipal | fl
Die OBJECT_ID ist die Objekt-ID von der Übersichtsseite des Unternehmensanwendungsknotens (Azure-Portal) für die Anwendungsregistrierung. Es handelt sich nicht um die Objekt-ID von der Übersichtsseite des Knotens „App-Registrierungen“. Die Verwendung der falschen Objekt-ID führt zu einem Authentifizierungsfehler.
Der folgende Screenshot zeigt ein Beispiel, in dem die richtige Objekt-ID gefunden wird, die mit „6d“ beginnt:
Der Mandantenadmin kann nun die spezifischen Postfächer im Mandanten hinzufügen, auf die Ihre Anwendung zugreifen darf. Diese Konfiguration erfolgt mit dem Add-MailboxPermission Cmdlet.
Das folgende Beispiel zeigt, wie Sie dem Dienstprinzipal Ihrer Anwendung Zugriff auf ein Postfach gewähren:
Add-MailboxPermission -Identity "john.smith@contoso.com" -User
<SERVICE_PRINCIPAL_ID> -AccessRights FullAccess
Unterschiedliche IDs werden bei der Erstellung des Exchange-Dienstprinzipals sowie später auch bei der Erteilung von Postfachberechtigungen verwendet.
Optionales Beispiel:
Das folgende Beispiel kann Ihnen dabei helfen, die richtige ID für die verschiedenen Phasen zu verwenden. In diesem Beispiel werden Microsoft Entra-Cmdlets verwendet. Daher müssen Sie das Microsoft Entra PowerShell-Modul installieren, sofern noch nicht geschehen. Weitere Informationen finden Sie unter Microsoft Entra PowerShell für Graph installieren.
$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 $($AADServicePrincipalDetails.Displayname)"
Add-MailboxPermission -Identity "john.smith@contoso.com" -User $EXOServicePrincipal.Identity -AccessRights FullAccess
Ihre Microsoft Entra-Anwendung kann jetzt über das SMTP-, POP- oder IMAP-Protokoll über den OAuth 2.0-Clientanmeldeinformations-Gewährungsflow auf die zulässigen Postfächer zugreifen. Weitere Informationen finden Sie in den Anweisungen unter Berechtigungen und Zustimmung in der Microsoft Identity Platform.
Sie müssen https://outlook.office365.com/.default in der Eigenschaft „scope“ in der Textnutzlast für die Zugriffstokenanforderung verwenden.
Die generierten Zugriffstoken können wie zuvor beschrieben als Token zum Authentifizieren von SMTP-, POP- und IMAP-Verbindungen über das SASL XOAUTH2-Format verwendet werden.
Hinweis
Wenn Sie versuchen, den Flow zur Gewährung von Clientanmeldeinformationen mit SendAs zu verwenden, müssen Sie der absendenden Person SendAs-Berechtigungen erteilen: Add-RecipientPermission (ExchangePowerShell).
Training
Modul
Die Dienstprinzipal-Authentifizierung mit benutzerdefinierten Konnektoren verwenden - Training
Erfahren Sie, wie Sie die Dienstprinzipal-Authentifizierung mit benutzerdefinierten Konnektoren verwenden.
Zertifizierung
Microsoft Certified: Identity and Access Administrator Associate - Certifications
Veranschaulichen der Features von Microsoft Entra ID, um Identitätslösungen zu modernisieren sowie Hybridlösungen und Identitätsgovernance zu implementieren