Einführung in Berechtigungen und Einwilligung

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 ihren 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 Auftrag 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 Benutzer kann beispielsweise über die rollenbasierte Zugriffssteuerung (RBAC) von Azure Active Directory (Azure AD) 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.

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. Für den reinen App-Zugriff müssen der Client-App die entsprechenden App-Rollen der aufgerufenen Ressourcen-App zugewiesen werden, um auf die angeforderten Daten zugreifen zu können. 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.

Stellen Sie sich z. B. eine Anwendung vor, der die delegierte Berechtigung Files.Read.All im Auftrag von Tom, dem Benutzer, erteilt wurde. Die Anwendung kann nur Dateien lesen, auf die Tom persönlich zugreifen kann.

Anwendungsberechtigungen (auch als App-Rollen bezeichnet) 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. Eine Anwendung, der die Anwendungsberechtigung Files.Read.All erteilt wurde, kann beispielsweise jede Datei im Mandanten lesen. Nur ein Administrator oder Besitzer des Dienstprinzipals kann in Anwendungsberechtigungen einwilligen.

Es gibt noch weitere Möglichkeiten, Anwendungen die Berechtigung für reinem App-Zugriff zu erteilen. Beispielsweise kann einer Anwendung eine RBAC-Rolle in Azure AD zugewiesen werden.

Vergleich von delegierten und Anwendungsberechtigungen

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 jeder 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 stellt seine Anmeldeinformationen bereit. Diese Anmeldeinformationen werden überprüft, 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. In vielen Fällen muss möglicherweise ein Administrator 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.

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.

Nächste Schritte