OAuth 2.0 in Microsoft Graph entschlüsselt: delegierte und Anwendungsberechtigungen

Von Mirko Peters · 2026-08-11 · Aktualisiert 2026-08-28

Willkommen zurück im Blog! Wenn Sie sich intensiv mit der Automatisierung in Microsoft 365 beschäftigen, sind Sie vermutlich schon auf die Grenzen gestoßen, die native Konnektoren und klassische …

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Blog! Wenn Sie sich intensiv mit der Automatisierung in Microsoft 365 beschäftigen, sind Sie wahrscheinlich schon auf die Grenzen gestoßen, die native Konnektoren und klassische Skripting-Möglichkeiten setzen. Die Komplexität der Authentifizierung kann bei der Automatisierung von M365 knifflig sein, besonders wenn Sie eine solide Sicherheit mit einer nahtlosen Funktionalität in Einklang bringen wollen. Ob Sie individuelle Unternehmensanwendungen entwickeln oder automatisierte Hintergrundprozesse einrichten: Ein sicheres Verständnis der Authentifizierungsmodelle ist entscheidend. Dieser Beitrag erklärt Token, Bereiche (Scopes) und Zustimmungsabläufe, damit Sie das passende Modell für benutzerzentrierte Anwendungen oder unbeaufsichtigte Hintergrundaufträge auswählen können. Tauchen wir direkt ein und schauen uns an, wie OAuth 2.0 die Microsoft Graph API antreibt.

Einführung in die Authentifizierung bei Microsoft Graph

Microsoft Graph ist das einheitliche Gateway zum gesamten Microsoft-365-Ökosystem. Anstatt mit getrennten, fragmentierten APIs für Exchange, SharePoint, Teams und Azure Active Directory (heute Microsoft Entra ID) zu arbeiten, können Entwickler und IT-Administratoren all diese Dienste über einen einzigen Endpunkt ansprechen. Da Graph den Zugriff auf sensible Unternehmensdaten steuert, erfordert die Absicherung dieses Gateways jedoch ein strenges Authentifizierungsframework. Der erste Schritt zu zuverlässigen, sicheren Automatisierungen, die unter Last nicht auseinanderfallen und keine Sicherheitswarnungen auslösen, ist zu verstehen, wie Identität, Zugriffstoken und Berechtigungen zusammenwirken.

OAuth 2.0 im Kontext von Microsoft 365 verstehen

Im Kern stützt sich Microsoft Graph für die Autorisierung auf das Protokoll OAuth 2.0. Wenn Ihre Anwendung oder Ihr Skript mit Graph kommunizieren möchte, kann es Anmeldedaten nicht einfach im Klartext übertragen. Stattdessen muss es ein Zugriffstoken bei der Microsoft Identity Platform (Entra ID) anfordern. Dieses Zugriffstoken fungiert als sicherer digitaler Ausweis. Es zeigt Microsoft Graph, wer die Anfrage stellt, welche Anwendung verwendet wird und vor allem, welche konkreten Berechtigungen (Scopes) diesem Token gewährt wurden. Ohne gültiges Token lehnt Graph die Anfrage sofort mit einem standardmäßigen Fehler für fehlende Autorisierung ab.

Delegierte Berechtigungen: Wann im Namen des Benutzers gearbeitet wird

Welches Berechtigungsmodell das richtige ist, hängt vollständig von der Art Ihrer Workload ab. Delegierte Berechtigungen sind für Apps gedacht, die im Auftrag eines angemeldeten Benutzers laufen. Verwendet eine Anwendung delegierte Berechtigungen, handelt sie im Namen des Benutzers, der gerade angemeldet ist. Führt ein Benutzer ein Skript aus, um den eigenen Kalender zu lesen oder das Profilbild zu aktualisieren, bewertet Graph die Anfrage nicht nur danach, was die Anwendung darf, sondern auch danach, worauf der einzelne Benutzer Zugriff hat. Hat der Benutzer keine Berechtigung, ein bestimmtes Postfach einzusehen, gewährt auch das delegierte Token keinen Zugriff darauf. Dieses Modell eignet sich ideal für benutzerorientierte Anwendungen, interaktive Tools und persönliche Produktivitätsskripte.

Anwendungsberechtigungen: Unbeaufsichtigte Hintergrundaufträge automatisieren

