9. Native Anwendungen (Native Applications)

Native Anwendungen (Native Applications) sind Clients (Client), die auf dem vom Ressourcenbesitzer (Resource Owner) verwendeten Gerät installiert und ausgeführt werden (d. h. Desktop-Anwendung, native mobile Anwendung). Native Anwendungen erfordern besondere Überlegungen in Bezug auf Sicherheit, Plattformfähigkeiten und die allgemeine Endbenutzererfahrung.

Der Autorisierungs-Endpunkt (Authorization Endpoint) erfordert eine Interaktion zwischen dem Client und dem Benutzeragenten (User-Agent) des Ressourcenbesitzers. Native Anwendungen können einen externen Benutzeragenten aufrufen oder einen Benutzeragenten in die Anwendung einbetten. Zum Beispiel:

Externer Benutzeragent (External User-Agent) - die native Anwendung kann die Antwort vom Autorisierungsserver mithilfe eines Weiterleitungs-URI (Redirection URI) mit einem beim Betriebssystem registrierten Schema erfassen, um den Client als Handler aufzurufen, manuelles Kopieren und Einfügen der Anmeldeinformationen, Ausführen eines lokalen Webservers, Installieren einer Benutzeragenten-Erweiterung oder durch Bereitstellung eines Weiterleitungs-URI, der eine servergehostete Ressource unter der Kontrolle des Clients identifiziert, die wiederum die Antwort für die native Anwendung verfügbar macht.
Eingebetteter Benutzeragent (Embedded User-Agent) - die native Anwendung erhält die Antwort durch direkte Kommunikation mit dem eingebetteten Benutzeragenten, indem Zustandsänderungen überwacht werden, die während des Ressourcenladens ausgegeben werden, oder durch Zugriff auf den Cookie-Speicher des Benutzeragenten.

Bei der Wahl zwischen einem externen oder eingebetteten Benutzeragenten sollten (SHOULD) Entwickler Folgendes berücksichtigen:

Ein externer Benutzeragent kann die Abschlussrate verbessern, da der Ressourcenbesitzer möglicherweise bereits eine aktive Sitzung mit dem Autorisierungsserver hat, wodurch die Notwendigkeit einer erneuten Authentifizierung entfällt. Es bietet eine vertraute Endbenutzererfahrung und Funktionalität. Der Ressourcenbesitzer kann sich auch auf Benutzeragenten-Funktionen oder -Erweiterungen verlassen, um bei der Authentifizierung zu helfen (z. B. Passwort-Manager, 2-Faktor-Geräteleser).
Ein eingebetteter Benutzeragent kann eine verbesserte Benutzerfreundlichkeit bieten, da die Notwendigkeit entfällt, den Kontext zu wechseln und neue Fenster zu öffnen.
Ein eingebetteter Benutzeragent stellt eine Sicherheitsherausforderung dar, da sich Ressourcenbesitzer in einem nicht identifizierten Fenster ohne Zugriff auf die visuellen Schutzmaßnahmen authentifizieren, die in den meisten externen Benutzeragenten zu finden sind. Ein eingebetteter Benutzeragent schult Endbenutzer darin, nicht identifizierten Authentifizierungsanforderungen zu vertrauen (was Phishing-Angriffe leichter ausführbar macht).

Bei der Wahl zwischen dem impliziten Autorisierungstyp (Implicit Grant Type) und dem Autorisierungscode-Autorisierungstyp (Authorization Code Grant Type) sollte (SHOULD) Folgendes berücksichtigt werden:

Native Anwendungen, die den Autorisierungscode-Autorisierungstyp verwenden, sollten (SHOULD) dies ohne Verwendung von Client-Anmeldeinformationen tun, da die native Anwendung nicht in der Lage ist, Client-Anmeldeinformationen vertraulich zu halten.
Bei Verwendung des impliziten Autorisierungstyp-Flusses wird kein Aktualisierungstoken (Refresh Token) zurückgegeben, was eine Wiederholung des Autorisierungsprozesses erfordert, sobald das Zugangstoken (Access Token) abläuft.