Delegierte vs. Anwendungsberechtigungen

Von Mirko Peters · 2026-04-26 · Aktualisiert 2026-07-18

Vergleichen Sie delegierte und Anwendungsberechtigungen in Microsoft Entra ID und wählen Sie das passende Zugriffsmodell für sichere APIs, Automatisierung und App-Entwicklung.

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

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

Wenn Sie mit Microsoft Entra ID arbeiten, ist die Frage, wer was tun darf und unter welchen Umständen, mehr als ein technisches Detail. Sie bildet das Fundament für sichere App-Entwicklung, Automatisierung und das gesamte Identitätsmanagement in der Microsoft-Cloud. Es macht einen großen Unterschied, ob Sie Benutzern erlauben, einer App genau so viel Zugriff zu gewähren, dass sie in deren Namen handeln kann (delegierte Berechtigungen), oder ob Sie einer App die Schlüssel geben, damit sie Aufgaben eigenständig erledigt (Anwendungsberechtigungen).

Falsch konfiguriert, öffnen Sie unter Umständen die Tür für unerwünschte Datenexposition, Compliance-Probleme oder sogar Sicherheitsvorfälle. Richtig konfiguriert, ermöglichen Sie reibungslosere Automatisierung, klarere Governance und zufriedenere Prüfer. Dieser Leitfaden bietet Ihnen den vollständigen Überblick: die Grundlagen dieser Berechtigungstypen, ihr Zusammenspiel im Alltag und alle Sicherheits-, Governance- und Betriebsaspekte, die Sie für die beste Entscheidung in Ihrer Umgebung benötigen. Bringen wir die Berechtigungen an ihren richtigen Platz, denn mit großem Zugriff kommt große Verantwortung.

Hintergrund und Einführung in die Berechtigungsmodelle der Microsoft-Identität

Berechtigungen in Microsoft Entra ID sind nicht einfach Kästchen zum Ankreuzen, sondern ein grundlegendes Framework, das fest in das Zusammenspiel von Apps und Benutzern in Microsoft 365, Azure und darüber hinaus eingebettet ist. Als Microsoft die Identität in die Cloud verlagerte, brauchte es einen Weg, damit Dienste und Drittanbieter-Tools sicher miteinander interagieren können, ohne allen pauschal uneingeschränkten Zugriff zu geben. Hier kommen delegierte und Anwendungsberechtigungen ins Spiel.

Diese Modelle ermöglichen es, präzise festzulegen, wer worauf zugreifen darf, und klare Grenzen zu ziehen zwischen dem, was ein einzelner Benutzer genehmigen kann, und dem, was nur ein Administrator erlauben sollte. Sie sind das Ergebnis jahrelanger Lernprozesse, teils auf die harte Tour, mit klassischen AD-Dienstkonten und umständlichen Alles-oder-nichts-Zugriffen. Diese Modelle zu verstehen ist nicht nur gute Praxis, sondern entscheidend, um Compliance-Anforderungen zu erfüllen, Zero Trust umzusetzen und zu verhindern, dass der Betrieb wegen Sicherheitsfehlkonfigurationen ins Stocken gerät.

Anwendungsberechtigungen vs. delegierte Berechtigungen: Kernkonzepte und Praxisszenarien

Sehen wir uns den Unterschied zwischen delegierten und Anwendungsberechtigungen in einfachen Worten an. Stellen Sie sich delegierte Berechtigungen so vor, dass Ihre App als Helfer agiert: Sie erhält nur dann Zugriff, wenn ein bestimmter Benutzer angemeldet ist, und ist auf das beschränkt, was dieser Benutzer selbst tun könnte. Anwendungsberechtigungen dagegen erlauben es der App, eigenständig zu handeln, wie ein unbeaufsichtigter Manager mit eigenem Schlüsselbund. Ein Benutzer muss dafür überhaupt nicht anwesend sein.

Bei delegierten Berechtigungen ist die Authentifizierung immer an einen Benutzer gebunden. Meldet sich jemand an, etwa bei einer App, die auf seine E-Mails oder seinen Kalender zugreifen muss, gewährt er der App ein zeitlich begrenztes Fenster, in dem sie mit seiner Autorität arbeiten kann. Meldet er sich ab, schließt sich dieses Fenster. Das eignet sich ideal für Apps, die auf Anfrage des Benutzers arbeiten, etwa Web-Frontends, Teams-Bots oder mobile Produktivitäts-Apps.

