Grundlegendes zum delegierten Zugriff
Wenn sich ein Benutzer bei einer Anwendung anmeldet und über diese auf eine andere Ressource, z. B. Microsoft Graph, zugreift, muss die Anwendung zunächst die Berechtigung für den Zugriff auf diese Ressource im Namen des Benutzers anfragen. Dieses gängige Szenario wird als delegierter Zugriff bezeichnet.
Gründe für delegierten Zugriff
Benutzer verwenden häufig verschiedene Anwendungen, um in Clouddiensten auf ihre Daten zuzugreifen. Beispielsweise kann jemand eine bevorzugte PDF-Reader-Anwendung verwenden möchten, um seine auf OneDrive gespeicherten Dateien anzuzeigen. Ein weiteres Beispiel ist die branchenspezifische Anwendung eines Unternehmens, die freigegebene Informationen über Kollegen abruft, sodass sie problemlos Prüfer für eine Anforderung auswählen können. In solchen Fällen muss die Clientanwendung, der PDF-Reader, oder das Tool des Unternehmens zur Genehmigung von Anforderungen autorisiert werden, im Auftrag des Benutzers, der sich bei der Anwendung angemeldet hat, auf diese Daten zuzugreifen.
Wählen Sie delegierten Zugriff, wenn Sie einen angemeldeten Benutzer mit seinen eigenen Ressourcen bzw. Ressourcen arbeiten lassen möchten, auf die er Zugriff hat. Unabhängig davon, ob ein Administrator Richtlinien für die gesamte Organisation einrichtet oder ein Benutzer eine E-Mail in seinem Posteingang löscht, sollte in allen Szenarien mit Benutzeraktionen auf delegierten Zugriff zurückgegriffen werden.
Im Gegensatz dazu ist delegierter Zugriff in der Regel eine schlechte Wahl bei Szenarien, die ohne einen angemeldeten Benutzer ablaufen müssen, wie z. B. Automatisierung. Er ist auch keine gute Wahl für Szenarien, bei denen der Zugriff auf Ressourcen vieler Benutzer erforderlich ist, wie z. B. Verhinderung von Datenverlust oder Sicherungen. Erwägen Sie den reinen Anwendungszugriff für diese Arten von Vorgängen.
Anfordern von Bereichen als Client-App
Ihre App muss den Benutzer bitten, für die Ressource, auf die Sie zugreifen möchten, einen bestimmten Bereich oder eine Reihe von Bereichen festzulegen. Bereiche können auch als delegierte Berechtigungen bezeichnet werden. Diese Bereiche beschreiben, welche Ressourcen und Vorgänge Ihre App im Auftrag des Benutzers ausführen möchte. Wenn Sie z. B. möchten, dass Ihre App dem Benutzer eine Liste der zuletzt empfangenen E-Mail- und Chatnachrichten anzeigt, können Sie den Benutzer bitten, seine Einwilligung in die Microsoft Graph-Bereiche Mail.Read und Chat.Read zu geben.
Nachdem Ihre App einen Bereich angefordert hat, muss ein Benutzer oder Administrator den angeforderten Zugriff gewähren. Private Benutzer mit Microsoft-Konten wie Outlook.com- oder Xbox Live-Konten können sich jederzeit selbst Bereiche gewähren. Organisationsbenutzer*innen mit Microsoft Entra-Konten können sich je nach Einstellungen ihrer Organisation ggf. Bereiche gewähren. Wenn ein Organisationsbenutzer nicht direkt in Bereiche einwilligen kann, muss er den Administrator seiner Organisation um seine Einwilligung bitten.
Befolgen Sie stets das Prinzip der geringsten Rechte: Fordern Sie auf keinen Fall Bereiche an, die Ihre App nicht benötigt. Dieses Prinzip trägt zur Eindämmung von Sicherheitsrisiken bei, sollte Ihre App kompromittiert werden, und erleichtert es Administratoren, Ihrer App Zugriff zu gewähren. Wenn Ihre App beispielsweise nur die Chats auflisten muss, an denen ein Benutzer teilnimmt, aber nicht die Chatnachrichten selbst anzeigen muss, sollten Sie den eingeschränkteren Microsoft Graph-Bereich Chat.ReadBasic anstelle von Chat.Read anfordern. Weitere Informationen zu Open ID Connect-Bereichen finden Sie unter Open ID Connect-Bereiche.
Entwerfen und Veröffentlichen von Bereichen für einen Ressourcendienst
Wenn Sie eine API erstellen und delegierten Zugriff im Auftrag von Benutzern erlauben möchten, müssen Sie Bereiche erstellen, die andere Apps anfordern können. In diesen Bereichen sollten die Aktionen oder Ressourcen beschrieben werden, die dem Client zur Verfügung stehen. Sie sollten beim Entwerfen Ihrer Bereiche Entwicklerszenarien berücksichtigen.
Token für sich selbst
Im Szenario, in dem Folgendes gilt:
- Die Ressourcenanwendung und die Clientanwendung sind identisch.
- Die Anwendung hat keine registrierte Web-API.
- Die Anwendung fordert ein Token für eine delegierte Berechtigung an, die sie selbst verfügbar macht.
Für diese Tokenanforderung wird keine Zustimmung benötigt oder angezeigt. Darüber hinaus kann für Apps, die in einem Mandanten erstellt werden und ein Token an sich selbst anfordern, davon ausgegangen werden, dass sie bereits Zugriff auf Profildaten haben und automatisch Profilzugriff erhalten.
Wie funktioniert delegierter Zugriff?
Das Wichtigste beim delegierten Zugriff ist, dass sowohl Ihre Client-App als auch der angemeldete Benutzer ordnungsgemäß autorisiert sein müssen. Das Gewähren eines Bereichs reicht nicht aus. Wenn entweder die Client-App nicht den richtigen Bereich hat oder der Benutzer nicht über ausreichende Rechte zum Lesen oder Ändern der Ressource verfügt, schlägt der Aufruf fehl.
- Autorisierung von Client-Apps: Client-Apps werden durch das Gewähren von Bereichen autorisiert. Wenn einer Client-App von einem*r Benutzer*in oder Administrator*in ein Zugriffsrecht für eine Ressource gewährt wird, wird diese Gewährung in Microsoft Entra ID aufgezeichnet. Alle delegierten Zugriffstoken, die vom Client angefordert werden, um im Auftrag des betreffenden Benutzers auf die Ressource zuzugreifen, enthalten dann die Anspruchswerte dieser Bereiche im Anspruch
scp. Die Ressourcen-App prüft diesen Anspruch, um festzustellen, ob der Client-App der richtige Bereich für den Aufruf gewährt wurde. - Benutzerautorisierung: Benutzer werden von der Ressource autorisiert, die Sie aufrufen. Ressourcen-Apps können zur Benutzerautorisierung ein oder mehrere Systeme verwenden, z. B. rollenbasierte Zugriffssteuerung, Besitz-/Mitgliedschaftsbeziehungen, Zugriffssteuerungslisten oder andere Überprüfungen. Microsoft Entra ID prüft beispielsweise, ob ein*e Benutzer*in einer App-Verwaltungsrolle oder allgemeinen Administratorrolle zugewiesen wurde, ehe er oder sie die Anwendungen einer Organisation löschen darf, erlaubt aber auch allen Benutzer*innen das Löschen von Anwendungen, die ihnen gehören. Gleichermaßen prüft der Dienst SharePoint Online, ob ein Benutzer über die entsprechenden Besitzer- oder Leserechte für eine Datei verfügt, ehe er sie öffnen darf.
Beispiel des delegierten Zugriffs: OneDrive über Microsoft Graph
Betrachten Sie das folgenden Beispiel:
Alice möchte mit einer Client-App eine Datei öffnen, die durch eine Ressourcen-API (Microsoft Graph) geschützt ist. Zur Benutzerautorisierung prüft der Dienst OneDrive, ob die Datei auf dem Laufwerk von Alice gespeichert ist. Wenn die Datei auf dem Laufwerk eines anderen Benutzers gespeichert ist, lehnt OneDrive die Anforderung von Alice als nicht autorisiert ab, da Alice nicht berechtigt ist, Laufwerke anderer Benutzer zu lesen.
Zur Autorisierung von Client-Apps prüft OneDrive, ob dem aufrufenden Client im Auftrag des angemeldeten Benutzers der Bereich Files.Read gewährt wurde. In diesem Fall ist Alice die angemeldete Benutzerin. Wenn für Alice Files.Read für die App nicht gewährt wurde, erfüllt OneDrive die Anforderung ebenfalls nicht.
| GET /drives/{id}/files/{id} | Client-App gewährt Alice den Bereich Files.Read |
Client-App gewährt Alice den Bereich Files.Read nicht |
|---|---|---|
| Das Dokument befindet sich in Alices OneDrive. | 200: Zugriff gewährt. | 403: Nicht autorisiert. Alice (oder ihr Administrator) hat diesem Client nicht erlaubt, ihre Dateien zu lesen. |
| Das Dokument befindet sich auf dem OneDrive* eines anderen Benutzers. | 403: Nicht autorisiert. Alice hat keine Leseberechtigungen für diese Datei. Auch wenn dem Client Files.Read gewährt wurde, sollte der Zugriff verweigert werden, wenn er im Auftrag von Alice handelt. |
403: Nicht autorisiert. Alice hat keine Leseberechtigung für diese Datei, und auch der Client darf keine Dateien lesen, auf die sie Zugriff hat. |
Dieses Beispiel wurde vereinfacht, um die delegierte Autorisierung zu veranschaulichen. Die Produktionsversion von OneDrive unterstützt viele andere Zugriffsszenarien, z. B. freigegebene Dateien.