7. Receiving the Authorization Response in a Native App (Empfang der Autorisierungsantwort in einer nativen App)
Es gibt mehrere Redirect-URI-Optionen für native Apps zum Empfangen der Autorisierungsantwort vom Browser, deren Verfügbarkeit und Benutzererfahrung je nach Plattform variiert.
Um diese Best Practice vollständig zu unterstützen, müssen (MUST) Authorization Server mindestens die drei in den folgenden Unterabschnitten beschriebenen Redirect-URI-Optionen für native Apps anbieten. Native Apps können (MAY) jede Redirect-Option verwenden, die ihren Anforderungen am besten entspricht, unter Berücksichtigung plattformspezifischer Implementierungsdetails.
7.1. Private-Use URI Scheme Redirection (Privat genutztes URI-Schema-Redirection)
Viele mobile und Desktop-Computing-Plattformen unterstützen Inter-App-Kommunikation über URIs, indem sie Apps erlauben, privat genutzte URI-Schemas (manchmal umgangssprachlich als "benutzerdefinierte URL-Schemas" bezeichnet) wie "com.example.app" zu registrieren. Wenn der Browser oder eine andere App versucht, eine URI mit einem privat genutzten URI-Schema zu laden, wird die App, die es registriert hat, gestartet, um die Anfrage zu bearbeiten.
Um eine OAuth 2.0-Autorisierungsanfrage mit einer privat genutzten URI-Schema-Umleitung durchzuführen, startet die native App den Browser mit einer Standard-Autorisierungsanfrage, bei der die Redirect-URI jedoch ein privat genutztes URI-Schema verwendet, das sie beim Betriebssystem registriert hat.
Bei der Wahl eines URI-Schemas, das mit der App verbunden werden soll, müssen (MUST) Apps ein URI-Schema verwenden, das auf einem Domainnamen basiert, der unter ihrer Kontrolle steht, in umgekehrter Reihenfolge ausgedrückt, wie in Abschnitt 3.8 von [RFC7595] für privat genutzte URI-Schemas empfohlen.
Beispielsweise kann eine App, die den Domainnamen "app.example.com" kontrolliert, "com.example.app" als ihr Schema verwenden. Einige Authorization Server weisen Client-Identifikatoren basierend auf Domainnamen zu, zum Beispiel "client1234.usercontent.example.net", die auch als Domainname für das Schema verwendet werden können, wenn sie auf die gleiche Weise umgekehrt werden. Ein Schema wie "myapp" würde diese Anforderung jedoch nicht erfüllen, da es nicht auf einem Domainnamen basiert.
Wenn es mehrere Apps desselben Herausgebers gibt, muss darauf geachtet werden, dass jedes Schema innerhalb dieser Gruppe eindeutig ist. Auf Plattformen, die App-Identifikatoren basierend auf umgekehrten Domainnamen verwenden, können diese Identifikatoren als privat genutztes URI-Schema für die OAuth-Umleitung wiederverwendet werden, um dieses Problem zu vermeiden.
Gemäß den Anforderungen von Abschnitt 3.2 von [RFC3986] erscheint, da es keine Benennungsautorität für privat genutzte URI-Schema-Umleitungen gibt, nur ein einzelner Schrägstrich ("/") nach der Schema-Komponente. Ein vollständiges Beispiel einer Redirect-URI unter Verwendung eines privat genutzten URI-Schemas ist:
com.example.app:/oauth2redirect/example-provider
Wenn der Authorization Server die Anfrage abschließt, leitet er zur Redirect-URI des Clients um, wie er es normalerweise tun würde. Da die Redirect-URI ein privat genutztes URI-Schema verwendet, führt dies dazu, dass das Betriebssystem die native App startet und die URI als Startparameter übergibt. Dann verwendet die native App die normale Verarbeitung für die Autorisierungsantwort.
7.2. Claimed "https" Scheme URI Redirection (Beanspruchte "https"-Schema-URI-Umleitung)
Einige Betriebssysteme erlauben es Apps, "https"-Schema [RFC7230] URIs in den Domains zu beanspruchen, die sie kontrollieren. Wenn der Browser auf eine beanspruchte URI stößt, wird anstatt die Seite im Browser zu laden, die native App mit der URI als Startparameter gestartet.
Solche URIs können als Redirect-URIs von nativen Apps verwendet werden. Sie sind für den Authorization Server nicht von einer regulären webbasierten Client-Redirect-URI zu unterscheiden. Ein Beispiel ist:
https://app.example.com/oauth2redirect/example-provider
Da die Redirect-URI allein nicht ausreicht, um öffentliche native App-Clients von vertraulichen Web-Clients zu unterscheiden, ist in Abschnitt 8.4 erforderlich (REQUIRED), dass der Client-Typ während der Client-Registrierung aufgezeichnet wird, um es dem Server zu ermöglichen, den Client-Typ zu bestimmen und entsprechend zu handeln.
Von Apps beanspruchte "https"-Schema-Redirect-URIs haben einige Vorteile gegenüber anderen nativen App-Redirect-Optionen, da die Identität der Ziel-App dem Authorization Server vom Betriebssystem garantiert wird. Aus diesem Grund sollten (SHOULD) native Apps diese gegenüber den anderen Optionen verwenden, wo dies möglich ist.
7.3. Loopback Interface Redirection (Loopback-Schnittstellen-Umleitung)
Native Apps, die in der Lage sind, einen Port auf der Loopback-Netzwerkschnittstelle ohne besondere Berechtigungen zu öffnen (typischerweise solche auf Desktop-Betriebssystemen), können die Loopback-Schnittstelle verwenden, um die OAuth-Umleitung zu empfangen.
Loopback-Redirect-URIs verwenden das "http"-Schema und werden mit dem Loopback-IP-Literal und dem Port konstruiert, auf dem der Client lauscht.
Das heißt, http://127.0.0.1:{port}/{path} für IPv4 und http://[::1]:{port}/{path} für IPv6. Ein Beispiel für eine Umleitung unter Verwendung der IPv4-Loopback-Schnittstelle mit einem zufällig zugewiesenen Port:
http://127.0.0.1:51004/oauth2redirect/example-provider
Ein Beispiel für eine Umleitung unter Verwendung der IPv6-Loopback-Schnittstelle mit einem zufällig zugewiesenen Port:
http://[::1]:61023/oauth2redirect/example-provider
Der Authorization Server muss (MUST) zum Zeitpunkt der Anfrage für Loopback-IP-Redirect-URIs die Angabe eines beliebigen Ports zulassen, um Clients zu unterstützen, die zum Zeitpunkt der Anfrage einen verfügbaren ephemeren Port vom Betriebssystem erhalten.
Clients sollten nicht (SHOULD NOT) annehmen, dass das Gerät eine bestimmte Version des Internet-Protokolls unterstützt. Es wird empfohlen (RECOMMENDED), dass Clients versuchen, sich sowohl mit IPv4 als auch mit IPv6 an die Loopback-Schnittstelle zu binden und diejenige zu verwenden, die verfügbar ist.