OAuth 2.0

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.

Note : Les points d’extrémité du protocole OpenID Connect sont traités ici : API 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) :

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 : OAuth 2.0 : 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 (actualiser) 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 point d’extrémité "resource"

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 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.

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). OAuthSD adapte également cette spécification à l’introspection (vérification) de l’ID Token fourni par OpenID Connect.

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.

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 joints 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 des Points d’extrémité d’introspection pour OAuthSD et OpenID Connect auxquels 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 par le serveur de ressource (RS)

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 ( la très mauvaise et la bonne ) :

 le cryptage symétrique du jeton (parfois appelé "jeton auto-décryptable"), qui n’est qu’une forme d’obfuscation si l’on considère la faible durée de vie d’un cryptage symétrique et la difficulté de partager la clé sans la compromettre.
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 (signature).

C’est encore Eran Hammer qui démontre la nécessité de signer les jetons pour authentifier : OAuth 2.0 (sans signature) est mauvais pour le Web :

"OAuth 2.0 supprime les signatures et la cryptographie en faveur des jetons portés, semblables aux cookies. En tant qu’éditeur d’OAuth 2.0, je suis associé au protocole OAuth 2.0 plus que la plupart des autres, et l’hypothèse est que je suis d’accord avec les décisions et les orientations prises par le protocole. Bien que le fait d’être éditeur donne un certain degré de contrôle temporaire sur la spécification, les décisions sont finalement prises par le groupe dans son ensemble (comme il se doit).
Et dans son ensemble, la communauté OAuth a commis une grave erreur (ndlr : en supprimant la signature des jetons) quant à l’orientation future du protocole. Une erreur qui fera d’OAuth 2.0 un agent de changement beaucoup moins important [1] sur le Web."

La recherche de la sécurité nous amène donc à faire valider le jeton (localement ou par introspection) par l’application tierce. C’est ce que permet la signature du 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, signé cryptographiquement (JWS). 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’une signature faisant appel à 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 d’identité ID Token (JWT signé ou JWS),
 OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo,
 API OpenID Connect : Découverte.
Vérifier le jeton est une chose. Il est tout aussi important de vérifier que l’application qui le présente le détient légitimement (il peut s’agir d’un jeton volé), voyez :
 Vérification de l’origine de la requête reçue par un serveur de ressource.

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é

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, sans espace ni caractère spécial autre que ’_’. Cet identifiant doit être unique pour tous les administrateurs d’applications inscrits sur le 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.

Enfin, naviguez à l’adresse https://oa.dnc.global/keys afin de créer l’entrée correspondant à la nouvelle paire de clés publique/privée.

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

Notes :
 OAuthSD crée pour l’application cliente une paire de clés publique/privée. Si vous souhaitez la changer, allez à la rubrique Toutes vos applications clientes et sélectionnez l’action "clés" correspondant à l’application.
 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.