Flux OAuth 2.0 et types de jetons

OAuth 2.0 définit quatre rôles. Le propriétaire de la ressource est l'utilisateur qui possède les données, par exemple ses fichiers Google Drive. Le client est l'application qui demande l'accès. Le serveur d'autorisation émet les jetons d'accès, par exemple le serveur OAuth de Google. Le serveur de ressources héberge les données protégées, par exemple l'API Google Drive. Comprendre ces rôles permet de clarifier l'objectif de chaque flux.

Le flux de code d'autorisation est le flux approprié pour les applications web côté serveur. L'utilisateur s'authentifie auprès du serveur d'autorisation, qui le redirige vers le client avec un code d'autorisation à courte durée de vie. Le serveur du client échange ce code contre des jetons via une requête par canal secondaire. Les jetons ne transitent jamais par le navigateur, ce qui les protège contre les fuites dans l'historique du navigateur et le référent.

Le flux implicite a été conçu pour les applications JavaScript exécutées uniquement dans le navigateur, qui ne pouvaient pas stocker les secrets du client de manière sécurisée. Les jetons étaient renvoyés directement dans le fragment de l'URL, sans passer par le canal secondaire. Le flux implicite est obsolète dans OAuth 2.1, car PKCE (RFC 7636) permet aux clients publics d'utiliser le flux de code d'autorisation de manière sécurisée, sans secret client.

Le flux ROPC permet aux clients de recueillir directement le nom d'utilisateur et le mot de passe de l'utilisateur, puis de les échanger contre des jetons. Ce flux était destiné aux clients de première partie hautement fiables, mais il contredit fondamentalement l'objectif d'OAuth, qui est d'empêcher les applications d'accéder aux identifiants des utilisateurs. Il est obsolète dans OAuth 2.1 et ne doit être utilisé dans aucune nouvelle application.

Le flux des identifiants du client sert à l'authentification de machine à machine (M2M), lorsqu'aucun utilisateur n'intervient. Le client s'authentifie directement auprès du serveur d'autorisation à l'aide de son identifiant et de son secret, puis reçoit un jeton d'accès destiné à son propre usage. Cas d'utilisation courants : tâches en arrière-plan, communication entre microservices et passerelles d'API accédant à des services principaux.

Le flux d'autorisation de l'appareil (RFC 8628) permet d'utiliser OAuth sur des appareils dont les capacités de saisie sont limitées : téléviseurs connectés, consoles de jeux, imprimantes et appareils IoT. L'appareil affiche un code court et une URL. L'utilisateur ouvre l'URL sur un téléphone ou un ordinateur pour autoriser l'accès. L'appareil interroge périodiquement le serveur d'autorisation jusqu'à ce que l'utilisateur termine l'autorisation.

OAuth 2.0 définit deux types de jetons d'accès. Les jetons opaques sont des chaînes aléatoires que le serveur de ressources valide en appelant le point de terminaison d'introspection du serveur d'autorisation. Les jetons d'accès JWT sont autonomes : le serveur de ressources peut les valider localement en vérifiant leur signature, ce qui réduit les appels à l'API d'introspection, mais nécessite une gestion des clés.

Les jetons d'actualisation sont des identifiants à longue durée de vie utilisés pour obtenir de nouveaux jetons d'accès après l'expiration du jeton d'accès. La rotation des jetons d'actualisation, obligatoire dans OAuth 2.1 pour les clients publics, émet un nouveau jeton d'actualisation à chaque utilisation et invalide l'ancien. Si un jeton d'actualisation volé est utilisé, le client légitime détecte l'invalidation, ce qui permet de détecter le vol du jeton.

La RFC 7662 définit le point de terminaison d'introspection des jetons, qui permet aux serveurs de ressources d'interroger le serveur d'autorisation sur l'état actuel (actif/inactif), la portée, le sujet et l'expiration d'un jeton d'accès opaque. L'introspection permet la révocation en temps réel des jetons : dès qu'un jeton est révoqué sur le serveur d'autorisation, les appels d'introspection renvoient immédiatement active: false.

La RFC 7009 définit le point de terminaison de révocation des jetons, qui permet aux clients d'informer le serveur d'autorisation qu'un jeton, d'accès ou d'actualisation, doit être invalidé. Cette fonctionnalité est utilisée lors de la déconnexion ou lorsqu'un client détecte une activité suspecte. Les jetons d'accès JWT ne peuvent pas être entièrement révoqués sans liste de révocation, car les serveurs de ressources les valident localement sans contacter le serveur d'autorisation.

Les portées OAuth 2.0 définissent les autorisations précises que le client demande. Le serveur d'autorisation présente les portées demandées à l'utilisateur afin qu'il les approuve. Les serveurs de ressources appliquent les exigences de portée pour chaque point de terminaison. Le principe du moindre privilège s'applique : les clients ne doivent demander que les portées minimales nécessaires, et les serveurs de ressources doivent rejeter les requêtes dont la portée est insuffisante.

Le flux de code d'autorisation convient aux applications côté serveur. Le flux implicite est obsolète (utilisez PKCE à la place). Le flux ROPC est obsolète (il annule l'objectif d'OAuth). Les identifiants du client servent aux échanges M2M. L'autorisation de l'appareil convient aux appareils dont les capacités de saisie sont limitées. Les jetons d'accès sont opaques ou JWT. Les jetons d'actualisation doivent faire l'objet d'une rotation. L'introspection (RFC 7662) et la révocation (RFC 7009) complètent la gestion des jetons.