Delegierte vs. Anwendungsberechtigungen: Das richtige Modell für Ihre App auswählen

Von Mirko Peters · 2026-08-11

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

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Willkommen zurück zum Podcast und zu unserer laufenden Serie, mit der Sie Microsoft 365, Azure und die Entwicklertools beherrschen lernen, die das moderne Cloud-Ökosystem antreiben. Wenn Sie schon einmal eine Integration entwickelt, ein Skript geschrieben oder eine unternehmensweite Automatisierung mithilfe der Microsoft Graph API bereitgestellt haben, sind Sie zweifellos auf die Berechtigungshürde gestoßen. Ihren Mandanten zu sichern und gleichzeitig funktionsfähige Anwendungen zu entwickeln, ist einer der kritischsten Balanceakte, vor denen Sie als Administrator oder Entwickler stehen. Die Wahl zwischen verschiedenen Berechtigungsmodellen wirkt sich direkt auf Ihre Sicherheitslage, die Geschwindigkeit der Bereitstellung und die gesamte Systemarchitektur aus.

Um dieses komplexe Thema weiter aufzuschlüsseln, haben wir kürzlich eine ausführliche Folge aufgezeichnet. Hören Sie sich unbedingt die vollständige Audiodiskussion unter Microsoft Graph Permissions and Consent Models Explained an. In diesem begleitenden Blogbeitrag vertiefen wir diese Konzepte, untersuchen die grundlegenden Unterschiede zwischen delegierten und Anwendungsberechtigungen, beleuchten Einwilligungsmodelle, zeigen bewährte Methoden und stellen ein umfassendes Framework vor, damit Ihre Apps sicher und compliant bleiben.

Überblick über die Berechtigungen der Microsoft Graph API

Bevor wir uns den Feinheiten einzelner Autorisierungsabläufe widmen, lohnt es sich zu verstehen, was Berechtigungen der Microsoft Graph API eigentlich sind. Im Kern fungiert Microsoft Graph als einheitliches Gateway zu Daten, die in Microsoft-365-Diensten liegen, darunter Exchange Online, SharePoint, Microsoft Teams, OneDrive und Azure Active Directory (Microsoft Entra ID). Anstatt Entwickler zu zwingen, sich bei mehreren getrennten Endpunkten zu authentifizieren, stellt Microsoft Graph einen einzigen REST-API-Endpunkt bereit. Da diese API jedoch den Zugriff auf praktisch jeden Winkel des digitalen Bestands einer Organisation eröffnet, erfordert ihre Absicherung ein robustes, granulares Berechtigungsframework.

Delegierte vs. Anwendungsberechtigungen

Wenn Sie eine Anwendung im Microsoft Identity Platform registrieren, müssen Sie ausdrücklich festlegen, wie Ihre App mit Ressourcen interagieren soll. Im Kern läuft dies auf die Wahl zwischen zwei primären Berechtigungstypen hinaus: delegierte Berechtigungen und Anwendungsberechtigungen. Diese Entscheidung bestimmt, wie sich Ihre Anwendung authentifiziert, wen oder was sie repräsentiert und welche Grenzen für die Daten gelten, die sie abrufen kann.

Delegierte Berechtigungen sind für clientseitige oder benutzerorientierte Anwendungen gedacht, etwa Single-Page-Webapps, mobile Apps oder Desktop-Hilfsprogramme, bei denen ein angemeldeter Benutzer aktiv anwesend ist. In diesem Modell arbeitet Ihre App *im Auftrag des* Benutzers. Die Anwendung kann nur auf Daten zugreifen und Aktionen ausführen, für die der Benutzer selbst die Berechtigung besitzt. Startet ein Benutzer die App, wird er aufgefordert, sich anzumelden und die Einwilligung ausdrücklich zu erteilen. Daraufhin wird ein OAuth-2.0-Zugriffstoken ausgestellt, das sowohl die Identität des Benutzers als auch die eingewilligten Bereiche (Scopes) enthält.

Anwendungsberechtigungen hingegen werden von Hintergrunddiensten, Daemons, Web-Jobs und automatisierten Runbooks genutzt, die unabhängig von einem Benutzerkontext laufen. Hier agiert die App mit ihrer eigenen Identität. Sie verwendet Client-Anmeldeinformationen, etwa ein Client-Geheimnis, ein öffentliches/privates Zertifikatsschlüsselpaar oder eine verwaltete Identität, um ein reines App-Zugriffstoken von Azure AD zu erhalten. Da kein Mensch am Rechner sitzt, der sich authentifiziert, erstrecken sich diese Berechtigungen auf mandantenweite Ressourcen. Daher bergen sie deutlich höhere Sicherheitsrisiken und erfordern stets die ausdrückliche Einwilligung eines Mandantenadministrators.

