Einwilligungserfahrung für Anwendungen in Azure Active Directory

In diesem Artikel erfahren Sie mehr über die Einwilligungserfahrung für Azure Active Directory-Anwendungen (Azure AD). Sie können dann auf intelligente Weise Anwendungen für Ihre Organisation verwalten und/oder Anwendungen mit einer nahtloseren Einwilligungserfahrung entwickeln.

Einwilligung ist der Prozess, mit dem ein Benutzer einer Anwendung die Autorisierung für den Zugriff auf geschützte Ressourcen in seinem Auftrag gewährt. Ein Administrator oder Benutzer kann zur Einwilligung aufgefordert werden, um den Zugriff auf seine Organisations-/individuellen Daten zuzulassen.

Die tatsächliche Benutzererfahrung des Erteilens der Einwilligung variiert in Abhängigkeit von den auf dem Mandanten des Benutzers festgelegten Richtlinien, dem Gültigkeitsbereich der Autorität (oder Rolle) des Benutzers und dem Typ der Berechtigungen, die von der Clientanwendung angefordert werden. Dies bedeutet, dass Anwendungsentwickler und Mandantenadministratoren eine gewisse Kontrolle über die Einwilligungserfahrung haben. Administratoren besitzen die Flexibilität, Richtlinien für einen Mandanten oder eine App festzulegen oder zu deaktivieren, um die Einwilligungserfahrung in ihrem Mandanten zu kontrollieren. Anwendungsentwickler können vorgeben, welche Typen von Berechtigungen angefordert werden, und ob sie Benutzer durch den Benutzereinwilligungsflow bzw. den Administratoreinwilligungsflow führen möchten.

  • Benutzereinwilligungsflow ist, wenn ein Anwendungsentwickler Benutzer mit der Absicht zum Autorisierungsendpunkt weiterleitet, die Einwilligung nur für den aktuellen Benutzer aufzuzeichnen.
  • Administratoreinwilligungsflow ist, wenn ein Anwendungsentwickler Benutzer mit der Absicht zum Administratoreinwilligungs-Endpunkt weiterleitet, die Einwilligung für den gesamten Mandanten aufzuzeichnen. Um sicherzustellen, dass der Administratoreinwilligungsflow ordnungsgemäß funktioniert, müssen Anwendungsentwickler alle Berechtigungen in der Eigenschaft RequiredResourceAccess im Anwendungsmanifest auflisten. Weitere Informationen finden Sie unter Anwendungsmanifest.

Die Einwilligungsaufforderung ist darauf ausgelegt, sicherzustellen, dass Benutzer über ausreichende Informationen verfügen, um zu bestimmen, ob sie der Clientanwendung so vertrauen, dass sie auf geschützte Ressourcen in ihrem Namen zugreifen darf. Das Verständnis der Bausteine hilft Benutzern, die Ihre Einwilligung geben, fundiertere Entscheidungen zu treffen, und hilft Entwicklern, bessere Benutzererfahrungen zu erstellen.

Das Diagramm und die Tabelle im Folgenden bieten Informationen über die Bausteine der Einwilligungsaufforderung.

Bausteine der Einwilligungsaufforderung

