Können normale Benutzer Anwendungsberechtigungen in Microsoft Entra ID genehmigen?

Nein. Anwendungsberechtigungen arbeiten ohne angemeldeten Benutzer und gelten mandantenweit. Deshalb kann nur ein Administrator mit entsprechenden Mandantenrechten Anwendungsberechtigungen erteilen.

Delegierte vs. Anwendungsberechtigungen in Microsoft Entra ID: Was Administratoren wissen müssen

Q: Was passiert, wenn ein Benutzer über eine App mit delegierten Berechtigungen auf eine Datei zugreifen möchte, für die er keine Rechte besitzt?

Auch die App wird am Zugriff auf diese Datei gehindert. Delegierte Berechtigungen übernehmen die Identität des Benutzers. Die App kann daher niemals mehr Zugriff erhalten, als der Benutzer persönlich hat.

Von Mirko Peters · 2026-10-28

Erfahren Sie die entscheidenden Unterschiede zwischen delegierten und Anwendungsberechtigungen in Microsoft Entra ID, einschließlich bewährter Sicherheitsmethoden und der Regeln für das Least-Privilege-Prinzip.

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

Wenn Sie Drittanbieter-Tools oder eigene Anwendungen in Ihre Microsoft 365-Umgebung integrieren, ist es entscheidend, den Unterschied zwischen delegierten und Anwendungsberechtigungen zu verstehen. Nur so lassen sich die Cloud-Sicherheit wahren, Datenabflüsse verhindern und das Least-Privilege-Prinzip in Microsoft Entra ID durchsetzen.

Das Wichtigste in Kürze

Delegierte Berechtigungen setzen einen angemeldeten Benutzer voraus und handeln in dessen Namen. Die App kann daher nur auf Daten zugreifen, die der Benutzer selbst einsehen darf.
Anwendungsberechtigungen arbeiten ohne menschlichen Benutzer. Sie gewähren weitreichenden Zugriff auf einen gesamten Mandanten und erfordern die Genehmigung durch einen Administrator.
Das Least-Privilege-Prinzip besagt, dass Apps stets nur die kleinste Menge an Berechtigungen erhalten sollten, die sie für ihre Aufgabe benötigen.
Microsoft Graph fungiert als zentraler Zugangspunkt zu den Daten von Microsoft 365 und stützt sich stark auf diese Berechtigungsmodelle.
Das Verständnis dieses Unterschieds verhindert gravierende Sicherheitslücken, etwa die unbeabsichtigte mandantenweite Freigabe für Drittanbieter-Anwendungen.

OAuth-Berechtigungen in der Microsoft Cloud verstehen

Wenn Sie ein externes Produktivitätstool oder ein internes Automatisierungsskript mit Ihrem Microsoft 365-Arbeitsbereich verbinden, startet dabei ein OAuth 2.0-Ablauf im Hintergrund. Ein Zugriffstoken zu erhalten ist allerdings nur die halbe Miete. Die eigentliche Sicherheitsgrenze bestimmt, was dieses Token tatsächlich tun darf. Im Microsoft-Identitätsökosystem, das auf Microsoft Entra ID (früher Azure Active Directory) basiert, werden Berechtigungen in zwei grundlegend verschiedene Typen unterteilt: delegierte Berechtigungen und Anwendungsberechtigungen.

Diese beiden Modelle zu verwechseln, gehört für IT-Administratoren, Entwickler und Power-User gleichermaßen zu den häufigsten Stolpersteinen. Wählen Sie den falschen Berechtigungstyp, können Sie unternehmensweite Daten ungewollt offenlegen oder die Funktion einer Anwendung vollständig unterbrechen. Schauen wir uns an, wie die einzelnen Typen funktionieren, wo sie verankert sind und wie Sie sie richtig steuern.

Delegierte Berechtigungen: Handeln im Namen eines Benutzers