Bei Anwendungsberechtigungen authentifiziert sich die App als eigene Identität (ein Dienstprinzipal) und erhält ein eigenes Token. Damit laufen Automatisierungen und Hintergrundaufgaben, etwa eine Systemintegration, die nachts Daten zwischen SharePoint und Ihrem CRM synchronisiert. Eine Benutzerinteraktion ist nicht erforderlich: Die App führt Aufgaben nach eigenem Zeitplan und mit eigener Zugriffsebene aus, vorausgesetzt, ein Administrator hat diese genehmigt.

Stellen Sie sich vor, Sie müssen die Benutzerbereitstellung automatisieren: Ein Hintergrunddienst aktualisiert jede Nacht still Benutzerkonten. Hier sind delegierte Berechtigungen nutzlos, denn niemand ist da, der den Zugriff genehmigen könnte. Wenn Ihre Lösung jedoch personalisierte Funktionen anbieten soll, während der Benutzer aktiv ist, etwa eine Signier-App für Dokumente, die mit OneDrive verknüpft ist, zeigen delegierte Berechtigungen ihre Stärke.

Praxisszenarien erfordern oft eine Kombination. Deshalb ist es entscheidend zu wissen, welches Modell zu Ihrem Anwendungsfall passt, und zwar für Benutzerfreundlichkeit, Governance und Sicherheit. Sie wollen nicht mehr Schlüssel herausgeben als nötig, aber Sie wollen auch nicht, dass Ihr Dienst um 3 Uhr morgens ausgesperrt ist, weil niemand da ist, der sich anmeldet.

Delegierte Berechtigungen in Microsoft Entra ID im Detail: Authentifizierungsablauf und Einschränkungen

Delegierte Berechtigungen in Microsoft Entra ID folgen einem klassischen, benutzergesteuerten Authentifizierungsablauf. Er beginnt, wenn sich ein Benutzer mit seinen Microsoft-Anmeldeinformationen bei Ihrer Anwendung anmeldet. Zu diesem Zeitpunkt fordert die App bestimmte Berechtigungen bzw. Bereiche (Scopes) an und zeigt dem Benutzer (und manchmal auch einem Administrator) genau an, auf welche Arten von Daten oder Aktionen sie zugreifen möchte.

Wenn die angeforderten Berechtigungen nur die Zustimmung des Benutzers erfordern, bestätigt der Benutzer sie direkt über einen Zustimmungsdialog. Für sensiblere Berechtigungen (etwa das Lesen aller Postfächer einer Organisation) ist die Zustimmung eines Administrators erforderlich. Nach der Zustimmung erhält Ihre App ein Zugriffstoken, das unmittelbar an die Identität des Benutzers und die ihm zugewiesenen Rollen gebunden ist.

Mit diesem Zugriffstoken kann die App Microsoft Graph oder M365-APIs aufrufen, handelt dabei aber immer im Auftrag des Benutzers. Ist der Benutzer ein Standardmitarbeiter, kann die App also nicht plötzlich Administratorfunktionen nutzen. Sobald sich der Benutzer abmeldet, endet der Zugriff der App. So bleibt der mögliche Schaden begrenzt.

Die Einschränkung dabei: Delegierte Berechtigungen versagen in unbeaufsichtigten Szenarien. Wenn Sie einen Hintergrundprozess, einen Cron-Job oder eine Dienstintegration betreiben, die nicht von einer aktiven Anmeldung abhängen soll, reichen delegierte Berechtigungen nicht aus. Sie setzen immer die Anwesenheit eines Benutzers voraus. Damit stoßen Support, Automatisierung und nächtliche Jobs an eine Grenze.

Außerdem gibt es einen Sicherheitsaspekt. Lässt sich ein Benutzer mit weitreichenden Zugriffsrechten zu einer Zustimmung verleiten, könnte eine App diese Berechtigungen missbrauchen. Dies ist ein zentraler Angriffsweg bei Consent-Phishing. Deshalb sollten Sie genau steuern, wer welche Berechtigungen erteilen darf, und Ihre Benutzer gezielt darüber aufklären, was die Zustimmungsdialoge tatsächlich bedeuten.