# Komponente Zweck
1 Benutzer-ID Dieser Bezeichner stellt den Benutzer dar, von dem die Clientanwendung den Zugriff auf geschützte Ressourcen in seinem Auftrag anfordert.
2 Titel Der Titel ändert sich basierend darauf, ob die Benutzer den Benutzer- oder Administratoreinwilligungsflow durchlaufen. Im Benutzereinwilligungsflow lautet der Titel „Berechtigungen“, während er im Administratoreinwilligungsflow eine zusätzliche Zeile namens „Für Ihre Organisation zustimmen“ besitzt.
3 App-Logo Dieses Bild sollte Benutzern einen visuellen Hinweis geben, ob diese App die App ist, auf die sie zugreifen wollten. Dieses Bild wird von den Anwendungsentwicklern bereitgestellt, und der Besitz für dieses Bild wird nicht überprüft.
4 App-Name Dieser Wert sollte Benutzer darüber informieren, welche Anwendung Zugriff auf ihre Daten anfordert. Beachten Sie, dass dieser Name von den Entwicklern bereitgestellt wird, und dass der Besitz an diesem App-Namen nicht überprüft wird.
5 Herausgebername und Überprüfung Der blaue Badge „verifiziert“ bedeutet, dass der App-Herausgeber seine Identität mithilfe eines Microsoft Partner Network-Kontos bestätigt und den Verifizierungsprozess abgeschlossen hat. Wenn die App durch den Herausgeber verifiziert wurde, wird der Herausgebername angezeigt. Wenn die App nicht durch den Herausgeber verifiziert wurde, wird anstelle eines Herausgebernamens „Nicht verifiziert“ angezeigt. Weitere Informationen finden Sie unter Herausgeberüberprüfung. Wenn Sie den Herausgebernamen auswählen, werden weitere App-Informationen angezeigt, etwa der Herausgebername, die Herausgeberdomäne, das Erstellungsdatum, Zertifizierungsdetails und Antwort-URLs.
6 Microsoft 365-Zertifizierung Das Microsoft 365-Zertifizierungslogo bedeutet, dass eine App anhand von Kontrollen überprüft wurde, die von führenden branchenüblichen Standardframeworks abgeleitet wurden, und dass strenge Sicherheits- und Complianceverfahren zum Schutz von Kundendaten vorhanden sind. Weitere Informationen finden Sie unter Worum handelt es sich bei der Microsoft 365-Zertifizierung?.
7 Informationen zum Herausgeber Zeigt an, ob die Anwendung von Microsoft veröffentlicht wird.
8 Berechtigungen Diese Liste enthält die Berechtigungen, die von der Clientanwendung angefordert werden. Benutzer sollten die Typen der angeforderten Berechtigungen immer bewerten, um zu verstehen, auf welche Daten der Zugriff der Clientanwendung in ihrem Namen autorisiert wird, wenn sie zustimmen. Als Anwendungsentwickler ist es am besten, den Zugriff auf die Berechtigungen mit den geringsten Rechten anzufordern.
9 Berechtigungsbeschreibung Dieser Wert wird vom Dienst bereitgestellt, der die Berechtigungen verfügbar macht. Um die Berechtigungsbeschreibung anzuzeigen, müssen Sie das Chevron neben den Berechtigungen umschalten.
10 https://myapps.microsoft.com Dies ist der Link, unter dem Benutzer alle Nicht-Microsoft-Anwendungen überprüfen und entfernen können, die zurzeit Zugriff auf ihre Daten haben.
11 Hier melden Dieser Link dient zum Melden einer verdächtigen App, wenn Sie der App nicht vertrauen, wenn Sie glauben, dass die App die Identität einer anderen App annimmt oder Ihre Daten missbraucht, oder aus einem anderen Grund.

Im folgenden Abschnitt werden die gängigen Szenarien und die erwartete Einwilligungserfahrung dafür beschrieben.

App erfordert eine Berechtigung, die der Benutzer erteilen kann

In diesem Einwilligungsszenario greift der Benutzer auf eine App zu, für die eine Berechtigung festgelegt werden muss, die im Autoritätsbereichs des Benutzers liegt. Der Benutzer wird an den Benutzerzustimmungsflow weitergeleitet.

Administratoren wird in der herkömmlichen Einwilligungsaufforderung ein zusätzliches Steuerelement angezeigt, das ihnen gestattet, die Einwilligung im Auftrag des gesamten Mandanten zu geben. Das Steuerelement ist standardmäßig deaktiviert, weshalb auch nur, wenn Administratoren das Kontrollkästchen ausdrücklich aktivieren, die Einwilligung im Auftrag des gesamten Mandanten erklärt wird. Dieses Kontrollkästchen wird nur für die Rolle „Globaler Administrator“ angezeigt, sodass es den Rollen „Cloudadministrator“ und „App-Administrator“ nicht angezeigt wird.

Einwilligungsaufforderung für Szenario 1a

Benutzern wird die herkömmliche Einwilligungsaufforderung angezeigt.

Screenshot der herkömmlichen Einwilligungsaufforderung.

Die App erfordert eine Berechtigung, die der Benutzer nicht erteilen kann

In diesem Einwilligungsszenario greift der Benutzer auf eine App zu, die mindestens eine Berechtigung erfordert, die außerhalb des Autoritätsbereichs des Benutzers liegt.

Administratoren wird in der herkömmlichen Einwilligungsaufforderung ein zusätzliches Steuerelement angezeigt, das es ihnen gestattet, die Einwilligung im Auftrag des gesamten Mandanten zu geben.

