Freigeben über

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

In der Microsoft Identity Platform ist das Verständnis von Berechtigungen und Zustimmung für die Entwicklung sicherer Anwendungen von entscheidender Bedeutung, die Zugriff auf geschützte Ressourcen erfordern. Dieser Artikel enthält eine Übersicht über die grundlegenden Konzepte und Szenarien im Zusammenhang mit Berechtigungen und Zustimmungen, die Anwendungsentwicklern dabei helfen, die erforderlichen Berechtigungen von Benutzern und Administratoren anzufordern. Durch das Verständnis dieser Konzepte können Sie sicherstellen, dass Ihre Anwendungen nur den benötigten Zugriff anfordern, Vertrauen und Sicherheit fördern.

Um auf eine geschützte Ressource wie E-Mail- oder Kalenderdaten zuzugreifen, benötigt Ihre Anwendung die Autorisierung des Ressourcenbesitzers. Der Ressourcenbesitzer kann der Anforderung Ihrer App zustimmen oder ablehnen. Wenn Sie diese grundlegenden Konzepte verstehen, können Sie sicherere und vertrauenswürdigere Anwendungen erstellen, die nur den benötigten Zugriff anfordern, wenn sie sie benötigen, von Benutzern und Administratoren.

Zugriffsszenarien

Als Anwendungsentwickler müssen Sie ermitteln, wie Ihre Anwendung auf Daten zugreift. 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 basiert die Autorisierung auf den Berechtigungen, denen der Benutzer für den Zugriff auf die Ressource gewährt wird. 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 " Nur-App-Zugriff" finden Sie unter "Nur-App-Zugriff".

Für den reinen App-Zugriff werden App-Rollen anstelle delegierter Bereiche verwendet. Wenn die Zustimmung erteilt wird, werden App-Rollen möglicherweise auch als Anwendungsberechtigungen bezeichnet. 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 kann nicht auf etwas zugreifen, auf das der angemeldete Benutzer nicht zugreifen konnte.

Nehmen Sie zum Beispiel eine Anwendung, der im Namen des Benutzers die Files.Read.All delegierte Berechtigung erteilt wird. 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, denen die Berechtigung zugeordnet ist.

Beispielsweise kann eine Anwendung, der die Anwendungsberechtigung Files.Read.All der Microsoft-Graph-API erteilt wurde, jede Datei im Mandanten mithilfe von Microsoft Graph 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: Anfordern einzelner Berechtigungen bei der Anmeldung		 – 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. Andere Szenarien, in denen Benutzern möglicherweise eine Zustimmungsaufforderung angezeigt wird, sind:

  • 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 zur Zustimmungsaufforderung und zur Zustimmungserfahrung für Administratoren und Endbenutzer finden Sie unter Anwendungszustimmung.

Die Einwilligung des Benutzers erfolgt, wenn ein Benutzer versucht, sich bei einer Anwendung anzumelden. Der Benutzer stellt seine Anmeldeinformationen bereit, die überprüft werden, um festzustellen, ob die Zustimmung 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. Möglicherweise muss ein Administrator die Zustimmung im Namen 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 Vorautorisierung ermöglicht es einem Ressourcenanwendungsbesitzer, Berechtigungen zu erteilen, ohne dass Benutzern eine Zustimmungsaufforderung für denselben Satz von Berechtigungen angezeigt wird, die vorautorisiert sind. Auf diese Weise fordert eine vorautorisierte Anwendung Benutzer nicht auf, Berechtigungen zuzustimmen. Ressourcenbesitzer können Client-Apps im Azure-Portal vorab autorisieren oder PowerShell und APIs wie Microsoft Graph verwenden.

In den meisten Fällen erfordern Kundenanwendungen in der externen Microsoft Entra-ID eine Vorautorisierung, da sie für Benutzer vorgesehen sind, die nicht Teil der Organisation sind und nicht in der Lage sein würden, den von der Anwendung angeforderten Berechtigungen zuzustimmen. Vorautorisierung stellt sicher, dass diese Benutzer auf die Anwendung zugreifen können, ohne zur Zustimmung aufgefordert zu werden.

Andere Autorisierungssysteme

Das Einwilligungs-Framework 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 Microsoft Entra-Rollen, Azure RBAC, Exchange RBAC und microsoft Teams-ressourcenspezifische Zustimmung.

Weitere Informationen