Übermäßige Berechtigungen für App-Zugriffe und Tokensicherheit in Microsoft Entra ID

Bei Berechtigungen gilt: Mehr ist nicht immer besser. Übermäßige Berechtigungen, also das Vergeben unnötiger oder überzogener Rechte, vor allem bei Anwendungsberechtigungen, können sensible Datenlecks und schwerwiegende Sicherheitsvorfälle begünstigen. Angenommen, Sie gewähren einer App Lese- und Schreibzugriff auf alle Postfächer im Unternehmen, sie benötigt aber nur das Lesen von Kalenderereignissen. Dann haben Sie Ihre Angriffsfläche deutlich vergrößert.

Diese Gefahr ist nicht nur theoretisch. Angreifer missbrauchen OAuth-Zustimmungen, um selbst die Multi-Faktor-Authentifizierung zu umgehen. Sie sprechen Benutzer oder Administratoren mit raffiniert gestalteten Zustimmungsabfragen an und verleiten sie dazu, riskante Berechtigungen zu genehmigen. Einmal eingeschleust, behalten diese schadhaften Apps häufig ihren Zugriff, selbst wenn Passwörter geändert oder MFA erzwungen werden. Der Zugriff des Angreifers bleibt bestehen, und klassische Schutzmaßnahmen laufen ins Leere. Eine praxisnahe Erklärung finden Sie in diesem Beitrag: So missbrauchen Angreifer OAuth-Zustimmungen in Entra ID. Dort erfahren Sie auch, wie Sie sich wirksam schützen.

Das Thema beschränkt sich nicht auf übermäßige Berechtigungen. Auch Tokens und Anmeldeinformationen, darunter Clientgeheimnisse und Zertifikate, werden zum lohnenden Ziel für Angreifer, wenn sie nicht ausreichend geschützt sind. Ein kompromittiertes Clientgeheimnis einer reinen App-Registrierung genügt einem Angreifer, um Ihren Dienst zu imitieren. Deshalb ist eine saubere Verwaltung von Anmeldeinformationen unverzichtbar: Verwenden Sie nach Möglichkeit verwaltete Identitäten, rotieren Sie Geheimnisse regelmäßig und speichern Sie Client-Anmeldeinformationen niemals im Code oder in ungeschützten Dateien. Für Umgebungen mit nicht menschlichen Zugriffen sollten Sie Microsoft Entra Workload Identities in Betracht ziehen. Sie ermöglichen geheimnisloses, nachvollziehbares Zugriffsmanagement und beseitigen die Probleme klassischer Dienstkonten. Einen vertiefenden Einblick, warum Workload Identities für Zero Trust unverzichtbar sind, bietet dieser Beitrag.

Schließlich ist eine gute Überwachung unverzichtbar. Prüfen Sie Anmeldeprotokolle und OAuth-Berechtigungen regelmäßig, richten Sie Warnmeldungen für verdächtige Zustimmungen und Tokennutzung ein, und bleiben Sie Consent-Phishing und Tokendiebstahl einen Schritt voraus. Erkenntnisse aus realen Sicherheitsvorfällen, wie diese Microsoft-365-Angriffskette, zeigen, dass Angreifer schwache Governance ausnutzen. Je mehr Transparenz Sie haben, desto besser. Schützen Sie die Schlüssel, begrenzen Sie die Berechtigungen und halten Sie Ihre Apps unter Kontrolle.

Kontrollen und bewährte Methoden für die Verwaltung delegierter und anwendungsbezogener Berechtigungen

