Appendix B. Platform-Specific Implementation Details (Annexe B. Détails d'implémentation spécifiques à la plateforme)
Ce document définit principalement les meilleures pratiques de manière générique, en référençant des techniques couramment disponibles dans divers environnements. Cette section non normative documente les détails d'implémentation de la meilleure pratique pour divers systèmes d'exploitation.
Les détails d'implémentation ici sont considérés comme exacts au moment de la publication mais changeront probablement avec le temps. On espère qu'un tel changement n'invalidera pas les principes génériques du reste du document et que ces principes devraient avoir la priorité en cas de conflit.
B.1. iOS Implementation Details (Détails d'implémentation iOS)
Les applications peuvent initier une demande d'autorisation dans le navigateur, sans que l'utilisateur ne quitte l'application, via la classe "SFSafariViewController" ou son successeur "SFAuthenticationSession", qui implémentent le modèle d'onglet de navigateur intégré à l'application. Safari peut être utilisé pour gérer les demandes sur les anciennes versions d'iOS sans fonctionnalité d'onglet de navigateur intégré à l'application.
Pour recevoir la réponse d'autorisation, les redirections par schéma URI à usage privé (appelées "schéma URL personnalisé") et les URI de schéma "https" revendiqués (connus sous le nom de "Universal Links") sont des choix viables. Les applications peuvent revendiquer des schémas URI à usage privé avec la clé "CFBundleURLTypes" dans le fichier de liste de propriétés de l'application, "Info.plist", et les URI de schéma "https" en utilisant la fonctionnalité Universal Links avec un fichier d'habilitation dans l'application et un fichier d'association hébergé sur le domaine.
Les URI de schéma "https" revendiqués sont le choix de redirection préféré sur iOS 9 et supérieur en raison de la preuve de propriété fournie par le système d'exploitation.
Un exemple open-source complet est inclus dans la bibliothèque AppAuth for iOS and macOS [AppAuth.iOSmacOS].
B.2. Android Implementation Details (Détails d'implémentation Android)
Les applications peuvent initier une demande d'autorisation dans le navigateur, sans que l'utilisateur ne quitte l'application, via la fonctionnalité Android Custom Tab, qui implémente le modèle d'onglet de navigateur intégré à l'application. Le navigateur par défaut de l'utilisateur peut être utilisé pour gérer les demandes lorsqu'aucun navigateur ne prend en charge les Custom Tabs.
Les fournisseurs de navigateurs Android devraient prendre en charge le protocole Custom Tabs (en fournissant une implémentation de la classe "CustomTabsService"), pour fournir l'optimisation de l'expérience utilisateur d'onglet de navigateur intégré à l'application à leurs utilisateurs. Chrome est un tel navigateur qui implémente les Custom Tabs.
Pour recevoir la réponse d'autorisation, les schémas URI à usage privé sont largement pris en charge via les Android Implicit Intents. Les URI de redirection de schéma "https" revendiqués via les Android App Links sont disponibles sur Android 6.0 et supérieur. Les deux types d'URI de redirection sont enregistrés dans le manifeste de l'application.
Un exemple open-source complet est inclus dans la bibliothèque AppAuth for Android [AppAuth.Android].
B.3. Windows Implementation Details (Détails d'implémentation Windows)
Les applications traditionnelles et Universal Windows Platform (UWP) peuvent effectuer des demandes d'autorisation dans le navigateur de l'utilisateur. Les applications traditionnelles utilisent généralement une redirection de bouclage pour recevoir la réponse d'autorisation, et l'écoute sur l'interface de bouclage est autorisée par les règles de pare-feu par défaut. Lors de la création du socket réseau de bouclage, les applications devraient (SHOULD) définir l'option de socket "SO_EXCLUSIVEADDRUSE" pour empêcher d'autres applications de se lier au même socket.
Les applications UWP peuvent utiliser des redirections de schéma URI à usage privé pour recevoir la réponse d'autorisation du navigateur, ce qui mettra l'application au premier plan. Connu sur la plateforme sous le nom d'"URI Activation", le schéma URI est limité à 39 caractères de longueur, et il peut inclure le caractère ".", rendant possibles les schémas courts basés sur des noms de domaine inversés (comme requis dans la Section 7.1).
Les applications UWP peuvent alternativement utiliser l'API Web Authentication Broker en mode Single Sign-on (SSO), qui est un agent utilisateur externe conçu pour les flux d'autorisation. Les cookies sont partagés entre les invocations du broker mais pas avec le navigateur préféré de l'utilisateur, ce qui signifie que l'utilisateur devra se connecter à nouveau, même s'il a une session active dans son navigateur ; mais la session créée dans le broker sera disponible pour les applications ultérieures qui utilisent le broker. Les personnalisations que l'utilisateur a apportées à son navigateur, telles que la configuration d'un gestionnaire de mots de passe, peuvent ne pas être disponibles dans le broker. Pour être qualifié d'agent utilisateur externe, le broker doit (MUST) être utilisé en mode SSO.
Pour utiliser le Web Authentication Broker en mode SSO, l'URI de redirection doit être de la forme msapp://{appSID} où "{appSID}" est l'identifiant de sécurité (SID) de l'application, qui peut être trouvé dans les informations d'enregistrement de l'application ou en appelant la méthode "GetCurrentApplicationCallbackUri". Bien que Windows applique l'autorité URI sur de telles redirections, garantissant que seule l'application avec le SID correspondant peut recevoir la réponse sur Windows, le schéma URI pourrait être revendiqué par des applications sur d'autres plateformes sans la même autorité présente ; ainsi, ce type de redirection devrait être traité de manière similaire aux redirections de schéma URI à usage privé à des fins de sécurité.
Un exemple open-source démontrant ces modèles est disponible [SamplesForWindows].
B.4. macOS Implementation Details (Détails d'implémentation macOS)
Les applications peuvent initier une demande d'autorisation dans le navigateur par défaut de l'utilisateur en utilisant les API de plateforme pour ouvrir des URI dans le navigateur.
Pour recevoir la réponse d'autorisation, les schémas URI à usage privé sont un bon choix d'URI de redirection sur macOS, car l'utilisateur est ramené directement à l'application à partir de laquelle il a lancé la demande. Ceux-ci sont enregistrés dans la liste de propriétés d'informations de bundle de l'application en utilisant la clé "CFBundleURLSchemes". Les redirections IP de bouclage sont une autre option viable, et l'écoute sur l'interface de bouclage est autorisée par les règles de pare-feu par défaut.
Un exemple open-source complet est inclus dans la bibliothèque AppAuth for iOS and macOS [AppAuth.iOSmacOS].
B.5. Linux Implementation Details (Détails d'implémentation Linux)
L'ouverture de la demande d'autorisation dans le navigateur par défaut de l'utilisateur nécessite une commande spécifique à la distribution : "xdg-open" est un tel outil.
La redirection de bouclage est le choix de redirection recommandé pour les applications de bureau sur Linux pour recevoir la réponse d'autorisation. Les applications ne devraient pas (SHOULD NOT) définir les options de socket "SO_REUSEPORT" ou "SO_REUSEADDR" afin d'empêcher d'autres applications de se lier au même socket.