Was aber, wenn um Mitternacht ein Skript oder ein Dienst laufen soll, ohne dass ein Benutzer am Rechner sitzt? Für unbeaufsichtigte Hintergrundaufträge, Daemon-Dienste und mandantenweite Berichtswerkzeuge benötigen Sie Anwendungsberechtigungen. In diesem Modell arbeitet die Anwendung unabhängig von jedem Benutzerkontext, sie läuft unter ihrer eigenen Identität. Da kein Benutzer vorhanden ist, der sich anmeldet und interaktiv zustimmt, setzen Anwendungsberechtigungen eine ausdrückliche Vorab-Genehmigung durch einen Mandantenadministrator voraus. Nach der Erteilung kann die App auf Daten der gesamten Organisation zugreifen. Das macht dieses Modell außergewöhnlich leistungsstark für administrative Automatisierung, Onboarding-Skripte und Compliance-Überwachung, erfordert aber zugleich eine strenge Sicherheitskontrolle.

Bereiche, Token und Zustimmungsabläufe im Überblick

Begriffe rund um Authentifizierung und Autorisierung wirken manchmal überwältigend, doch wenn Sie den Ablauf Schritt für Schritt betrachten, wird der Prozess klarer. Bereiche (Scopes) sind die konkreten Berechtigungen, die Ihre Anwendung anfordert, zum Beispiel User.Read.All oder Mail.Read. Wenn ein Benutzer oder Administrator eine App autorisiert, prüft und genehmigt er genau diese Bereiche. Nach der Genehmigung stellt die Identitätsplattform ein JSON Web Token (JWT) aus. Ihr Code fügt dieses Token für jede an Microsoft Graph gesendete Anfrage in den HTTP-Autorisierungsheader ein. Eine korrekte Verwaltung der Zustimmung sorgt dafür, dass Ihre App Tokens reibungslos erhält und nicht auf unerwartete Hürden stößt.

Das Warten auf die Administratorzustimmung vermeiden

Einer der häufigsten Reibungspunkte für Entwickler und Administratoren ist das Warten auf eine administrative Genehmigung. Fordert eine Anwendung Anwendungsberechtigungen mit hohen Rechten oder sensible delegierte Bereiche an, verlangt Microsoft Entra ID unter Umständen, dass ein Administrator der Anwendung zustimmt, bevor überhaupt Tokens ausgestellt werden können. Wenn Ihre Bereitstellungspipeline davon ausgeht, dass Benutzer selbst zustimmen können, und diese plötzlich durch Mandantenrichtlinien blockiert werden, bleibt Ihre Automatisierung vollständig stehen. Um dieses Warten auf die Administratorzustimmung zu vermeiden, sollten Sie die benötigten Berechtigungen immer im Voraus planen, die geschäftliche Begründung dokumentieren und sich mit Ihren globalen Administratoren bzw. Anwendungsadministratoren abstimmen, um bei Bedarf die mandantenweite Zustimmung vorab zu konfigurieren.

Häufige Fallstricke und ihre Behebung

Auch erfahrene Entwickler stoßen bei der Arbeit mit Microsoft Graph gelegentlich auf frustrierende Autorisierungshürden. Schauen wir uns einige typische Probleme und ihre Lösung an:

• Funktioniert bei mir, schlägt bei anderen fehl: Meist liegt das an fehlender Zustimmung oder falschen Bereichen. Lösung: Dokumentieren Sie die benötigten Bereiche klar und konfigurieren Sie bei Bedarf die mandantenweite Administratorzustimmung.
• Überladene Antworten mit riesigen Datenmengen: Das Abrufen kompletter Benutzerlisten ohne Filter führt zu Timeouts und Drosselung. Lösung: Verwenden Sie $select, $top, Paginierung und Delta-Abfragen.
• Endlose 401/403-Schleifen: Ursache ist ein abgelaufenes Token oder der Einsatz eines delegierten Berechtigungstyps für einen Hintergrundjob ohne angemeldeten Benutzer. Lösung: Implementieren Sie eine robuste Tokenerneuerung und wechseln Sie für Hintergrundaufgaben zu Anwendungsberechtigungen.
• Erreichen von Ratenlimits: Antworten mit dem Statuscode 429 bedeuten, dass Sie Anfragen zu schnell senden. Lösung: Implementieren Sie exponentielles Backoff, berücksichtigen Sie den Header Retry-After und bündeln Sie Vorgänge.
• Wildwuchs bei Geheimnissen: Das Hartcodieren von Clientgeheimnissen in Skripten ist ein erhebliches Sicherheitsrisiko. Lösung: Nutzen Sie Azure Key Vault, verwaltete Identitäten oder sichere Umgebungsvariablen.

