9. Applications natives (Native Applications)

Les applications natives (Native Applications) sont des clients (Client) installés et exécutés sur l'appareil utilisé par le propriétaire de ressource (Resource Owner) (c'est-à-dire application de bureau, application mobile native). Les applications natives nécessitent une attention particulière en matière de sécurité, de capacités de plateforme et d'expérience utilisateur globale.

Le point de terminaison d'autorisation (Authorization Endpoint) nécessite une interaction entre le client et l'agent utilisateur (User-Agent) du propriétaire de ressource. Les applications natives peuvent invoquer un agent utilisateur externe ou intégrer un agent utilisateur dans l'application. Par exemple :

Agent utilisateur externe (External User-Agent) - l'application native peut capturer la réponse du serveur d'autorisation en utilisant un URI de redirection (Redirection URI) avec un schéma enregistré auprès du système d'exploitation pour invoquer le client en tant que gestionnaire, copier-coller manuel des informations d'identification, exécuter un serveur Web local, installer une extension d'agent utilisateur, ou en fournissant un URI de redirection identifiant une ressource hébergée sur serveur sous le contrôle du client, qui à son tour rend la réponse disponible pour l'application native.
Agent utilisateur intégré (Embedded User-Agent) - l'application native obtient la réponse en communiquant directement avec l'agent utilisateur intégré en surveillant les changements d'état émis pendant le chargement de la ressource, ou en accédant au stockage des cookies de l'agent utilisateur.

Lors du choix entre un agent utilisateur externe ou intégré, les développeurs devraient (SHOULD) considérer ce qui suit :

Un agent utilisateur externe peut améliorer le taux de complétion, car le propriétaire de ressource peut déjà avoir une session active avec le serveur d'autorisation, éliminant le besoin de se réauthentifier. Il offre une expérience utilisateur et des fonctionnalités familières. Le propriétaire de ressource peut également s'appuyer sur les fonctionnalités ou extensions de l'agent utilisateur pour aider à l'authentification (par exemple, gestionnaire de mots de passe, lecteur de dispositif à deux facteurs).
Un agent utilisateur intégré peut offrir une meilleure utilisabilité, car il élimine le besoin de changer de contexte et d'ouvrir de nouvelles fenêtres.
Un agent utilisateur intégré pose un défi de sécurité car les propriétaires de ressources s'authentifient dans une fenêtre non identifiée sans accès aux protections visuelles présentes dans la plupart des agents utilisateurs externes. Un agent utilisateur intégré éduque les utilisateurs finaux à faire confiance aux demandes d'authentification non identifiées (rendant les attaques de phishing plus faciles à exécuter).

Lors du choix entre le type d'autorisation implicite (Implicit Grant Type) et le type d'autorisation par code (Authorization Code Grant Type), les éléments suivants devraient (SHOULD) être pris en compte :

Les applications natives qui utilisent le type d'autorisation par code devraient (SHOULD) le faire sans utiliser d'informations d'identification de client, en raison de l'incapacité de l'application native à garder les informations d'identification de client confidentielles.
Lors de l'utilisation du flux de type d'autorisation implicite, un jeton de rafraîchissement (Refresh Token) n'est pas renvoyé, ce qui nécessite de répéter le processus d'autorisation une fois que le jeton d'accès (Access Token) expire.