Teilen über

Übersicht über Berechtigungen und Einwilligung auf der Microsoft Identity Platform

  • Artikel

Für den Zugriff auf eine geschützte Ressource wie E-Mail- oder Kalenderdaten benötigt Ihre Anwendung die Autorisierung des Ressourcenbesitzers. Der Ressourcenbesitzer kann in die Anforderung Ihrer App einwilligen oder sie ablehnen. Das Verständnis dieser grundlegenden Konzepte hilft Ihnen dabei, sicherere und vertrauenswürdigere Anwendungen zu schaffen, die von Benutzern und Administratoren nur den jeweils erforderlichen Zugriff verlangen.

Zugriffsszenarien

Als Anwendungsentwickler müssen Sie herausfinden, wie Ihre Anwendung auf Daten zugreifen wird. Die Anwendung kann einen delegierten Zugriff vorsehen, bei dem sie im Auftrag eines angemeldeten Benutzers agiert, oder einen reinen App-Zugriff, bei dem sie nur als die eigene Identität der Anwendung agiert.

Abbildung der Zugriffsszenarien.

Delegierter Zugriff (Zugriff im Auftrag eines Benutzers)

In diesem Zugriffsszenario hat sich ein Benutzer bei einer Clientanwendung angemeldet. Die Clientanwendung greift im Auftrag des Benutzers auf die Ressource zu. Ein delegierter Zugriff erfordert delegierte Berechtigungen. Sowohl Client als auch Benutzer müssen getrennt voneinander autorisiert werden, um die Anforderung zu stellen. Weitere Informationen zum Szenario mit delegiertem Zugriff finden Sie unter Szenario mit delegiertem Zugriff.

Der Client-App müssen die richtigen delegierten Berechtigungen gewährt werden. Delegierte Berechtigungen können auch als Bereiche bezeichnet werden. Bereiche sind Berechtigungen für eine bestimmte Ressource, die angeben, worauf eine Clientanwendung im Namen des Benutzers zugreifen kann. Weitere Informationen zu Bereichen finden Sie unter Bereiche und Berechtigungen.

Für den Benutzer hängt die Autorisierung von den Berechtigungen ab, die ihm für den Zugriff auf die Ressource erteilt wurden. Der/die Benutzer*in kann beispielsweise über die rollenbasierte Zugriffssteuerung (RBAC) von Microsoft Entra für den Zugriff auf Verzeichnisressourcen oder über RBAC für Exchange Online für den Zugriff auf E-Mail- und Kalenderressourcen berechtigt sein. Weitere Informationen zu RBAC für Anwendungen finden Sie unter RBAC für Anwendungen.

Reiner App-Zugriff (Zugriff ohne Benutzer)

In diesem Zugriffsszenario agiert die Anwendung allein, ohne dass sich ein Benutzer anmeldet. Dieser Anwendungszugriff kommt in Szenarien wie Automatisierung und Datensicherung zum Einsatz. Zu diesem Szenario gehören Apps, die als Hintergrunddienste oder Daemons ausgeführt werden. Es eignet sich, wenn sich ein bestimmter Benutzer nicht anmelden soll oder die benötigten Daten nicht auf einen einzelnen Benutzer begrenzt werden können. Weitere Informationen zum Szenario des reinen App-Zugriffs finden Sie unter Reiner App-Zugriff.

Für den reinen App-Zugriff werden App-Rollen anstelle delegierter Bereiche verwendet. Falls durch Einwilligung erteilt, können App-Rollen auch als Anwendungsberechtigungen bezeichnet werden. Der Client-App müssen die entsprechenden Anwendungsberechtigungen der aufgerufenen Ressourcen-App erteilt werden. Sobald diese gewährt wurden, kann die Client-App auf die angeforderten Daten zugreifen. Weitere Informationen zum Zuweisen von App-Rollen zu Clientanwendungen finden Sie unter Zuweisen von App-Rollen zu Anwendungen.

Arten von Berechtigungen

Delegierte Berechtigungen kommen im Szenario mit delegiertem Zugriff zum Einsatz. Es handelt sich um Berechtigungen, die es der Anwendung erlauben, im Auftrag eines Benutzers zu handeln. Die Anwendung hat keinerlei Zugriff auf etwas, auf das der angemeldete Benutzer nicht selbst zugreifen kann.

Nehmen Sie als Beispiel eine Anwendung, der die delegierte Berechtigung Files.Read.All im Auftrag des Benutzers erteilt wurde. Die Anwendung kann nur Dateien lesen, auf die der Benutzer persönlich zugreifen kann.

Anwendungsberechtigungen (auch als App-Rollen bekannt) kommen im Szenario mit reinem App-Zugriff zum Einsatz, ohne dass ein angemeldeter Benutzer beteiligt ist. Die Anwendung kann auf alle Daten zugreifen, für die die Berechtigung gilt.

Beispielsweise kann eine Anwendung, der die Microsoft Graph-API-Anwendungsberechtigung Files.Read.All erteilt wurde, mithilfe von Microsoft Graph jede Datei im Mandanten lesen. Im Allgemeinen kann nur ein Administrator oder Besitzer eines API-Dienstprinzipals in von dieser API verfügbar gemachte Anwendungsberechtigungen einwilligen.