Best Practices für Sicherheit und Governance

Wenn Sie über eine API Zugriff auf Ihren Microsoft 365-Mandanten gewähren, hat Sicherheit oberste Priorität. Das Prinzip der minimalen Berechtigungen bedeutet, dass Sie nur die absolut notwendigen Bereiche anfordern sollten, damit Ihre Anwendung funktioniert. Fordern Sie niemals Directory.AccessAsUser.All an, nur um den Anzeigenamen eines Benutzers zu lesen. Führen Sie ein übersichtliches Zustimmungsregister, das festhält, welche Apps auf Ihren Mandanten zugreifen dürfen. Trennen Sie Ihre Entwicklungs-, Test- und Produktionsanwendungsregistrierungen konsequent voneinander und legen Sie einen strikten Zeitplan für die Rotation von Clientgeheimnissen und Zertifikaten fest.

Ihre ersten echten Abfragen (Beispiele)

Sobald Ihr Authentifizierungsmodell steht, können Sie Abfragen an die Graph-API senden. Hier sind einige praxisnahe Beispiele, die Sie anpassen können:

• Neue Mitarbeitende seit einem Datum:
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• Meine nächsten Besprechungen:
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• Teammitglieder einer Gruppe:
  GET /groups/{group-id}/members?$select=id,displayName,mail
• Geänderte Benutzer (Delta):
  GET /users/delta?$select=id,displayName,mail

Empfohlene Werkzeuge

Die richtigen Werkzeuge erleichtern das Erstellen und Debuggen von Microsoft Graph-Abfragen erheblich. Der Graph Explorer ist ein unverzichtbarer webbasierter Testbereich, um Endpunkte zu prüfen und Hinweise zur Zustimmung einzusehen. Zum Programmieren kapseln die Microsoft Graph SDKs (.NET, JavaScript, Python) einen großen Teil der zugrunde liegenden HTTP-Mechanik. Postman oder REST Client-Erweiterungen in Ihrer IDE eignen sich hervorragend für die Verwaltung von Sammlungen und Umgebungen, während Power Automate, Logic Apps und PowerShell die visuelle und operative Workflow-Automatisierung hervorragend übernehmen.

Häufige Fragen

Delegiert oder Anwendung – wie wähle ich aus?

Benutzerzentrierte Aufgaben lassen sich am besten über delegierte Berechtigungen abbilden. Unbeaufsichtigte Aufträge, Hintergrunddienste und umfassende administrative Aufgaben erfordern Anwendungsberechtigungen in Verbindung mit einer ordnungsgemäßen Administratoreinwilligung.

Wie vermeide ich Drosselung?

Verwenden Sie $select, um die Größe der Nutzdaten zu begrenzen, implementieren Sie Paginierung und Delta-Abfragen, bündeln Sie Anforderungen nach Möglichkeit per Batch und gestalten Sie Ihre Skripte stets so, dass sie HTTP-Statuscodes 429 mithilfe einer Wiederholungslogik sauber behandeln.

Kann ich Graph ohne Programmierung nutzen?

Ja! Sie können Endpunkte im Graph Explorer prototypisch testen und Workflows mit Power Automate orchestrieren. Für komplexe Logik sollten Sie auf offizielle SDKs oder PowerShell-Skripte umsteigen.

Ist Graph sicher genug für Compliance-Berichte?

Auf jeden Fall. Wenn Sie das Prinzip der minimalen Berechtigungen anwenden, zentrale Protokollierung nutzen, Einwilligungsprozesse prüfbar gestalten und Geheimnisse sicher verwalten, erfüllt Microsoft Graph anspruchsvolle Compliance-Anforderungen von Unternehmen.

Fazit

Die Authentifizierung in Microsoft Graph zu beherrschen, ist der entscheidende Schlüssel für jeden Administrator, Architekten oder Entwickler, der das volle Potenzial von Microsoft 365 nutzen möchte. Wer den wesentlichen Unterschied zwischen delegierten und Anwendungsberechtigungen versteht, Bereiche und Token sorgfältig verwaltet und strikte Sicherheits-Governance einhält, kann Automatisierungen entwickeln, die zugleich leistungsstark und sicher sind. Um tiefer in dieses Thema einzusteigen, Codebeispiele zu erkunden und fortgeschrittene Strategien für Fehlerbehandlung und Drosselung kennenzulernen, sehen Sie sich unbedingt die passende Podcast-Episode an: Automate Microsoft 365 with Microsoft Graph API. Viel Erfolg beim Automatisieren!