Wichtigste Unterschiede und Anwendungsfälle

Wer genau weiß, wann welches Berechtigungsmodell einzusetzen ist, vermeidet architektonische Engpässe und Sicherheitslücken. Schauen wir uns einen kurzen vergleichenden Überblick an:

Delegierte Berechtigungen: Die App arbeitet für einen Benutzer. Der Benutzer muss sich anmelden und einwilligen. Die App kann nur sehen, was der Benutzer sehen kann. Dieses Modell eignet sich ideal für Client-Apps, die persönliche Daten wie individuelle Kalender oder E-Mails lesen oder schreiben.
Anwendungsberechtigungen: Die App arbeitet als eigenständige Identität. Kein Benutzer muss sich anmelden. Ein Administrator muss einwilligen. Die App kann Daten im gesamten Mandanten einsehen und ändern. Dieses Modell eignet sich ideal für Hintergrundsynchronisierung, administrative Berichte und automatisierte Governance-Jobs.

Welches Modell die richtige Wahl ist, hängt vollständig von der Architektur Ihrer Anwendung ab. Wenn Sie beispielsweise ein interaktives Dashboard entwickeln, das das Profil und den persönlichen Posteingang eines Benutzers anzeigt, müssen Sie delegierte Berechtigungen verwenden. Wenn Sie hingegen ein automatisiertes Skript entwickeln, das um Mitternacht alle Postfächer der Organisation für ein Compliance-Audit durchsucht, sind Anwendungsberechtigungen erforderlich.

Delegierte Berechtigungen in Microsoft Graph

So funktionieren delegierte Berechtigungen

Delegierter Zugriff ist eng mit der Identität des Benutzers verknüpft. Wenn Ihre Anwendung eine delegierte Berechtigung anfordert, bittet sie den Autorisierungsserver im Grunde um die Erlaubnis, sich innerhalb definierter Grenzen als der angemeldete Benutzer auszugeben. Das Zugriffstoken, das über den OAuth-Autorisierungscode-Flow zurückgegeben wird, enthält bestimmte Scope-Claims. Diese spiegeln sowohl die eigenen Rechte des Benutzers als auch die von der Anwendung angeforderten Berechtigungen wider.

Bei delegiertem Zugriff handelt Ihre App direkt im Namen des Benutzers.
Sowohl die App-Registrierung als auch der einzelne Benutzer müssen über die entsprechenden zugrunde liegenden Rechte verfügen.
Scopes legen die genaue Obergrenze dessen fest, was Ihre App im Namen des Benutzers tun kann.
Das resultierende Zugriffstoken verbindet die Identität der Anwendung und den Benutzerkontext miteinander.

Typische Szenarien für delegierte Berechtigungen

Delegierte Berechtigungen bilden die Grundlage für die meisten alltäglichen Produktivitätsintegrationen. Benötigt eine Notiz-App für Unternehmen beispielsweise, Dateien mit dem OneDrive-Konto eines Benutzers zu synchronisieren, fordert sie den Scope Files.ReadWrite an. Hat der Benutzer keine Berechtigung für ein bestimmtes Dokument, lehnt die Graph API die Anfrage ab, auch wenn der Scope der App dies technisch zulassen würde. Ähnlich verhält es sich mit Apps, die das Microsoft Graph SDK nutzen, um im Namen eines Benutzers automatisierte E-Mail-Benachrichtigungen zu versenden. Sie stützen sich auf delegierte Scopes wie Mail.Send.

Sicherheit und Zustimmung

Delegierte Berechtigungen sind grundsätzlich sicherer als mandantenweite Anwendungsberechtigungen, da sie an die Grenzen des Benutzers gebunden sind. Dennoch bringen sie eigene Sicherheitsherausforderungen mit sich. Fordert eine Anwendung zu weit gefasste Scopes an, etwa vollen Zugriff auf das gesamte Postfach und Verzeichnisprofil eines Benutzers, könnten ein erfolgreicher Phishing-Angriff oder die Kompromittierung der App sensible personenbezogene Daten offenlegen. Entwickler müssen das Prinzip der minimalen Berechtigungen konsequent einhalten und nur die Scopes anfordern, die für die unmittelbare Funktionalität erforderlich sind.

