Wir haben eine Dienstanwendung geschrieben, die Office 365-Kalenderinformationen aus mehreren Kalendern in einer Organisation (Mandant) liest und einige Analysen mit den Einträgen durchführt. Wir verwenden hierfür die Office 365 REST-API.
Wir haben mehrere Client-Organisationen (Mandanten), die diese Funktionalität benötigen. Daher habe ich die Schritte in @ befolg@ Matthias Leibmann Artikel hier:Building Daemon oder Service Apps mit Office 365 Mail-, Kalender- und Kontakt-APIs (OAuth2-Client-Anmeldeinformationsfluss)

Wir haben während der Entwicklung ein Azure-Testkonto und ein Office 365-Testabonnement verwendet. Alles funktioniert sehr gut, und wir haben erfolgreich auf Daten mehrerer Mandanten zugegriffen.
Als ich jedoch versuchte, die mandantenfähige Anwendung unter Verwendung unseres Azure-Produktionskontos und von Azure Active Directory (AAD) einzurichten, stellte ich fest, dass ich die für "Office 365 Exchange Online" erforderlichen Anwendungsberechtigungen nicht in den "Berechtigungen" definieren kann zu anderen Anwendungen “auf der Benutzeroberfläche, da unser Produktions-AAD-Konto nicht mit einem Office 365-Konto verknüpft ist.
Ich gehe davon aus, dass wir uns mit unserem Azure-Produktionskonto für eine Entwicklertestversion von Office 365 anmelden können. Auf diese Weise können wir die erforderlichen Berechtigungen festlegen. Ich weiß jedoch nicht, was in 30 Tagen nach Ablauf der Office 365-Testversion passieren wird.

Gibt es eine Möglichkeit, diese erforderlichen Berechtigungen zu definieren, ohne dass ein Office 365-Konto mit unserem Produktions-AAD verknüpft ist?
Ist dies nur ein Tooling-Problem im Azure-Front-End oder gibt es einen technischen Grund, warum wir ein eigenes Office 365-Abonnement benötigen, obwohl wir immer eine Verbindung mit dem Office 365-Konto eines anderen Unternehmens herstellen?