Voyez également : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).
Ce qui suit (une bonne partie, hormis les notes) est une traduction du document RFC 6749 [1].
Autorisation via un code (Authorization Code Grant)
Le code d’autorisation est obtenu en utilisant un serveur d’autorisation comme intermédiaire entre le client [2] et le propriétaire de la ressource [3]. Au lieu de demander l’autorisation directement au propriétaire de la ressource, le client dirige le propriétaire de la ressource vers un serveur d’autorisation (via son user-agent [4] tel que défini dans [RFC2616]), qui à son tour ramène le propriétaire de la ressource au client avec le code d’autorisation.
Avant de rediriger le propriétaire de la ressource vers le client avec le code d’autorisation, le serveur d’autorisation authentifie le propriétaire de la ressource [5], et obtient l’autorisation. Étant donné que le propriétaire de la ressource s’authentifie uniquement auprès du serveur d’autorisation, les références du propriétaire de la ressource ne sont jamais partagées avec le client.
Le code d’autorisation présente quelques avantages de sécurité importants, tels que la capacité d’authentifier le client [6], ainsi que la transmission du jeton d’accès directement au client [7] sans passer par l’user-agent du propriétaire de la ressource et potentiellement l’exposer à d’autres, y compris le propriétaire de la ressource [8].
Avertissement : pour des développements nouveaux, il sera souvent préférable d’utiliser OpenID Connect : Autorisation via un code (Authorization Code Flow). Un avantage important d’OIDC est la transmission aux applications et aux ressources protégées du jeton JWT liant l’identité de l’utilisateur final, celle de l’application et une définition de la portée des autorisations accordées.
Autorisation via mot de passe (User Credentials, Resource Owner Password Credentials Grant)
L’accréditation via mot de passe [9] du propriétaire de ressource (c’est-à-dire nom d’utilisateur et mot de passe) peut être utilisée directement comme demande d’autorisation pour obtenir un jeton d’accès. L’accréditation ne doit être utilisée que lorsqu’il existe un degré de confiance élevé entre le propriétaire de la ressource et le client (par exemple le client fait partie du système d’exploitation de l’appareil ou d’une application ayant des privilèges élevés), et lorsque d’autres types de soumission d’autorisation ne sont pas disponibles (tel qu’un code d’autorisation).
Même si ce type de soumission nécessite un accès direct du client aux informations d’identification du propriétaire de la ressource [10], les informations d’identification du propriétaire de la ressource sont utilisées pour une demande unique et sont échangés contre un jeton d’accès. Ce type de soumission peut éliminer la nécessité pour le client de stocker les informations d’identification du propriétaire de la ressource pour un usage futur, grâce à un jeton d’accès à vie longue ou un jeton de rafraîchissement.
Autorisation serveur à serveur (Client Credentials Grant)
Les informations d’identification du client (ou d’autres formes d’authentification client) peuvent être utilisées comme une soumission d’autorisation lorsque le périmètre d’autorisation est limité aux ressources protégées sous le contrôle du client, ou à des ressources protégées précédemment négociées avec le serveur d’autorisation. Typiquement, les informations d’identification client sont utilisées comme une autorisation lorsque le client agit en son propre nom (le client est propriétaire de la ressource) ou demande l’accès à des ressources sur la base d’une autorisation préalablement négociée par le serveur d’autorisation [11].
Fin de la traduction du document RFC 6749.
Derrière les affirmations sur la sécurité, il apparait clairement que ces flux ne sont sécurisés que si l’on peut "faire confiance" aux applications clientes. Autant dire qu’ils ne sont sécurisés que dans un espace propriétaire (corporate realm). Il manque une signature pour authentifier le client, comme le démontre brillament Eran Hammer, un des concepteurs d’OAuth 2.0 : OAuth 2.0 (sans signature) est mauvais pour le Web.
Sur le sujet, voyez également : Typologie des applications au regard de la sécurité des données.
JWT Bearer (JWT Bearer Authorization Grant)
Ce flux d’autorisation présente la particularité de fournir un jeton JWT (JSON Web Token) au point d’accès Token pour obtenir un jeton d’accès.
Ce flux est également désigné par "Client Authentication" dans la RFC 7523.
Notes :
OAuthSD propose une approche unifiée des flux et des points d’entrée des protocoles OAuth 2.0 et d’OpenID Connect :
OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type),
OpenID Connect et OAuth 2.0 : Les points d’extrémité d’OAuthSD
Certains auteurs définissent dans le cadre d’OAuth 2.0 un flux "Refresh Token Grant" s’adressant au point d’extrémité de jeton. Il ne s’agit pas à proprement parler d’un flux puisque, prolongeant un flux d’autorisation établi précédemment, il ne peut exister de façon autonome. Voir : Rafraîchir (actualiser) un jeton d’accès.
RSS 2.0