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

, par DnC

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 via mot de passe (User Credentials, Resource Owner Password Credentials Grant),
- Autorisation serveur à serveur (Client Credentials Grant),
- JWT Bearer (JWT Bearer Authorization Grant) en développement.

Nous ne développons pas l’Autorisation Implicite (Implicit Grant), cette méthode étant non-sûre.

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.

JWT Bearer (JWT Bearer Authorization Grant)

Comme son nom l’indique, ce flux d’autorisation transporte un jeton JWT (JSON Web Token). Ce faisant, des informations sur l’application et l’utilisateur sont directement véhiculées par le jeton.

Ce flux est également désigné par "Client Authentication" dans la RFC 7523.

Arrivé à ce point, nous sommes d’avis qu’il vaut mieux passer à OpenID Connect.

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.

OAuth 2.0 : Points d’extrémité

, par DnC

Note : Les points d’extrémité du protocole OpenID Connect sont traités ici : OpenID Connect : Points d’extrémité.

Points d’extrémité définis par OAuth 2.0

Le point d’extrémité d’autorisation et le point d’extrémité de jeton sont tous deux situés sur le serveur d’autorisation (ce serveur). OAuth Server by DnC y ajoute trois points d’extrémé.

Le point d’extrémité de redirection est situé dans l’application cliente.

Les points d’extrémité sont illustrés dans ce schéma (cas du flux d’Autorisation via un code) :

OAuth 2.0 Endpoints.

La spécification OAuth 2.0 ne décrit pas comment l’URI de ces points d’extrémité est définie ni les documente. C’est à chaque développeur de décider. Voici comment OAuth Server by DnC définit les points d’extrémité :

Point d’extrémité d’autorisation (Authorization Endpoint)
https://oa.dnc.global/oauth/authorize.php
Usage : OAuth 2.0 : Obtenir une autorisation pour l’application cliente.

Le point d’extrémité d’autorisation est le point d’extrémité sur le serveur d’autorisation auquel l’utilisateur final se connecte à l’aide de l’user-agent (en général un navigateur Web), et accorde l’autorisation à l’application cliente.

Point d’extrémité de redirection, ou URI de retour à l’application cliente (Redirection Endpoint)
Le point d’extrémité de redirection est le point d’extrémité dans l’application cliente vers lequel le user-agent est redirigé, après avoir obtenu l’autorisation au point d’extrémité d’autorisation. Cet URI est défini par l’auteur d’une application cliente quand il l’inscrit sur ce serveur. Voir : Lier une application cliente au serveur OAuthSD.

Point d’extrémité de jeton (Token Endpoint)
https://oa.dnc.global/oauth/token.php
Usages : OAuth 2.0 : Obtenir un jeton d’accès, Rafraîchir un jeton d’accès.

Le point d’extrémité de jeton est le point d’extrémité sur le serveur d’autorisation auquel s’adresse l’application cliente avec le code d’autorisation, l’ID client et le secret, pour obtenir un jeton d’accès ou rafraîchir un jeton d’accès ayant expiré.

Points d’extrémité définis par OAuth Server by DnC pour la vérification du jeton d’accès

Point d’extrémité de ressource (Resource Endpoint) [1]
https://oa.dnc.global/oauth/resource.php
Usage : Validation du jeton d’accès par interrogation du serveur d’autorisation (Introspection)

Dans l’exemple de flux ci-dessus, l’envoi à l’application cliente d’un jeton d’accès valide lui permet d’être "logged-in". La plupart des sites web et blogs décrivant OAuth ne traitent pas de la validation du jeton d’accès. Ceci veut-il dire que leur approche du protocole se limite à l’authentification des utilisateurs pour l’accès à l’application ?

Cependant, ce n’est pas fini : l’intérêt d’un jeton d’accès réside dans l’usage qui en sera fait par l’application cliente pour signaler à un serveur de ressources protégées qu’elle est autorisée à obtenir des données.

La norme OAuth 2.0 n’indique pas comment les serveurs de données protégées qui reçoivent un jeton d’accès doivent procéder pour le valider, que ce soit localement ou en s’adressant à point d’entrée dédié à sa validation. Cette problématique est exposée ici dans sa généralité : Validation du jeton d’accès par une ressource protégée.

OAuth 2.0 Server PHP offre un contrôleur pour la vérification de la validité du jeton d’accès.

Avec OAuth Server by DnC, les serveurs de ressource (Resource API) peuvent accéder au point d’extrémité "resource" pour valider le jeton d’accès reçu et obtenir des informations complémentaires.

Des données de profil utilisateur sont transmises avec la réponse, ce qui nous rapproche d’un protocole d’authentification tel que OpenID Connect.

OAuth Server by DnC offre également le point d’extrémité suivant :

Point d’extrémité d’introspection (Introspection Endpoint)
https://oa.dnc.global/oauth/introspect.php
Le document RFC 7662 : OAuth 2.0 Token Introspection propose une méthode identique dans le principe et très proche dans la réalisation. Les données retournées sont au format JSON et se rapprochent du contenu d’un JSON Web Token (JWT).

