4. Overview (Übersicht)
Für die Autorisierung von Benutzern in nativen Apps besteht die beste aktuelle Praxis (Best Current Practice) darin, die OAuth-Autorisierungsanfrage in einem externen User-Agent (External User-Agent) (typischerweise dem Browser) auszuführen und nicht in einem eingebetteten User-Agent (Embedded User-Agent) (wie einem, der mit Web-Views implementiert ist).
Früher war es üblich, dass native Apps eingebettete User-Agents (üblicherweise mit Web-Views implementiert) für OAuth-Autorisierungsanfragen verwendeten. Dieser Ansatz hat viele Nachteile, einschließlich der Möglichkeit, dass die Host-App Benutzeranmeldeinformationen und Cookies kopieren kann, sowie der Notwendigkeit für den Benutzer, sich in jeder App von Grund auf neu zu authentifizieren. Siehe Abschnitt 8.12 für eine tiefergehende Analyse der Nachteile der Verwendung eingebetteter User-Agents für OAuth.
Autorisierungsanfragen von nativen Apps, die den Browser verwenden, sind sicherer und können den Authentifizierungsstatus des Benutzers nutzen. Die Möglichkeit, die vorhandene Authentifizierungssitzung im Browser zu verwenden, ermöglicht Single Sign-On, da sich Benutzer nicht jedes Mal beim Authorization Server authentifizieren müssen, wenn sie eine neue App verwenden (sofern nicht durch die Richtlinie des Authorization Servers erforderlich).
Die Unterstützung von Autorisierungsabläufen zwischen einer nativen App und dem Browser ist möglich, ohne das OAuth-Protokoll selbst zu ändern, da die OAuth-Autorisierungsanfrage und -antwort bereits in Form von URIs definiert sind. Dies umfasst URIs, die für die Inter-App-Kommunikation verwendet werden können. Einige OAuth-Server-Implementierungen, die davon ausgehen, dass alle Clients vertrauliche Web-Clients sind, müssen ein Verständnis für öffentliche native App-Clients und die Typen von Redirect-URIs hinzufügen, die sie verwenden, um diese Best Practice zu unterstützen.
4.1. Authorization Flow for Native Apps Using the Browser (Autorisierungsablauf für native Apps mit dem Browser)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| User Device |
| |
| +--------------------------+ | (5) Authorization +---------------+
| | | | Code | |
| | Client App |---------------------->| Token |
| | |<----------------------| Endpoint |
| +--------------------------+ | (6) Access Token, | |
| | ^ | Refresh Token +---------------+
| | | |
| | | |
| | (1) | (4) |
| | Authorizat- | Authoriza- |
| | ion Request | tion Code |
| | | |
| | | |
| v | |
| +---------------------------+ | (2) Authorization +---------------+
| | | | Request | |
| | Browser |--------------------->| Authorization |
| | |<---------------------| Endpoint |
| +---------------------------+ | (3) Authorization | |
| | Code +---------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Abbildung 1: Native App-Autorisierung über einen externen User-Agent
Abbildung 1 veranschaulicht die Interaktion zwischen einer nativen App und dem Browser zur Autorisierung des Benutzers.
(1) Die Client-App öffnet einen Browser-Tab mit der Autorisierungsanfrage.
(2) Der Authorization Endpoint empfängt die Autorisierungsanfrage, authentifiziert den Benutzer und erhält die Autorisierung. Die Authentifizierung des Benutzers kann die Verkettung mit anderen Authentifizierungssystemen beinhalten.
(3) Der Authorization Server stellt einen Autorisierungscode für die Redirect-URI aus.
(4) Der Client empfängt den Autorisierungscode von der Redirect-URI.
(5) Die Client-App präsentiert den Autorisierungscode am Token Endpoint.
(6) Der Token Endpoint validiert den Autorisierungscode und stellt die angeforderten Token aus.