Accueil > OpenID Connect OAuth Server par DnC > Développer > OAuth 2.0 : Les Types d’Autorisation (Grant Type)

OAuth 2.0 : Les Types d’Autorisation (Grant Type)

Dans le cadre du protocole OAuth 2.0, OAuth Server by DnC traite les types d’autorisation suivants :
- Autorisation via un code (Authorization Code Grant),
- Autorisation Implicite (Implicit Grant)
- Autorisation via mot de passe (User Credentials, Resource Owner Password Credentials Grant),
- Autorisation serveur à serveur (Client Credentials Grant),
- JWT Bearer (JWT Bearer Authorization Grant) .


Voyez également : OpenID Connect : 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].

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. [12]

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

[1Ceci est une première approche, car cette norme comporte de nombreuses ambiguïtés, voire des erreurs conceptuelles, qui obscurcissent la compréhension de OAuth.

[2Dans le vocabulaire d’OAuth, le terme "client" désigne une application cliente, c’est à dire l’application demandant l’accès à la ressource protégée.

[3En réalité, le serveur d’autorisation n’a pas la moindre idée du propriétaire de la ressource. Tout ce qu’il voit, c’est un utilisateur quelconque qui utilise une certaine application, laquelle délègue au serveur d’autorisation l’identification de l’utilisateur. Que celui-ci soit effectivement le propriétaire de la ressource préjuge de la suite du processus dite "authentification", qui implique le serveur de ressource, car seul celui-ci a une idée de qui sont les propriétaires des données. On préfèrera le terme "utilisateur final" (end user) pour désigner l’internaute qui tente d’accéder aux données protégées à travers l’application cliente.

[4Dans le cas général l’"user-agent" est le navigateur de l’utilisateur.

[5C’est précisément ce que ne fait pas le protocole OAuth qui n’est pas un protocole d’authentification. OAuth doit être encapsulé dans une couche de protocole supplémentaire tel que OpenID Connect pour assurer cette fonction. Voyez : Généralités sur l’authentification, introduction d’OpenID Connect.

[6en effet, mais le mot "authentification" devrait être réservé à l’identification sûre de l’utilisateur final.

[7à l’application cliente

[8Cette dernière phrase est assez incompréhensible. Il est bien évident que ce n’est pas le propriétaire de la ressource qui présente un risque de sécurité, mais un internaute quelconque, éventuellement malveillant, ou son navigateur éventuellement pollué par un malware. Il y a constamment confusion entre user-agent (le navigateur de n’importe quel internaute) et le propriétaire de la ressource. Il faut comprendre : "y compris n’importe quel user-agent mis en œuvre par un Internaute mal intentionné ou pollué par un malware."

[9Pourquoi parler de mot de passe, cela est très restrictif. Le serveur d’autorisation peut présenter à l’utilisateur différents moyens de s’identifier, par exemple un lecteur de carte, la reconnaissance biométrique etc..

[10Pas seulement : les informations d’identification doivent également circuler entre l’application et le serveur d’autorisation, ce qui retire presque tout intérêt à ce mode d’autorisation.

[11La deuxième phrase de cette définition est une paraphrase de la première, et semble plutôt meilleure.

[12Il se peut que nous ayons là une mort annoncée de OpenID Connect qui n’implique pas non plus de signature de la requête. Finalement, le flux JWT Bearer est intéressant...