Grundlegendes zu API-Autorisierung und Tokenzwischenspeicherung

Abgeschlossen

Das Design des Unternehmensportals umfasst das Lesen des Profils des angemeldeten Benutzers aus Microsoft Graph. Die Authentifizierung identifiziert den Benutzer im Portal, aber ein API-Aufruf benötigt auch ein Zugriffstoken mit entsprechenden Berechtigungen.

Diese Einheit erklärt Berechtigungstypen, Gültigkeitsbereiche und ein beispielhaftes Muster für den MSAL4J-Tokencache. Es wird nicht davon ausgegangen, dass eine Anwendung oder angemeldete Sitzung ausgeführt wird.

API-Berechtigungen und -Bereiche

Eine geschützte API definiert Berechtigungen für ihre Funktionen und Daten. Microsoft Graph verfügt beispielsweise über unterschiedliche Berechtigungen zum Lesen eines Profils, Lesen eines Kalenders und Senden von E-Mails. Eine Anwendung fordert nur die Berechtigungen an, die für den vorgesehenen Vorgang erforderlich sind.

Microsoft Entra ID unterstützt zwei Berechtigungstypen:

Berechtigungstyp Kontext Einwilligung
Delegierte Berechtigungen Die Anwendung fungiert im Namen eines angemeldeten Benutzers. Der Zugriff wird durch die gewährten Berechtigungen und den Zugriff des Benutzers eingeschränkt. Ein Benutzer oder ein autorisierter Administrator kann je nach Berechtigungs- und Mandantenrichtlinie eine Einwilligung erteilen.
Anwendungsberechtigungen Die Anwendung fungiert als sich selbst ohne angemeldeten Benutzer, z. B. als Hintergrunddienst. Die Zustimmung des Administrators ist erforderlich.

Das Portal verwendet delegierte BerechtigungenUser.Read, um das Profil des angemeldeten Benutzers zu lesen. Diese Berechtigung gewährt keinen Zugriff auf die Daten jedes Benutzers oder nicht verwandte Ressourcen wie Kalender.

Bereiche beschreiben den angeforderten Zugriff

In einer delegierten Autorisierungsanforderung ausdrücken OAuth 2.0-Bereiche die Berechtigungen, die die Anwendung anfordert. Ein Bereich kann sowohl die Ressource als auch die Berechtigung identifizieren; Fordert beispielsweise https://graph.microsoft.com/Calendars.Read die Kalenderleseberechtigung für Microsoft Graph an.

In den Beispielen wird der einzelne Bereich User.Readverwendet. Für Microsoft Graph-Berechtigungsbereiche kann der Ressourcenbezeichner weggelassen werden. Dies entspricht also https://graph.microsoft.com/User.Read. Weitere Informationen finden Sie unter Bereiche und Berechtigungen.

Konfigurierte API-Berechtigungen, angeforderte Bereiche und Zustimmung sind unterschiedlich. Das Hinzufügen einer API-Berechtigung zu einer App-Registrierung erteilt nicht selbst die Zustimmung oder ändert die vom Code der Anwendung angeforderten Bereiche.

Ein Zugriffstoken ist spezifisch für seine API

Ein Zugriffstoken ist für eine bestimmte Ressource vorgesehen. Ein Token für Microsoft Graph kann nicht mit einem Token für eine andere API austauschbar sein, und ein ID-Token ist kein Ersatz für ein API-Zugriffstoken.

MSAL4J bezieht und zwischenspeichert Token. Die Anwendung verwendet das Token für seine beabsichtigte Ressource, anstatt es zu analysieren, um Annahmen über die Identität des angemeldeten Benutzers vorzunehmen oder es als wiederverwendbaren Autorisierungscode zu behandeln.

Beispielhafter stiller Tokenabruf

Bei späteren Anforderungen kann eine Webanwendung MSAL um ein Token bitten, ohne den Benutzer über eine andere Anmeldeinteraktion zu senden. Das folgende Fragment stammt aus dem AuthHelper des Referenzbeispiels. Es veranschaulicht das Wiederherstellen eines sitzungsbezogenen Caches und das Anfordern eines Tokens für ein Konto, das bereits in diesem Kontext dargestellt ist.

final SilentParameters parameters = SilentParameters
                                        .builder(Collections.singleton(Config.SCOPES), context.getAccount())
                                        .build();

final ConfidentialClientApplication client = getConfidentialClientInstance();
client.tokenCache().deserialize(context.getTokenCache());

final IAuthenticationResult result = client.acquireTokenSilently(parameters).get();

SilentParameters identifiziert den angeforderten Bereich und das angeforderte Konto. In diesem Beispiel enthält Config.SCOPESUser.Read, und context liefert das Konto und den serialisierten Cache, der der authentifizierten Sitzung zugeordnet ist. Hierbei handelt es sich um Beispielanwendungshilfsprogramme, nicht um Werte, die der Lernende abrufen muss.

Nachdem der Cache wiederhergestellt wurde, wird versucht, acquireTokenSilently die Anforderung ohne Benutzerinteraktion zu erfüllen. Es kann ein verwendbares zwischengespeichertes Zugriffstoken zurückgeben oder ggf. ein zwischengespeichertes Aktualisierungstoken verwenden. "Silent" bedeutet nicht unbedingt, dass keine Netzwerkanforderung auftritt.

Dieses Fragment lässt die umgebende Cachepersistenz und Ausnahmebehandlung aus. Wenn MSAL angibt, dass eine Benutzerinteraktion erforderlich ist, startet die Webanwendung eine neue Autorisierungsanforderung und verarbeitet den resultierenden Rückruf. Der alte Autorisierungscode wird nicht erneut eingelöst. Andere Fehler, z. B. Netzwerk- oder Konfigurationsfehler, benötigen eine geeignete Fehlerbehandlung anstelle einer bedingungslosen Anmeldeschleife.

Tokencache- und Sitzungsdaten enthalten vertrauliche Informationen. Eine vollständige Anwendung muss diese Daten schützen, sie dem richtigen Konto und der richtigen Sitzung zuordnen und Cacheänderungen entsprechend beibehalten.

Interpretieren des Ergebnisses vor dem API-Aufruf

Bei erfolgreichem Tokenerwerb wird ein IAuthenticationResult erzeugt, das das Zugriffstoken sowie Informationen über seine Lebensdauer und den Kontokontext enthält. Bei einer Microsoft Graph Anforderung stellt die Anwendung das Graph-Zugriffstoken für den HTTP-Client oder den Graph-Authentifizierungsanbieter bereit.

MSAL4J liest das Profil eines Benutzers nicht nur durch den Erwerb dieses Tokens. Die separate API-Anforderung führt den Datenvorgang aus.

Microsoft Graph stellt die Ressource bereit.

Microsoft Graph stellt Microsoft-Clouddaten und -dienste über https://graph.microsoft.com bereit. Der /v1.0/me Endpunkt stellt den angemeldeten Benutzer dar und erfordert einen delegierten Benutzerkontext.

Die nächste Einheit untersucht eine illustrative Anforderung an diesen Endpunkt und die entsprechende Anforderung über das Java Graph SDK. Die übersicht über Microsoft Graph beschreibt die umfassendere API.