Native Anwendungen

Native Apps sind Anwendungen, die eine Web-API im Namen eines Benutzers aufrufen. Dieses Szenario basiert auf dem OAuth 2.0-Autorisierungscode-Erteilungstyp mit einem öffentlichen Client, wie in Abschnitt 4.1 der OAuth 2.0-Spezifikationbeschrieben. Die systemeigene Anwendung ruft mithilfe des OAuth 2.0-Protokolls ein Zugriffstoken für den Benutzer ab. Dieses Zugriffstoken wird dann in der Anforderung an die Web-API gesendet, die den Benutzer autorisiert und die gewünschte Ressource zurückgibt.

Diagramm

Protokollfluss

Wenn Sie die AD-Authentifizierungsbibliotheken verwenden, werden die meisten der unten beschriebenen Protokolldetails für Sie behandelt, z. B. das Popupmenü des Browsers, das Zwischenspeichern von Token und die Behandlung von Aktualisierungstoken.

1. Mithilfe eines Browser-Popups sendet die systemeigene Anwendung eine Anforderung an den Autorisierungsendpunkt in Azure AD. Diese Anforderung enthält die Anwendungs-ID und den Umleitungs-URI der systemeigenen Anwendung, wie im Azure-Portal dargestellt, und den Anwendungs-ID-URI für die Web-API. Wenn sich der Benutzer noch nicht angemeldet hat, wird er aufgefordert, sich erneut anzumelden.
2. Azure AD authentifiziert den Benutzer. Wenn es sich um eine mehrinstanzenfähige Anwendung handelt und die Zustimmung zur Verwendung der Anwendung erforderlich ist, muss der Benutzer zustimmen, wenn er dies noch nicht getan hat. Nach der Erteilung der Zustimmung und der erfolgreichen Authentifizierung gibt Azure AD einen Autorisierungscode als Antwort zur Umleitungs-URI der Clientapplikation zurück.
3. Wenn Azure AD eine Autorisierungscodeantwort zurück auf den Umleitungs-URI ausgibt, stoppt die Clientanwendung die Browserinteraktion und extrahiert den Autorisierungscode aus der Antwort. Mithilfe dieses Autorisierungscodes sendet die Clientanwendung eine Anforderung an den Tokenendpunkt von Azure AD, der den Autorisierungscode enthält, Details zur Clientanwendung (Anwendungs-ID und Umleitungs-URI) und die gewünschte Ressource (Anwendungs-ID-URI für die Web-API).
4. Der Autorisierungscode und Informationen zur Clientanwendung und Web-API werden von Azure AD überprüft. Nach erfolgreicher Überprüfung gibt Azure AD zwei Token zurück: ein JWT-Zugriffstoken und ein JWT-Aktualisierungstoken. Darüber hinaus gibt Azure AD grundlegende Informationen zum Benutzer zurück, z. B. den Anzeigenamen und die Mandanten-ID.
5. Über HTTPS verwendet die Clientanwendung das zurückgegebene JWT-Zugriffstoken, um die JWT-Zeichenfolge mit der Bezeichnung "Bearer" im Autorisierungsheader der Anforderung zur Web-API hinzuzufügen. Die Web-API überprüft dann das JWT-Token und gibt bei erfolgreicher Überprüfung die gewünschte Ressource zurück.
6. Wenn das Zugriffstoken abläuft, erhält die Clientanwendung einen Fehler, der angibt, dass sich der Benutzer erneut authentifizieren muss. Wenn die Anwendung über ein gültiges Aktualisierungstoken verfügt, kann es verwendet werden, um ein neues Zugriffstoken abzurufen, ohne dass der Benutzer aufgefordert wird, sich erneut anzumelden. Wenn das Aktualisierungstoken abläuft, muss die Anwendung den Benutzer erneut interaktiv authentifizieren.

Codebeispiele

Sehen Sie sich die Codebeispiele für Native Application to Web API-Szenarien an. Und schauen Sie häufig wieder vorbei – wir fügen häufig neue Beispiele hinzu. Native Application to Web API.

App-Registrierung

Informationen zum Registrieren einer Anwendung beim Azure AD v1.0-Endpunkt finden Sie unter Registrieren einer App.

• Einzelner Mandant – Sowohl die systemeigene Anwendung als auch die Web-API müssen im selben Verzeichnis in Azure AD registriert werden. Die Web-API kann so konfiguriert werden, dass eine Reihe von Berechtigungen verfügbar gemacht wird, die verwendet werden, um den Zugriff der systemeigenen Anwendung auf ihre Ressourcen zu beschränken. Die Clientanwendung wählt dann die gewünschten Berechtigungen aus dem Dropdownmenü "Berechtigungen für andere Anwendungen" im Azure-Portal aus.
• Multi-Tenant-Architektur – Zuerst wird die native Anwendung immer nur im Verzeichnis des Entwicklers oder Herausgebers registriert. Zweitens ist die systemeigene Anwendung so konfiguriert, dass sie die Berechtigungen angibt, die für die Funktion erforderlich sind. Diese Liste der erforderlichen Berechtigungen wird in einem Dialogfeld angezeigt, wenn ein Benutzer oder Administrator im Zielverzeichnis der Anwendung zugestimmt hat, die sie ihrer Organisation zur Verfügung stellt. Einige Anwendungen erfordern nur Berechtigungen auf Benutzerebene, denen jeder Benutzer in der Organisation zustimmen kann. Andere Anwendungen erfordern Berechtigungen auf Administratorebene, denen ein Benutzer in der Organisation nicht zustimmen kann. Nur ein Verzeichnisadministrator kann Anwendungen zustimmen, die diese Berechtigungsstufe erfordern. Wenn der Benutzer oder Administrator zustimmt, wird nur die Web-API in ihrem Verzeichnis registriert.

Token-Ablauf

Wenn die systemeigene Anwendung ihren Autorisierungscode zum Abrufen eines JWT-Zugriffstokens verwendet, empfängt sie auch ein JWT-Aktualisierungstoken. Wenn das Zugriffstoken abläuft, kann das Aktualisierungstoken verwendet werden, um den Benutzer erneut zu authentifizieren, ohne dass er sich erneut anmelden muss. Dieses Aktualisierungstoken wird dann verwendet, um den Benutzer zu authentifizieren, was zu einem neuen Zugriffstoken und Aktualisierungstoken führt.

Nächste Schritte

• Weitere Informationen zu anderen Anwendungstypen und Szenarien
• Erfahren Sie mehr über die Azure AD -Authentifizierungsgrundlagen