Vergleich von delegierten und Anwendungsberechtigungen

Berechtigungstypen Delegierte Berechtigungen Anwendungsberechtigungen
App-Typen Web/Mobil/Single-Page-App (SPA) Web/Daemon
Zugriffskontext Zugreifen im Namen von Benutzer*innen Ohne Benutzer zugreifen
Zum Einwilligen berechtigte Personen – Benutzer können für ihre Daten einwilligen
– Administratoren können für alle Benutzer einwilligen		 Nur der Administrator kann einwilligen
Einwilligungsmethoden – Statisch: Konfigurierte Liste bei der App-Registrierung
– Dynamisch: Individuelle Berechtigungen bei der Anmeldung anfordern		 – NUR statisch: Konfigurierte Liste bei der App-Registrierung
Andere Namen – Bereiche
– OAuth2-Berechtigungsbereiche		 – App-Rollen
– Reine App-Berechtigungen
Ergebnis der Einwilligung (spezifisch für Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Eine Möglichkeit, Anwendungen Berechtigungen zu erteilen, ist mittels Einwilligung. Einwilligung ist ein Vorgang, bei dem Benutzer oder Administratoren eine Anwendung für den Zugriff auf eine geschützte Ressource autorisieren. Wenn ein Benutzer z. B. erstmalig versucht, sich bei einer Anwendung anzumelden, kann die Anwendung die Berechtigung anfordern, das Profil des Benutzers einzusehen und den Inhalt seines Postfachs zu lesen. Der Benutzer sieht die Liste der Berechtigungen, die die App über eine Einwilligungsaufforderung anfordert. Es folgen weitere Szenarien, in denen Benutzern ggf. eine Einwilligungsaufforderung angezeigt wird:

  • Wenn eine zuvor erteilte Einwilligung widerrufen wird
  • Wenn die Anwendung so programmiert ist, dass sie bei der Anmeldung ausdrücklich zur Einwilligung auffordert.
  • Wenn die Anwendung die dynamische Einwilligung verwendet, um zur Laufzeit nach Bedarf neue Berechtigungen anzufordern

Die wichtigsten Details einer Einwilligungsaufforderung sind die Liste der Berechtigungen, die die Anwendung benötigt, und die Informationen zum Herausgeber. Weitere Informationen über die Einwilligungsaufforderung und -umgebung für Administratoren und Benutzer finden Sie unter Umgebung für die Anwendungseinwilligung.

Die Einwilligung des Benutzers erfolgt, wenn ein Benutzer versucht, sich bei einer Anwendung anzumelden. Der Benutzer gibt ihre Anmeldeinformationen an, die überprüft werden, um festzustellen, ob die Einwilligung bereits erteilt wurde. Wenn keine vorherige Einwilligung des Benutzers oder Administrators für die erforderlichen Berechtigungen vorliegt, wird der Benutzer aufgefordert, der Anwendung die erforderlichen Berechtigungen zu erteilen. Ein Administrator muss möglicherweise die Einwilligung im Auftrag des Benutzers erteilen.

Abhängig von den benötigten Berechtigungen kann es bei einigen Anwendungen erforderlich sein, dass ein Administrator die Zustimmung erteilt. So kann beispielsweise nur ein Administrator in Anwendungsberechtigungen und viele delegierte Berechtigungen mit hohen Rechten einwilligen.

Administratoren können die Einwilligung für sich persönlich oder die gesamte Organisation erteilen. Weitere Informationen zur Benutzer- und Administratoreinwilligung finden Sie unter Übersicht über die Benutzer- und Administratoreinwilligung.

Authentifizierungsanforderungen werden zur Administratoreinwilligung aufgefordert, wenn die Zustimmung nicht erteilt wurde und eine dieser hochprivilegierten Berechtigungen angefordert wird.

Berechtigungsanforderungen, die benutzerdefinierte Anwendungsbereiche enthalten, werden nicht als hochprivilegiert betrachtet und erfordern daher keine Administratoreinwilligung.

Vorauthentifizierung

Die Vorabautorisierung ermöglicht es einem Ressourcenbesitzer, Anwendungsberechtigungen zu erteilen, ohne dass Benutzern eine Einwilligungsaufforderung für den Berechtigungssatz angezeigt werden muss, dem die Vorabautorisierung erteilt wurde. Auf diese Weise wird eine Anwendung, die vorab autorisiert wurde, den Benutzer nicht um eine Einwilligung in Berechtigungen bitten. Ressourcenbesitzer können Client-Apps im Azure-Portal oder mithilfe von PowerShell und APIs wie Microsoft Graph vorab autorisieren.

Andere Autorisierungssysteme

Das Zustimmungsframework ist nur eine Möglichkeit zur Autorisierung einer Anwendung oder eines Benutzers für den Zugriff auf geschützte Ressourcen. Administratoren sollten andere Autorisierungssysteme kennen, die möglicherweise Zugriff auf vertrauliche Informationen gewähren. Beispiele für verschiedene Autorisierungssysteme bei Microsoft sind integrierte Entra-Rollen, Azure RBAC, Exchange RBAC und ressourcenspezifische Zustimmung in Teams.

Weitere Informationen