MS Graph: Erhalte oAuth Zugriffstoken von Admin anstatt von User

Question

Hallo, ich will über MS Graph auf die freigegebenen Kalender eines Users in einer Firma zugreifen können.

Der Ablauf ist folgender: Ich leite in meinem Verwaltungs-Portal auf die Microsoft Login-Seite weiter. Dort gibt der Kunde die Zugangsdaten des User ein, der auf die Kalender zugreifen will. Microsoft schickt dann die für mich relevanten Daten (User, Zugriffstoken und Refreshtoken) an die angegebene Redirect-URI. Die für mich relevanten Permission ist Calendars.ReadWrite.Shared

Bei einigen meiner Kunden ist es jedoch so, dass ein Admin die Freigaben bestätigen muss. Da öffnet sich nachdem der User seine Zugangsdaten eingegeben hat eine weitere Seite, auf der ein Admin bestätigen muss (mit den Zugangsdaten des Admins). In diesen Fällen erhalte ich dann in der Redirect-URI nicht die Daten des Users, sondern die Daten des Admins, der bestätigt hat (Mail, oAuth-Token usw). Damit kann ich natürlich nicht auf die Kalender zugreifen.

Meine Fragen:

1.) Lässt sich das serverseitig im Azure irgendwie konfigurieren, dass nicht der Token des Admins der die Freigabe macht gesendet wird, sondern der Token desjenigen für den die Freigabe erteilt wird?

2.) Kann ich clientseitig einstellen/erzwingen, dass die Token des richtigen Users geschickt werden?

3.) Gibt es vielleicht generell ein Ablaufproblem?

Falls es hilft:
Der Client ist eine Node.js Anwendung und die Authentifizierung erfolge mittels passport und der passport-microsoft-strategy.

Diese scopes sind in meinem Client definiert: openid profile offline_access user.read calendars.readwrite.shared calendars.readwrite

Beste Grüße

Hubert

Answer 1

Hallo Hubert,

Du entwickelst wahrscheinlich eine clientseitige Node.js-Anwendung, die OAuth 2.0-Authentifizierung verwendet und normalerweise als Daemon oder Dienstkonto dient. Der empfohlene Ansatz besteht darin, die Daemon-App mit der Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) für Node.js zu erstellen.

Der anzufordernde Bereich für einen Anmeldeinformationsfluss für Clients ist der Name der Ressource, gefolgt von /.default. Durch diese Notation weiß Microsoft Entra ID, dass die Berechtigungen auf Anwendungsebene verwendet werden sollen, die im Zuge der Anwendungsregistrierung statisch deklariert wurden. Außerdem müssen diese API-Berechtigungen von einem Mandantenadministrator gewährt werden. Weitere Informationen findest Du hier:

Tutorial: Aufrufen der Microsoft Graph-API in einer Node.js-Konsolen-Daemon-App

Bei Daemonanwendungen ist vorab eine Einwilligung des Mandantenadministrators für den Aufruf der Web-API durch die Anwendung erforderlich. Diese Einwilligung wird ebenfalls auf der Seite API-Berechtigungen durch einen Mandantenadministrator angegeben. Dieser wählt dazu Administratoreinwilligung erteilen für unsere Organisation aus, wie in diesem Artikel erläutert:

Registrieren von Daemon-Apps, die Web-APIs aufrufen

Wenn Daemons, Dienste oder andere nicht interaktive Anwendungen (ohne Benutzerinteraktion) auf Deine API zugreifen sollen, anstelle delegierter Berechtigungen musst Du Anwendungsberechtigungen verfügbar machen. Verwendet die API, die Du aufrufst, Anwendungsberechtigungen?

Der Microsoft Entra-Mandantenadministrator kann die Sicherheit durch Beschränken der Tokenausstellung auf Client-Apps, denen App-Rollen (Anwendungsberechtigungen) zugewiesen wurden, erhöhen. Wenn einer Client-App keine App-Rollen zugewiesen wurden, gibt Microsoft Entra ID eine Fehlermeldung an den Client zurück, wie in der folgenden Dokumentation beschrieben:

Geschützte Web-API: App-Registrierung

Gruß,

Ivan Dragov

Answer 2

Hallo Ivan,

vielen Dank für die rasche Rückmeldung.

Bei meinem Programm handelt es sich um einen Online Service (Linux, Dockerized), der auf einem Server läuft.

Ich stelle ein Verwaltungsportal zur Verfügung, auf dem meine Kunden ihre Zugänge (= Office-365 User) hinzufügen können.

Diese User haben Zugriff auf freigegebene Ressourcen-Kalender.

Ich speichere in meiner DB den Zugriffstoken (+ RefreshToken) für jeden User und nutze diese Token später für den Zugriff auf die Graph-API (finden der freigegebenen Kalender, synchronisieren der Termine, Eintragen von neuen Terminen, usw.).

Dieser Ablauf funktioniert seit Jahren ziemlich gut. Nur haben mich jetzt Kunden darauf aufmerksam gemacht, dass es nicht möglich ist, einen User hinzuzufügen, wenn davor noch die Bestätigung eines Administrators benötigt wird. Dann erhalte ich im Callback bei der Redirect-URI nämlich nicht den User, sondern den Administrator.

Sie lösen dieses Problem derzeit so, dass der User kurzfristig Admin-Rechte bekommt (dadurch braucht man keinen zusätzlichen Admin für die Bestätigung). Und die Admin-Rechte werden im Anschluss wieder entzogen.

Das ist natürlich ziemlich unschön und ich glaube nicht, dass das so gewollt ist.

In meiner App habe ich folgende API-Berechtigungen konfiguriert:
Calendars.ReadWrite.Shared (Delegiert) - Für den Zugriff auf die freigegebenen Kalender
User.Read (Delegiert)

Beste Grüße

Hubert Antlinger

Answer 3

Nochmal Hallo,

ich habe mich mal in das Thema der Anwendungsberechtigungen eingelesen und kann mir jetzt vorstellen, dass ich den Zugriff auf die Ressourcenkalender direkt durchführen kann. Ohne den "Umweg" über einen User, welcher Zugriff auf die Kalender hat.

Die Idee des Zugriffs über den User ist historisch gewachsen aus dem alten Ablauf der Zugriffe auf on premise Exchange Server. Möglicherweise ist das jetzt mit Office365 und Graph nicht mehr nötig.

Auch wenn das nicht das Ursprungsproblem (Zugrifftoken zu Admin-User) löst, kann ich mir vorstellen, damit den Kalenderzugriff umsetzen zu können.

Vielen Dank für den Wink mit dem Zaunpfahl.

Hubert Antlinger