Share via

Abrufen der Autorisierung für den Zugriff auf Ressourcen

  • Artikel

Dieser Artikel hilft Entwicklern, zu verstehen, wie Zero Trust beim Abrufen von Ressourcenzugriffsberechtigungen für Anwendungen am besten sichergestellt werden kann. Für den Zugriff auf geschützte Ressourcen 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. Ihre App erhält ein Zugriffstoken, wenn der Ressourcenbesitzer die Einwilligung erteilt. Ihre App erhält kein Zugriffstoken, wenn der Ressourcenbesitzer den Zugriff verweigert.

Konzeptionelle Überprüfung

Sie können die Microsoft Identity Platform zum Authentifizieren und zum Autorisieren Ihrer Anwendungen und zur Verwaltung Ihrer Berechtigungen und Zustimmungen verwenden. Beginnen wir mit einigen Konzepten:

  • Die Authentifizierung (manchmal abgekürzt als AuthN) ist der Prozess, mit dem Sie beweisen, dass Ihre beanspruchte Identität korrekt ist. Für die Microsoft Identity Platform wird das OpenID Connect-Protokoll für die Verarbeitung der Authentifizierungsvorgänge genutzt. Die Autorisierung (manchmal abgekürzt als AuthZ) gewährt einer authentifizierten Partei die Berechtigung, etwas zu tun. Sie gibt an, auf welche Daten die authentifizierte Partei zugreifen kann. Für die Microsoft Identity Platform wird das OAuth2.0-Autorisierungsprotokoll für die Verarbeitung der Autorisierungsvorgänge genutzt. Autorisierungsoptionen umfassen Zugriffssteuerungslisten (Access Control Lists, ACL), rollenbasierte Zugriffssteuerung und Attributzugriffssteuerung (ABAC). Die Authentifizierung ist häufig ein Faktor der Autorisierung.

  • Mit delegiertem Zugriff (im Auftrag eines angemeldeten Benutzers handeln) oder Direktzugriff (nur als eigene Identität der Anwendung handeln) kann Ihre Anwendung, auf Daten zugreifen. Delegierter Zugriff erfordert delegierte Berechtigungen (auch bezeichnet als Bereiche). Der Client und der Benutzer müssen separat autorisiert sein, um die Anforderung zu stellen. Direktzugriff erfordert möglicherweise Anwendungsberechtigungen (auch bekannt als App-Rollen). Wenn App-Rollen Anwendungen gewährt werden, können sie als Anwendungsberechtigungen bezeichnet werden.

  • Delegierte Berechtigungen, die mit delegiertem Zugriff verwendet werden, ermöglichen es einer Anwendung, im Namen eines Benutzers zu handeln und nur auf das zuzugreifen, worauf der Benutzer zugreifen kann. Anwendungsberechtigungen, die mit direktem Zugriff verwendet werden, ermöglichen einer Anwendung den Zugriff auf alle Daten, denen die Berechtigung zugeordnet ist. Nur Administratoren und Besitzer des Dienstprinzipals können in Anwendungsberechtigungen einwilligen.

  • Einwilligung ist die Art und Weise, in der Anwendungen Berechtigungen erhalten. Benutzer oder Administratoren autorisieren eine Anwendung für den Zugriff auf eine geschützte Ressource. Eine Zustimmungsaufforderung listet die Berechtigungen auf, die die Anwendung zusammen mit Herausgeberinformationen benötigt.

  • Vorabautorisierung ist die Art und Weise, in der Ressourcenanwendungsbesitzer Zugriff auf Client-Apps gewähren. Sie können dies im Azure-Portal oder mithilfe von PowerShell und APIs wie Microsoft Graph tun. Sie können Ressourcenberechtigungen erteilen, ohne dass Benutzern eine Einwilligungsaufforderung für den Satz von vorab autorisierten Berechtigungen angezeigt wird.

Der Unterschied zwischen delegierten Berechtigung und Anwendungsberechtigung

Anwendungen funktionieren in zwei Modi: wenn ein Benutzer vorhanden ist (delegierte Berechtigung) und wenn kein Benutzer vorhanden ist (Anwendungsberechtigung). Wenn sich ein Benutzer vor einer Anwendung befindet, sind Sie gezwungen, im Namen dieses Benutzers zu handeln. Sie sollten nicht im Namen der Anwendung handeln. Wenn ein Benutzer Ihre Anwendung leitet, fungieren Sie als Stellvertretung für diesen Benutzer. Sie erhalten die Berechtigung, im Namen des Benutzers zu handeln, der vom Token identifiziert wird.

Diensttypanwendungen (Hintergrundaufgaben, Daemons, Server-zu-Server-Prozesse) verfügen nicht über Benutzer, die sich selbst identifizieren oder ein Kennwort eingeben können. Sie benötigen eine Anwendungsberechtigung, um im Namen von sich selbst (im Auftrag der Dienstanwendung) zu handeln.

Bewährte Methoden für die Zero Trust-Anwendungsautorisierung

Ihr Autorisierungsansatz umfasst die Authentifizierung als Komponente, wenn Sie eine Verbindung mit einem Benutzer, der in der Anwendung vorhanden ist, und der Ressource herstellen, die Sie aufrufen. Wenn Ihre Anwendung im Namen eines Benutzers handelt, vertrauen wir einer aufrufenden Anwendung nicht, um uns mitzuteilen, wer der Benutzer ist oder wenn die Anwendung entscheiden kann, wer der Benutzer ist. Die Microsoft Entra ID überprüft den Benutzer und stellt im Token direkt Informationen über ihn bereit.

Wenn Sie Ihrer Anwendung erlauben müssen, eine API aufzurufen oder Ihre Anwendung zu autorisieren, damit die Anwendung auf eine Ressource zugreifen kann, können moderne Autorisierungsschemas eine Autorisierung über ein Berechtigungs- und Zustimmungsframework erfordern. Referenz Bewährte Sicherheitsmethoden für Anwendungseigenschaften , die Umleitungs-URI, Zugriffstoken (verwendet für implizite Abläufe), Zertifikate und geheime Schlüssel, Anwendungs-ID-URI und Anwendungsbesitz enthalten.

Nächste Schritte