Point d’extrémité de révocation (Revocation Endpoint)

OAuth Server by DnC expose le point de terminaison ’revoke’ pour la révocation d’un jeton :
https://oa.dnc.global/oauth/revoke.php
Usage : Révoquer un jeton.

Notes

[1Aussi connu sous le nom de Resource Owner Endpoint

Validation du jeton d’accès par une ressource protégée

, par DnC

Un serveur de ressource protégé (RS) et, plus généralement, une application tierce, sont distincts de l’application cliente et du serveur d’autorisation (AS).

Il s’agit de définir comment un RS valide le jeton d’accès qui accompagne une requête de la part de l’application cliente.

Position du problème

Nous sommes ici au cœur du problème !

La norme OAuth 2.0 n’indique pas comment les serveurs de ressources (RS) qui reçoivent un jeton d’accès doivent procéder pour le valider.

La spécification OAuth 2.0, RFC6749, aborde cette question dans la section 7 : "Les méthodes utilisées par le serveur de ressource pour valider le jeton d’accès (ainsi que toute réponse d’erreur) dépassent le cadre de cette spécification, mais impliquent généralement une interaction ou une coordination entre le serveur de ressources et le serveur d’autorisation".

Justin Richer traite magistralement ce sujet dans cet article : In OAuth 2.0, how do resource servers assert a token issued by an authorization server ? et se trouve à l’origine de ce document : RFC 7662 : OAuth 2.0 Token Introspection.

Eran Hammer, qui a activement contribué à l’élaboration de la norme, expose ce qui suit : OAuth v2 communication between authentication and resource server.

Deux cas se présentent :

1. Le serveur de ressource (RS) et le serveur d’autorisation (AS) sont colocalisés, ou communiquent par un canal sûr, comme un tunnel SSH. Dans tous les cas, ils appartiennent tous deux à une même organisation.

Le RS peut donc accéder aux informations nécessaires (comme la clé publique d’une paire publique/privée) pour décoder la signature.

La plupart des articles traitant de ce sujet s’appuient sur ce cas de figure pour sauter à pieds joint sur la technique de validation de la signature. Nous estimons que ce cas est trivial : si le RS communique de façon sûre avec l’AS, alors il n’est nullement besoin d’un serveur d’authentification.

2. Le serveur de ressource (RS) n’est pas directement lié au serveur d’autorisation (AS).

Dans ce cas, il existe deux familles de méthodes :
- la première consiste à authentifier le jeton d’accès par interrogation du serveur d’autorisation (introspection).
- la deuxième consiste à ce que l’application tierce assure localement l’authentification du jeton d’accès.

Ceci est développé dans ce qui suit :

Authentification du jeton d’accès par interrogation du serveur d’autorisation (introspection)

Cette méthode présente un avantage important : elle permet de savoir si le jeton a été révoqué avant la fin de sa période de validité.

Elle a cependant l’inconvénient d’augmenter le trafic avec le SA, ce qui peut être minimisé par une mise en cache des réponses du côté du RS.

OAuth Server by DnC offre deux Points d’extrémité d’introspection auquel les applications tierces peuvent s’adresser pour effectuer la validation du jeton d’accès.

Identity Server 3 et Word Perfect offrent également un point d’extrémité pour la validation du jeton d’accès.

Authentification du jeton d’accès localement à l’application tierce

Une approche un peu rapide d’OAuth peut laisser croire qu’il existe une magie permettant de valider localement un jeton d’accès sans que RS et AS ne soient aucunement liés. En fait, il faudra toujours une forme de secret partagé entre le RS et l’AS.

A ce point, il existe (encore) deux voies distinctes :

- le cryptage symétrique du jeton (parfois appelé "jeton auto-décryptable"), qui n’est qu’une forme d’obfuscation.
Nous traiterons rapidement de l’obfuscation. Cette voie peut parfois s’avérer utile pour protéger des données peu sensibles contre les curieux et les robots.
Ainsi que le dit Fabio Galloneto dans l’article intitulé "Securing Sensitive Strings" : "Pour résoudre le problème, la première stratégie qui vient à l’esprit est l’obfuscation. ... la "sécurité par l’obscurité" n’est pas la sécurité. Cela vaut la peine de souligner que par définition un système sécurisé est « un système conçu de sorte que si quelqu’un sait tout sur le fonctionnement du système, il est toujours sécurisé » (voir le principe de Kerckhoff) et que l’obfuscation n’ajoute rien à la sécurité dans ce contexte."

- la validation à l’aide de cryptage asymétrique.

La recherche de la sécurité nous amène donc à la valider le jeton localement à l’application tierce. C’est ce que permet le jeton JWT (JSON Web Token).
Plusieurs implémentations utilisent un tel jeton :

OpenID Connect

Le protocole OpenID Connect utilise un jeton d’identité (ID Token) fondé sur JWT. La norme décrit comment une application cliente doit valider un ID Token reçu en réponse à une demande d’authentification. Un tiers (le serveur de ressource protégé notamment) peut évidemment appliquer la même méthode, à condition d’accéder aux informations nécessaires. La validation est effectuée notamment à l’aide d’un cryptage asymétrique, mettant en œuvre une paire de clé publique-privée, ce qui suppose que l’application cliente accède à la clé publique.

OAuthSD offre toutes les réponses à ces questions :
- Validation du jeton JWT,
- OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo,
- OpenID Connect : Découverte.

Différentes plateformes mettent en œuvre la validation du jeton d’identité :

Identity Server

- IdentityServer3 : AccessTokenValidation

Google Identity Plateform

- Google Identity Plateform

Exchange 2013

Exchange 2013 utilise aussi un jeton JWT pour le jeton d’identité, qui est similaire à l’ID Token défini par OpenID Connect. Il est donc intéressant de consulter les documents suivants :

- Présentation du jeton d’identité Exchange

- Utilisation de PHP pour valider un jeton d’identité

Lier une application cliente au serveur OAuthSD

, par DnC

Cet article s’adresse à un développeur.

Il décrit comment adapter une application pour qu’elle devienne cliente OAuth 2.0 et comment l’inscrire sur OAuth Server byDnC.

Ceci suppose que le développeur ou son organisation soit inscrit sur le serveur en tant qu’Administrateur d’applications.

Le processus comporte deux aspects :

- du côté du serveur OAuth, inscrire l’application,
- du côté de l’application cliente, insérer le code nécessaire pour assurer le lien avec le serveur OAuth.

1. S’inscrire en tant qu’Administrateur d’applications

L’inscription se fait ici : Formulaire d’inscription.

Renseignez soigneusement votre fiche d’Administrateur d’application, la plupart de ces informations étant communiquées aux utilisateurs finaux dont vous devez gagner la confiance.

Attention : ne confondez pas l’inscription en tant qu’Administrateur d’applications (un développeur qui inscrit son application cliente pour qu’elle puisse déléguer l’authentification à OAuthSD) avec l’inscription d’un internaute en tant qu’utilisateur final des applications clientes, qui se fait ici : Je m’inscris.

Notes :
- Le terme "Administrateur d’applications" permet de distinguer le développeur ou le propriétaire d’une application cliente qui s’inscrit sur ce serveur, de l’utilisateur final, qui doit aussi s’inscrire, mais autrement. Dans le modèle de données sous-jacent, il s’agit également de l’objet éditorial de SPIP (la table Auteurs), tandis que l’utilisateur final correspond à une table distincte.

2. Inscrire l’application cliente sur le serveur OAuthSD

Dans la rubrique Gérer, aller à Ajouter (Inscrire) une application cliente et remplir le formulaire :

- Client Id (obligatoire) : Chaine identifiant l’application de façon unique. Entrez un nom court, de préférence sans espace ni caractère spécial. Cet identifiant doit être unique pour tous les auteurs du serveur. Il est visible du public et doit donc être représentatif de l’application et de votre entreprise.

- Client secret (obligatoire) : une courte chaîne assimilable à un mot de passe fort. Ce code n’apparait que dans ce dialogue et doit rester secret.

- Redirect uri (obligatoire) : URI de retour à l’application cliente. C’est l’adresse à laquelle le serveur OAuth fait retour sur le client avec le résultat de l’authentification.

- Grant Type (obligatoire) : sélectionnez un des Types d’autorisation.

- Scopes (obligatoire) : Liste des Scopes autorisés pour l’application, séparés par un espace. Dans une phase de test ou pour une application simple, si vous n’avez pas défini de scope, indiquez "basic".

- User id ID de l’utilisateur unique de l’application. Utilisé notamment pour l’autorisation serveur à serveur. Laissez vide si votre application ne nécessite pas de définition de l’UserId.

Vérifiez vos entrées et actionnez le bouton "Enregistrer".

Vous pourrez retrouver l’application et la modifier à la rubrique Toutes vos applications clientes.

Notes :
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, toute application apte à déléguer ses autorisations à un serveur compatible OAuth 2.0 peut être inscrite sans modification sur OAuth 2 Server by DnC.

3. Insérer dans l’application le code nécessaire

Si l’application cliente est conçue pour déléguer ses authentifications à un serveur à la norme OAuth 2.0, il n’y a rien de plus à faire.

Sinon, c’est une affaire de développeur. Il y a deux adaptations à réaliser :

- Écrire le code situé au Point d’extrémité de redirection, ou URI de retour à l’application cliente (Redirection Endpoint). Il s’agit de demander au serveur OAuth un jeton d’accès pour l’application, à partir du Code d’autorisation (Authorization code) retourné par le serveur. Nous en donnons un exemple ici : Exemple de code pour le Point d’extrémité de redirection.

- Consommer une API protégée de type HTTP REST est extrêmement simple. Voici un exemple avec L’API REST de Radar : Une fonction pour tout simplifier !.

Notes :
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, l’adaptation de l’application décrite ci-dessus lui permettra de déléguer ses autorisations à n’importe quel serveur compatible OAuth 2.0.