4. Overview (Vue d'ensemble)
Pour autoriser les utilisateurs dans les applications natives, la meilleure pratique actuelle consiste à effectuer la demande d'autorisation OAuth dans un agent utilisateur externe (External User-Agent) (généralement le navigateur) plutôt que dans un agent utilisateur intégré (Embedded User-Agent) (tel que celui implémenté avec des web-views).
Auparavant, il était courant que les applications natives utilisent des agents utilisateurs intégrés (généralement implémentés avec des web-views) pour les demandes d'autorisation OAuth. Cette approche présente de nombreux inconvénients, notamment le fait que l'application hôte puisse copier les identifiants et les cookies de l'utilisateur, ainsi que le besoin pour l'utilisateur de s'authentifier à partir de zéro dans chaque application. Voir la Section 8.12 pour une analyse plus approfondie des inconvénients de l'utilisation d'agents utilisateurs intégrés pour OAuth.
Les demandes d'autorisation des applications natives qui utilisent le navigateur sont plus sécurisées et peuvent tirer parti de l'état d'authentification de l'utilisateur. La possibilité d'utiliser la session d'authentification existante dans le navigateur permet une authentification unique (Single Sign-On), car les utilisateurs n'ont pas besoin de s'authentifier auprès du serveur d'autorisation chaque fois qu'ils utilisent une nouvelle application (sauf si requis par la politique du serveur d'autorisation).
La prise en charge des flux d'autorisation entre une application native et le navigateur est possible sans modifier le protocole OAuth lui-même, car la demande et la réponse d'autorisation OAuth sont déjà définies en termes d'URI. Cela englobe les URI qui peuvent être utilisés pour la communication inter-applications. Certaines implémentations de serveur OAuth qui supposent que tous les clients sont des clients web confidentiels devront ajouter une compréhension des clients d'applications natives publiques et des types d'URI de redirection qu'ils utilisent pour prendre en charge cette meilleure pratique.
4.1. Authorization Flow for Native Apps Using the Browser (Flux d'autorisation pour les applications natives utilisant le navigateur)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| 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 +---------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Figure 1 : Autorisation d'application native via un agent utilisateur externe
La figure 1 illustre l'interaction entre une application native et le navigateur pour autoriser l'utilisateur.
(1) L'application cliente ouvre un onglet de navigateur avec la demande d'autorisation.
(2) Le point de terminaison d'autorisation reçoit la demande d'autorisation, authentifie l'utilisateur et obtient l'autorisation. L'authentification de l'utilisateur peut impliquer un enchaînement vers d'autres systèmes d'authentification.
(3) Le serveur d'autorisation émet un code d'autorisation vers l'URI de redirection.
(4) Le client reçoit le code d'autorisation depuis l'URI de redirection.
(5) L'application cliente présente le code d'autorisation au point de terminaison de jeton.
(6) Le point de terminaison de jeton valide le code d'autorisation et émet les jetons demandés.