Delegierte Berechtigungen sind für Apps gedacht, bei denen ein Mensch vor dem Bildschirm sitzt. Wenn Sie sich mit Ihrem Microsoft-Konto bei einer mobilen App oder einem Webdienst anmelden, leiht die App Ihre Identität für einen bestimmten Satz von Aufgaben aus. Man spricht dann von einer delegierten Berechtigung.

In diesem Szenario handelt die App als Sie. Sie kann nur auf Daten zugreifen, für die Sie selbst bereits eine Berechtigung besitzen, und nicht mehr. Hat Ihr Benutzerkonto keinen Lesezugriff auf einen bestimmten SharePoint-Ordner oder den Kalender einer Kollegin oder eines Kollegen, kann die App ebenfalls nicht darauf zugreifen. Da der mögliche Schaden durch die Berechtigungen des einzelnen Benutzers natürlich begrenzt ist, empfiehlt Microsoft delegierte Berechtigungen überall dort, wo ein Mensch in den Workflow eingebunden ist.

So zeigen sich delegierte Berechtigungen in der Praxis

Mit delegierten Berechtigungen kommen Sie jedes Mal in Berührung, wenn Sie eine Zustimmungsabfrage bestätigen. Ein Terminassistent zeigt beispielsweise einen Bildschirm, auf dem steht, dass er Ihren Kalender lesen möchte. Diese Anfrage entspricht einem bestimmten OAuth-Scope. Da Sie anwesend sind, um die Anfrage zu genehmigen oder abzulehnen, agieren Sie als Ressourceneigentümer und bestimmen genau, was die Clientanwendung aus Ihrem Profil nutzen darf.

Anwendungsberechtigungen: Hintergrunddienste und mandantenweiter Zugriff

Anwendungsberechtigungen folgen einem völlig anderen Prinzip. Sie sind für Hintergrunddienste, automatisierte Synchronisierungsskripte und Backend-Dienste gedacht, die um drei Uhr morgens laufen, wenn kein Benutzer angemeldet ist. Denken Sie an ein automatisiertes Reporting-Tool, das Daten aus allen Postfächern der Organisation zusammenführt.

Da kein Benutzer vorhanden ist, der einen Identitätskontext liefert, authentifiziert sich die Anwendung mit eigenen Anmeldedaten, etwa einer Client-ID und einem Clientgeheimnis (Client Secret) über den Client-Credentials-Flow. Daher erlauben Anwendungsberechtigungen dem Tool, im Namen der Anwendung auf die gesamte Organisation zuzugreifen. Hat eine App Anwendungsberechtigungen zum Lesen von E-Mails, kann sie die Postfächer jedes einzelnen Benutzers im Mandanten lesen.

Warum die Administratorzustimmung zwingend erforderlich ist

Angesichts der enormen Macht von Anwendungsberechtigungen können normale Benutzer diesen nicht selbst zustimmen. Ein Standardmitarbeiter kann eine delegierte Berechtigung für den eigenen Kalender genehmigen, Anwendungsberechtigungen erfordern dagegen die ausdrückliche Zustimmung eines globalen Administrators oder eines Administrators für privilegierte Rollen. Diese strenge Kontrolle verhindert, dass schädliche oder schlecht programmierte Apps unbemerkt organisationsweite Daten abgreifen.

Microsoft Graph und die Rolle von OAuth-Bereichen

Ob eine Anwendung delegierte oder Anwendungsberechtigungen nutzt, sie leitet ihre Anfragen letztlich über ein zentrales, leistungsstarkes Gateway: Microsoft Graph. Jeder Teams-Chat, jedes SharePoint-Dokument, jede OneDrive-Datei und jede Outlook-E-Mail ist hinter Microsoft Graph erreichbar, sofern die aufrufende Anwendung ein gültiges OAuth-Zugriffstoken vorlegt.

