Microsoft OAuth 2.0 - Vorbedingungen für den automatischen Erhalt von Zugangstokens

Hallo zusammen,

Microsoft entfernt die Möglichkeit die Standardauthentifizierung in Exchange Online zu verwenden. Diese Entscheidung erfordert, dass Kunden von Apps, die die Standardauthentifizierung verwenden, zu Apps wechseln, die die moderne Authentifizierung verwenden (OAuth 2.0-tokenbasierte Autorisierung).

Da dieses Thema in letzter Zeit häufiger im Support diskutiert wurde, stellen wir euch ein Einstiegs-Dokument bereit, in dem es um die Vorbedingungen für den automatischen Erhalt von Zugangstokens geht.

Microsoft OAuth2.0 – Pre conditions to obtain access tokens automatically.pdf (250,1 KB)

Sobald die Vorbedingungen erfüllt sind, lässt sich mit einem X4-Projekt der Token abrufen und anschließend bspw. im IMAP-Adapter verwenden. Wir haben ein X4-Beispielprojekt erstellt, den wir euch zur Verfügung stellen können. Schreibt dazu gerne den Support an, falls Ihr Interesse an dem Beispielprojekt habt.

Viele Grüße
Daniel

Eine Anmerkung dazu:
In der oben verlinkten Anleitung findet sich ein link zu Dokumentation von Microsoft (Authenticate an IMAP, POP or SMTP connection using OAuth | Microsoft Learn)

Dort wird beschrieben, welche PowerShell commands notwendig sind, um per clients credential flow Mails abzurufen.
Falls sich nachdem Ausführen der PowerShell commands immernoch keine Mails abrufen lassen, dann könnte evtl. dieser Forumseintrag helfen:

Die Microsoft Doku ist da nicht spezifisch genug, welche „object id“ verwendet werden soll. Es gibt zwei: Einmal die object id in der angelegten Azure Applikation sowie die enterprise object id (deutsch: unternehmens objekt id, oder änhlich :slight_smile: ).
Hat man bereits ein ServicePrincipal mit der Applikations objekt id angelegt und der Abruf von Mails funktioniert nicht, so sollte man den alten ServicePrincipal löschen und neu anlegen mit der enterprise object id.

Bis der ServicePrincipal ordnungsemäß funktioniert, kann es einige zeit dauern (das Internet erwähnt immer so 15 bis 30min, bei einem unserer Fälle hat das aber erst nach 3h geklappt).

Zum Ausschließen von Fehlern beim Ausführen der PowerShell commands kann auch versucht werden, manuell ein Token per Authorization Code Flow mit hilfe von Postman (das postman projekt und ne kurze Anleitung gibts hier: Microsoft Identity Platform und der OAuth 2.0-Autorisierungscodeflow - Microsoft Entra | Microsoft Learn) durchzuführen. Hier müssen zusätzlich noch die „AccessAsUser“-scopes gesetzt werden (z.b. IMAP.AccessAsUser.All für IMAP).
Bekommt man damit ein Token, kann dies manuell in den Mail Adapter kopiert werden. Falls das Token funktioniert, dann lief beim Ausführen der PowerShell commands etwas schief.

Das abholen eines token per client credential flow (das ist der Flow, den die PowerShell commands ermöglichen) kann ebenfalls mit dem oben verlinkten postman Projekt getestet werden (Aufruf: „user client credential with shared secret“).