7. Receiving the Authorization Response in a Native App (Réception de la réponse d'autorisation dans une application native)
Plusieurs options d'URI de redirection sont disponibles pour les applications natives pour recevoir la réponse d'autorisation du navigateur, dont la disponibilité et l'expérience utilisateur varient selon la plateforme.
Pour prendre en charge complètement cette meilleure pratique, les serveurs d'autorisation doivent (MUST) offrir au moins les trois options d'URI de redirection décrites dans les sous-sections suivantes aux applications natives. Les applications natives peuvent (MAY) utiliser l'option de redirection qui convient le mieux à leurs besoins, en tenant compte des détails d'implémentation spécifiques à la plateforme.
7.1. Private-Use URI Scheme Redirection (Redirection par schéma URI à usage privé)
De nombreuses plateformes informatiques mobiles et de bureau prennent en charge la communication inter-applications via des URI en permettant aux applications d'enregistrer des schémas URI à usage privé (parfois appelés familièrement "schémas URL personnalisés") comme "com.example.app". Lorsque le navigateur ou une autre application tente de charger un URI avec un schéma URI à usage privé, l'application qui l'a enregistré est lancée pour gérer la demande.
Pour effectuer une demande d'autorisation OAuth 2.0 avec une redirection par schéma URI à usage privé, l'application native lance le navigateur avec une demande d'autorisation standard, mais celle où l'URI de redirection utilise un schéma URI à usage privé qu'elle a enregistré auprès du système d'exploitation.
Lors du choix d'un schéma URI à associer à l'application, les applications doivent (MUST) utiliser un schéma URI basé sur un nom de domaine sous leur contrôle, exprimé dans l'ordre inverse, comme recommandé par la Section 3.8 de [RFC7595] pour les schémas URI à usage privé.
Par exemple, une application qui contrôle le nom de domaine "app.example.com" peut utiliser "com.example.app" comme schéma. Certains serveurs d'autorisation attribuent des identifiants clients basés sur des noms de domaine, par exemple "client1234.usercontent.example.net", qui peuvent également être utilisés comme nom de domaine pour le schéma lorsqu'ils sont inversés de la même manière. Un schéma tel que "myapp", cependant, ne répondrait pas à cette exigence, car il n'est pas basé sur un nom de domaine.
Lorsqu'il y a plusieurs applications du même éditeur, il faut veiller à ce que chaque schéma soit unique au sein de ce groupe. Sur les plateformes qui utilisent des identifiants d'application basés sur des noms de domaine en ordre inverse, ces identifiants peuvent être réutilisés comme schéma URI à usage privé pour la redirection OAuth afin d'aider à éviter ce problème.
Conformément aux exigences de la Section 3.2 de [RFC3986], comme il n'y a pas d'autorité de nommage pour les redirections par schéma URI à usage privé, seule une barre oblique ("/") apparaît après le composant du schéma. Un exemple complet d'URI de redirection utilisant un schéma URI à usage privé est :
com.example.app:/oauth2redirect/example-provider
Lorsque le serveur d'autorisation termine la demande, il redirige vers l'URI de redirection du client comme il le ferait normalement. Comme l'URI de redirection utilise un schéma URI à usage privé, cela entraîne le lancement de l'application native par le système d'exploitation, en transmettant l'URI comme paramètre de lancement. Ensuite, l'application native utilise le traitement normal pour la réponse d'autorisation.
7.2. Claimed "https" Scheme URI Redirection (Redirection par URI de schéma "https" revendiqué)
Certains systèmes d'exploitation permettent aux applications de revendiquer des URI de schéma "https" [RFC7230] dans les domaines qu'elles contrôlent. Lorsque le navigateur rencontre un URI revendiqué, au lieu que la page soit chargée dans le navigateur, l'application native est lancée avec l'URI fourni comme paramètre de lancement.
De tels URI peuvent être utilisés comme URI de redirection par les applications natives. Ils sont indiscernables pour le serveur d'autorisation d'un URI de redirection client web régulier. Un exemple est :
https://app.example.com/oauth2redirect/example-provider
Comme l'URI de redirection seul ne suffit pas à distinguer les clients d'applications natives publiques des clients web confidentiels, il est requis (REQUIRED) dans la Section 8.4 que le type de client soit enregistré lors de l'enregistrement du client pour permettre au serveur de déterminer le type de client et d'agir en conséquence.
Les URI de redirection de schéma "https" revendiqués par l'application présentent certains avantages par rapport aux autres options de redirection d'applications natives dans la mesure où l'identité de l'application de destination est garantie au serveur d'autorisation par le système d'exploitation. Pour cette raison, les applications natives devraient (SHOULD) les utiliser de préférence aux autres options lorsque cela est possible.
7.3. Loopback Interface Redirection (Redirection par interface de bouclage)
Les applications natives capables d'ouvrir un port sur l'interface réseau de bouclage sans nécessiter de permissions spéciales (généralement, celles sur les systèmes d'exploitation de bureau) peuvent utiliser l'interface de bouclage pour recevoir la redirection OAuth.
Les URI de redirection de bouclage utilisent le schéma "http" et sont construits avec le littéral IP de bouclage et le port sur lequel le client écoute.
C'est-à-dire http://127.0.0.1:{port}/{path} pour IPv4, et http://[::1]:{port}/{path} pour IPv6. Un exemple de redirection utilisant l'interface de bouclage IPv4 avec un port attribué aléatoirement :
http://127.0.0.1:51004/oauth2redirect/example-provider
Un exemple de redirection utilisant l'interface de bouclage IPv6 avec un port attribué aléatoirement :
http://[::1]:61023/oauth2redirect/example-provider
Le serveur d'autorisation doit (MUST) permettre de spécifier n'importe quel port au moment de la demande pour les URI de redirection IP de bouclage, afin d'accommoder les clients qui obtiennent un port éphémère disponible du système d'exploitation au moment de la demande.
Les clients ne devraient pas (SHOULD NOT) supposer que l'appareil prend en charge une version particulière du protocole Internet. Il est recommandé (RECOMMENDED) que les clients tentent de se lier à l'interface de bouclage en utilisant à la fois IPv4 et IPv6 et utilisent celui qui est disponible.