Einwilligungsaufforderung für Szenario 1a

Benutzer, die keine Administratoren sind, werden am Erteilen ihrer Einwilligung für die Anwendung gehindert und darauf hingewiesen, ihren Administrator um Zugriff auf die App zu bitten. Wenn der Workflow für die Administratoreinwilligung im Mandanten des Benutzers aktiviert ist, können Benutzer, die keine Administratoren sind, über die Einwilligungsaufforderung eine Anforderung für die Administratorgenehmigung senden. Weitere Informationen zum Workflow für die Administratoreinwilligung finden Sie unter Workflow für die Administratoreinwilligung.

Screenshot der Einwilligungsaufforderung, die den Benutzer auffordert, einen Administrator um Zugriff auf die App zu bitten.

In diesem Einwilligungsszenario navigiert der Benutzer zum Flow für die Administratoreinwilligung oder wird dorthin geleitet.

Administratorbenutzern wird die Administratoreinwilligungsaufforderung angezeigt. Der Titel und die Beschreibung der Berechtigungen hat sich in dieser Eingabeaufforderung geändert, und die Änderungen unterstreichen die Tatsache, dass das Annehmen dieser Aufforderung der App Zugriff auf die angeforderten Daten im Auftrag des gesamten Mandanten erteilt.

Einwilligungsaufforderung für Szenario 3a

Benutzer, die keine Administratoren sind, werden am Erteilen ihrer Einwilligung für die Anwendung gehindert und darauf hingewiesen, ihren Administrator um Zugriff auf die App zu bitten.

Screenshot der Einwilligungsaufforderung, die den Benutzer auffordert, einen Administrator um Zugriff auf die App zu bitten.

In diesem Szenario willigt ein Administrator in alle Berechtigungen ein, die eine Anwendung anfordert. Dazu können auch delegierte Berechtigungen im Namen aller Benutzer im Mandanten gehören. Der Administrator erteilt die Einwilligung über die Seite API-Berechtigungen der Anwendungsregistrierung im Azure-Portal.

Screenshot der expliziten Administratoreinwilligung über das Azure-Portal.

Alle Benutzer in diesem Mandanten sehen das Dialogfeld für die Einwilligung nur, wenn die Anwendung neue Berechtigungen erfordert. Um zu erfahren, welche Administratorrollen delegierten Berechtigungen zustimmen können, lesen Sie Berechtigungen der Administratorrolle in Azure AD.

Wichtig

Das explizite Gewähren der Zustimmung über die Schaltfläche Berechtigungen erteilen ist derzeit für Single-Page-Webanwendungen (Single-Page Applications, SPAs) erforderlich, die „MSAL.js“ nutzen. Andernfalls tritt für die Anwendung ein Fehler auf, wenn das Zugriffstoken angefordert wird.

Häufige Probleme

In diesem Abschnitt werden die häufigen Probleme mit der Einwilligungserfahrung und mögliche Tipps zur Problembehandlung beschrieben.

  • 403 Fehler

    • Handelt es sich um ein Szenario mit Delegierung? Welche Berechtigungen hat ein Benutzer?
    • Wurden für die Nutzung des Endpunkts erforderliche Berechtigungen hinzugefügt?
    • Prüfen Sie, ob das Token die notwendigen Ansprüche hat, um den Endpunkt aufzurufen.
    • Welchen Berechtigungen wurde zugestimmt? Wer hat eingewilligt?
  • Benutzer kann nicht einwilligen

    • Prüfen Sie, ob der Administrator des Mandanten die Einwilligung des Benutzers für Ihr Unternehmen deaktiviert hat.
    • Vergewissern Sie sich, ob es sich bei den von Ihnen angeforderten Berechtigungen um auf Administratoren beschränkte Berechtigungen handelt.
  • Benutzer ist auch nach der Einwilligung des Administrators noch blockiert

    • Prüfen Sie, ob statische Berechtigungen so konfiguriert sind, dass sie eine Obermenge der dynamisch angeforderten Berechtigungen sind.
    • Überprüfen Sie, ob eine Benutzerzuweisung für die App erforderlich ist.

Problembehandlung bei bekannten Fehlern

Problembehandlungsschritte finden Sie unter Unerwarteter Fehler beim Vorgang des Genehmigens einer Anwendung.

Nächste Schritte