Anwendungsberechtigungen in Microsoft Graph

So funktionieren Anwendungsberechtigungen

Anwendungsberechtigungen verzichten vollständig auf den menschlichen Faktor in der Authentifizierung. Statt einer Anmeldeaufforderung authentifiziert sich die Anwendung direkt bei Microsoft Entra ID über Clientanmeldeinformationen. Das resultierende Token enthält App-Rollen statt delegierter Scopes und gewährt dem Dienstprinzipal einen umfassenden, uneingeschränkten Zugriff auf Ressourcen im gesamten Mandanten.

Anwendungsberechtigungen funktionieren vollständig ohne angemeldeten Benutzer.
Die Anwendung erhält ein reines App-Token, um Ressourcen abzufragen.
Der Zugriff wird durch die zugewiesenen App-Rollen des Dienstprinzipals gesteuert und nicht durch einzelne Benutzerrechte.

Wann Sie Anwendungsberechtigungen verwenden sollten

Beschränken Sie Anwendungsberechtigungen konsequent auf Backend-Workloads, unbeaufsichtigte Dienste (Daemons) und System-zu-System-Integrationen. Beispiele sind automatisierte Systeme zur Benutzerbereitstellung, zentrale Backup-Lösungen, Tools zur Reaktion auf Sicherheitsvorfälle und Skripte für Mandantenmigrationen.

Administratorzustimmung und Sicherheitsauswirkungen

Da Anwendungsberechtigungen die Einschränkungen einzelner Benutzer umgehen und mandantenweiten Zugriff gewähren, können normale Benutzer ihnen nicht zustimmen. Nur ein privilegierter Administrator kann die Zustimmung zu Anwendungsberechtigungen erteilen. Falsch konfigurierte Anwendungsberechtigungen, etwa Directory.ReadWrite.All oder Mail.ReadWrite.All für eine nicht vertrauenswürdige oder schlecht programmierte Hintergrund-App, können einen gesamten Microsoft 365-Mandanten einer vollständigen Kompromittierung aussetzen. Prüfen Sie die Dienstprinzipale Ihrer Unternehmensanwendungen daher regelmäßig.

Vor- und Nachteile der Berechtigungen der Microsoft Graph API

Vorteile

Einheitliches Berechtigungsmodell: Ein einheitliches, konsistentes Autorisierungsframework für alle Microsoft 365-Dienste vereinfacht die Administration.
Granulare Scopes: Fein abgestufte delegierte und Anwendungs-Scopes ermöglichen präzise Architekturen nach dem Prinzip der minimalen Berechtigungen.
Standardisiertes OAuth2/OpenID Connect: Nutzt branchenübliche Sicherheitsprotokolle für eine unkomplizierte Identitätsintegration.
RBAC-Integration: Lässt sich nahtlos in Azure AD-Rollen und Richtlinien für bedingten Zugriff einbinden und sorgt so für zentrale Compliance.
Inkrementelle Zustimmung: Ermöglicht Apps, im Laufe der Zeit zusätzliche Berechtigungen anzufragen, statt von Anfang an alles zu verlangen.

Nachteile

Komplexität: Wer die Schnittmenge aus delegierten Bereichen, App-Rollen und Modellen für die Administratorzustimmung durchblicken muss, kann von der Einarbeitung schnell überfordert sein.
Risiken durch hohe Berechtigungen: Eine falsch konfigurierte breite Berechtigung (etwa Sites.FullControl.All) kann große Mengen an Unternehmensdaten offenlegen.
Engpässe bei der Administratorzustimmung: Wenn für wirkungsvolle Berechtigungen eine administrative Genehmigung erforderlich ist, kann das agile Entwicklungszyklen ausbremsen.
Verstreute Dokumentation: Entwickler müssen häufig mehrere Microsoft-Dokumentationsquellen gegenlesen, um das genaue Verhalten der APIs nachzuvollziehen.

Zustimmungsmodelle und Best Practices

Benutzer- vs. Administratorzustimmung in Microsoft Graph

