Freigeben über

Erwerben der Autorisierung für den Zugriff auf Ressourcen

Dieser Artikel hilft Ihnen als Entwickler, zu verstehen, wie Sie beim Abrufen von Ressourcenzugriffsberechtigungen für Ihre Anwendung am besten Zero Trust sicherstellen können. Um auf geschützte Ressourcen wie E-Mail- oder Kalenderdaten zuzugreifen, benötigt Ihre Anwendung die Autorisierung des Ressourcenbesitzers. Der Ressourcenbesitzer kann der Anforderung Ihrer App zustimmen oder ablehnen. Ihre App erhält ein Zugriffstoken, wenn der Ressourcenbesitzer die Zustimmung erteilt; Ihre App empfängt kein Zugriffstoken, wenn der Ressourcenbesitzer den Zugriff verweigert.

Konzeptionelle Überprüfung

Sie können die Microsoft Identity Platform verwenden, um Ihre Anwendungen zu authentifizieren und zu autorisieren und Berechtigungen und Zustimmungen zu verwalten. Beginnen wir mit einigen Konzepten:

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

  • Delegierter Zugriff (im Auftrag eines angemeldeten Benutzers) oder direkter Zugriff (nur als eigene Identität der Anwendung) ermöglicht Ihrer Anwendung den Zugriff auf Daten. Delegierter Zugriff erfordert delegierte Berechtigungen (auch als Bereiche bezeichnet). Der Client und der Benutzer müssen separat autorisiert sein, um die Anforderung zu stellen. Für den direkten Zugriff sind möglicherweise Anwendungsberechtigungen erforderlich (auch als App-Rollen bezeichnet). Wenn Anwendungen App-Rollen empfangen, 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, was 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 der Dienstprinzipale können Berechtigungen für Anwendungen zustimmen.

  • Die Zustimmung 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.

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

Unterschied zwischen Delegierten-Berechtigung und Anwendungsberechtigung

Anwendungen funktionieren in zwei Modi: wenn ein Benutzer vorhanden ist (delegierte Berechtigung) und wenn kein Benutzer (Anwendungsberechtigung) vorhanden ist. Wenn sich ein Benutzer vor einer Anwendung befindet, sind Sie gezwungen, im Namen dieses Benutzers zu handeln. Sie sollten nicht im Namen der Anwendung selbst 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 verfügt über die Authentifizierung als Komponente, wenn Sie eine Verbindung mit einem Benutzer herstellen, der mit der Anwendung und mit der Ressource verbunden ist, 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 die Anwendung entscheiden kann, wer der Benutzer ist. Die Microsoft Entra-ID überprüft und stellt direkt Informationen über den Benutzer im Token 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. Verweisen auf Sicherheitsbestepraktiken für Anwendungseigenschaften, die Umleitungs-URI, Zugriffstoken (verwendet für implizite Abläufe), Zertifikate und geheime Schlüssel, Anwendungs-ID-URI und Anwendungsbesitz umfassen.

Nächste Schritte

  • Last updated on