Die Leitplanken, die diese Token kontrollieren, heißen Bereiche (Scopes). Ein Scope ist eine präzise Kennzeichnung im Token, die die genauen Grenzen festlegt, etwa das Lesen eines Kalenders im Unterschied zum Senden einer E-Mail. Fordern Entwickler zu weit gefasste Bereiche an, etwa Lese- und Schreibzugriff, obwohl einfacher Lesezugriff genügen würde, verstoßen sie gegen grundlegende Sicherheitsprinzipien. Administratoren müssen diese Bereiche bei der Überprüfung von App-Registrierungen sorgfältig prüfen.

Das Least-Privilege-Prinzip in Ihrem Mandanten durchsetzen

Sicherheitsempfehlungen in Microsoft Entra ID laufen immer auf eine zentrale Grundregel hinaus: das Least-Privilege-Prinzip. Jede App, jeder Dienstprinzipal und jedes Automatisierungsskript sollte nur das absolute Mindestmaß an Zugriff erhalten, das für die Aufgabe nötig ist.

Bevorzugen Sie immer delegierte Berechtigungen gegenüber Anwendungsberechtigungen, wenn ein Mensch mit der App interagiert.
Prüfen Sie Zustimmungsdialoge genau, um sicherzustellen, dass Apps keine unnötigen Bereiche anfordern.
Überprüfen Sie regelmäßig die in Microsoft Entra ID registrierten Unternehmensanwendungen, um verwaiste Token oder nicht genutzte App-Registrierungen zu widerrufen.
Stellen Sie sicher, dass jeder Client-Credentials-Flow in headless Umgebungen administrativ überwacht wird.

Fazit

Wer die Mechanik moderner Cloud-Identitäten verstehen will, muss über die einfachen Anmeldeschaltflächen hinausblicken und die zugrunde liegenden Berechtigungsstrukturen betrachten. Ob Sie mobile Benutzer-Apps mit delegierten Bereichen verwalten oder umfangreiche Unternehmensautomatisierungen mit Anwendungsberechtigungen: Diese Grenzen zu verstehen, ist für eine sichere Microsoft-365-Umgebung unverzichtbar.

Um tiefer in die Grundlagen dieser Abläufe einzusteigen, hören Sie sich die vollständige Folge des Podcasts an. Dort erhalten Sie eine verständliche Erklärung zu OAuth 2.0, den Lebenszyklen von Token und den vier Akteuren jedes Autorisierungsablaufs.

Häufige Fragen

Können normale Benutzer in Microsoft Entra ID Anwendungsberechtigungen genehmigen?

Nein. Anwendungsberechtigungen funktionieren ohne angemeldeten Benutzer und wirken mandantenweit. Daher kann nur ein Administrator mit entsprechenden Mandantenrechten Anwendungsberechtigungen erteilen.

Was passiert, wenn ein Benutzer über eine App mit delegierten Berechtigungen auf eine Datei zugreifen möchte, für die er keine Rechte besitzt?

Auch die App wird dann am Zugriff auf diese Datei gehindert. Delegierte Berechtigungen übernehmen die Identität des Benutzers, daher kann die App niemals mehr Zugriff erhalten, als der Benutzer selbst hat.

Was ist das größte Sicherheitsrisiko von Anwendungsberechtigungen?

Da Anwendungsberechtigungen Hintergrunddienste ohne menschliche Aufsicht ausführen, kann ein kompromittierter App-Zugangsdaten einem Angreifer uneingeschränkten Zugriff auf unternehmensweite Postfächer, Dateien und Ressourcen verschaffen.

Wie arbeitet Microsoft Graph mit OAuth-Token und Berechtigungen zusammen?

Microsoft Graph dient als API-Gateway für Microsoft 365. Jede Anfrage an Graph muss ein OAuth-Zugriffstoken enthalten, das bestimmte Bereiche (Scopes) integriert, die entweder delegierte oder Anwendungsberechtigungen definieren.