Die Art, wie Zustimmung eingeholt wird, ist für die Governance einer Organisation entscheidend. Die Benutzerzustimmung erlaubt einzelnen Personen, Apps den Zugriff auf ihre persönlichen Daten zu gestatten. Bei der Administratorzustimmung wechselt die Genehmigung zu den IT-Administratoren, die Anwendungsanfragen im Namen der gesamten Organisation prüfen. Moderne Sicherheitsbaselines im Unternehmen deaktivieren die Benutzerzustimmung häufig vollständig und leiten jede Anwendungsbereitstellung über formalisierte Workflows zur vorherigen Genehmigung durch Administratoren.

Auswirkungen von Mandantenrichtlinien auf Berechtigungen

Unternehmensweite Mandantenrichtlinien können das Laufzeitverhalten Ihrer App grundlegend verändern. Hat ein Administrator strenge Richtlinien für bedingten Zugriff festgelegt, etwa eine Pflicht zur Multi-Faktor-Authentifizierung (MFA) oder konforme, hybrid Azure AD-verbundene Geräte, wird eine App, die ein Graph-Token ohne Erfüllung dieser Kriterien anfordert, blockiert. Entwickler müssen ihre Anwendungen so gestalten, dass sie Fehler bei der Token-Anforderung sauber abfangen und verständliche Hinweise zur Behebung anzeigen.

Strategien für einen reibungslosen Zustimmungsablauf

Um Reibungsverluste für Benutzer und Blockaden durch Administratoren zu vermeiden, planen Sie Ihre Berechtigungsstrategie, bevor Sie mit dem Programmieren beginnen. Setzen Sie inkrementelle Zustimmungsmuster ein: Ihre App fordert zu Beginn nur grundlegende Identitätsbereiche an und fragt spezielle Ressourcenberechtigungen erst dann ab, wenn der Benutzer genau diese Funktionen aufruft. Nutzen Sie automatisierte Workflows zur vorherigen Genehmigung in Microsoft Entra ID, um die Entwicklung zu beschleunigen, ohne die strenge Sicherheitskontrolle aufzugeben.

Häufige Fehler im Umgang mit Berechtigungen der Microsoft Graph API

Delegierte und Anwendungsberechtigungen werden verwechselt, und die Anforderungen an den Benutzerkontext werden falsch eingeschätzt.
Es werden von Anfang an zu viele Berechtigungen angefordert, statt einem Least-Privilege-Ansatz zu folgen.
Die Anforderungen an die Administratorzustimmung werden beim Bereitstellen von Hintergrunddiensten nicht berücksichtigt.
Es wird angenommen, dass Änderungen von Berechtigungen im Azure-Portal ohne Aktualisierung des Tokens sofort wirksam werden.
Ein delegiertes Zugriffstoken wird vorgelegt, obwohl ein Clientanmeldeinformationen-Token erforderlich ist.
Richtlinien für bedingten Zugriff, die Graph-API-Anfragen zur Laufzeit blockieren, werden ignoriert.
Die Bereichsansprüche (Scope-Claims) werden zur Laufzeit im Anwendungscode nicht validiert.
Die erteilten Anwendungsberechtigungen und Dienstprinzipale werden im Laufe der Zeit nicht überprüft.

Microsoft Graph API Berechtigungs-Checkliste

Nutzen Sie diese umsetzbare Checkliste, um Ihr Team beim sicheren Entwerfen, Implementieren und Überprüfen von Microsoft Graph API-Berechtigungen zu begleiten:

Fazit

Die Berechtigungen der Microsoft Graph API müssen nicht frustrierend sein. Wenn Sie die betrieblichen Unterschiede verstehen – delegierte Berechtigungen, die eine angemeldete Person voraussetzen und an deren Benutzerkontext gebunden sind, und Anwendungsberechtigungen, die unbeschränkt im Hintergrund laufen und die Zustimmung eines Administrators erfordern –, können Sie sichere, skalierbare Lösungen entwerfen. Das Prinzip der geringsten Rechte, konsequente Überwachung und der Einsatz unternehmensweiter Governance-Werkzeuge halten Ihre Microsoft 365-Umgebung sicher, ohne Innovationen zu bremsen.

Für weitergehende Hinweise, praxisnahe Strategien und vertiefende Einblicke in die Absicherung Ihrer Cloud-Umgebung hören Sie sich unbedingt unsere vollständige Audio-Zusammenfassung zur passenden Folge an: Microsoft Graph Permissions and Consent Models Explained. Halten Sie Ihre Berechtigungen eng gefasst, Ihre Anmeldedaten sicher und viel Erfolg beim Programmieren!