Integrierte Entra-Kontrollen für die Berechtigungsverwaltung einsetzenNutzen Sie die integrierten Einwilligungs-Workflows, Genehmigungsprozesse für Administratoren und granulare Richtlinien von Microsoft Entra, um festzulegen, welche Benutzer oder Gruppen Berechtigungen erteilen dürfen. Verwenden Sie Richtlinien für die Administratoreinwilligung, damit nur geprüfte Apps Bereiche mit hohem Risiko erhalten.
Das Prinzip der minimalen Berechtigungen durchsetzenErteilen Sie Apps nur die minimale Menge an Berechtigungen, die sie für ihre Funktion benötigen. Prüfen Sie jede Berechtigung, die bei der App-Registrierung angefordert wird, und entfernen Sie alles, was nicht notwendig ist. Das Prinzip der minimalen Berechtigungen ist Ihr wirksamster Schutz gegen Missbrauch und übermäßige Zugriffe.
Regelmäßige Überprüfungen und Audits der Berechtigungen planenRichten Sie routinemäßige Zugriffsüberprüfungen ein und nutzen Sie dafür die Berechtigungs- und Einwilligungsübersichten in Entra, um ungenutzte oder riskante Berechtigungen zu identifizieren und zu entziehen. Automatisieren Sie diese Prüfungen nach Möglichkeit, um Governance skalierbar umzusetzen, wie in fortgeschrittenen Governance-Leitfäden wie dieser Microsoft-Purview-Strategie beschrieben.
Änderungen an Berechtigungen überwachen und Warnmeldungen einrichtenRichten Sie Überwachung und Warnmeldungen ein, um neue OAuth-Berechtigungen, auffällige Anstiege bei der Nutzung von App-Berechtigungen oder unerwartete Administratorintegrationen zu erkennen. Proaktive Berichte geben Ihnen Zeit zu reagieren, bevor sich Sicherheitsvorfälle verschärfen.
Token und Anmeldeinformationen sicher speichernSpeichern Sie Clientgeheimnisse und Token in sicheren Tresoren wie Azure Key Vault. Rotieren Sie Anmeldeinformationen regelmäßig, verwenden Sie Zertifikate anstelle gemeinsam genutzter Geheimnisse und bevorzugen Sie Workload-Identitäten für nicht-menschliche Zugriffe, da sie ein besseres Lebenszyklusmanagement und bessere Nachvollziehbarkeit bieten.
Fortgeschrittene Governance und Richtlinienautomatisierung einführenSetzen Sie Werkzeuge wie Microsoft Purview und Azure Policy ein, um mandantenweite Kontrollen durchzusetzen, Risiken mit Data Loss Prevention einzugrenzen und auf kontinuierliche Compliance auszulegen. Einen praxisnahen Blick darauf, wie Sie Richtlinien für Governance by Design nutzen, bietet die Azure-Governance-Strategie für Unternehmen.

Wenn Sie diese Schritte befolgen und das Governance-Ökosystem von Microsoft nutzen, können Sie Ihre Organisation befähigen, Berechtigungsrisiken zu managen, bevor sie zu Problemen werden. Schulen Sie Benutzer regelmäßig im sicheren Umgang mit Einwilligungen, automatisieren Sie, wo immer möglich, und denken Sie daran: Berechtigungsmanagement ist nie abgeschlossen. Bleiben Sie wachsam, verfeinern Sie Ihre Richtlinien laufend, dann bleibt Ihre Entra-ID-Umgebung in gutem Zustand.

Das sollten Sie sich auch anhören

Wenn Sie sich mit delegierten vs. Anwendungsberechtigungen in Entra ID beschäftigen, liefern diese Folgen praktischen Kontext für die sichere Einführung von Microsoft 365, Datenschutz, Governance und das Management von KI-Risiken.

Microsoft Purview – Simply Explained — Erfahren Sie, wie Klassifizierung, Aufbewahrung, Compliance und Schutz in einem gemeinsamen Microsoft-Modell für Datengovernance zusammenspielen.
Microsoft Defender XDR – Simply Explained — Verbinden Sie Datenschutzkontrollen mit Erkennung, Untersuchung und Reaktion.
Conditional Access – Simply Explained — Verstehen Sie, wie Identitäts- und Risikosignale Zugriffsentscheidungen zusätzlichen Kontext geben.
Microsoft AI Agent Harness – Simply Explained — Entdecken Sie die Kontrollen, die KI-Automatisierung zuverlässiger, nachvollziehbarer und sicherer machen.

Diese Folgen helfen Ihnen, die Konzepte des Artikels in praktische Entwurfs- und Einführungsentscheidungen zu übersetzen.