i-TegoDocumentationAuthentification > OpenID Connect OAuth Serveur dédié > Développer > OAuth 2.0

Avertissement : n’hésitez pas à sauter ce chapitre et à passer directement à OpenID Connect.

OAuth 2.0 est la base sur laquelle est construit OpenID Connect.

OAuth 1.0 fournissait un jeton signé, mais la version 2.0 a supprimé cette caractéristique essentielle pour la sécurité. OpenID Connect rétablit cette fonctionnalité avec le jeton JWT. Notons que certains serveurs, sans être OIDC, avaient rétabli la signature du jeton. Il en est ainsi, par exemple, de OAuth 2.0 Server de thephpleague.com.

OAuthSD répond au standard OpenID Connect. Alors, pourquoi se référer encore aux protocoles d’OAuth 2.0 ? Ne devrait-on pas considérer qu’il s’agit d’une couche sous-jacente pour ne considérer que les flux OpenID Connect ? Ce site s’en trouverait singulièrement simplifié ! Voyez : OAuth 2.0 ou OpenID Connect ? pour en savoir plus.

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

  publié le par i-Tego WM

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

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.

[6Sous certaines conditions, notamment s’il s’agit d’une application Web. Voir : Typologie des applications au regard de la sécurité des données.

[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é

  publié le par i-Tego WM

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) :

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

Notes

[1Aussi connu sous le nom de Resource Owner Endpoint

Validation du jeton par une ressource protégée

  (publié initialement le vendredi 11 novembre 2016) par i-Tego WM

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

Notes

[1Un euphémisme pour dire "un changement catastrophique pour la sécurité du Web".

OAuth 2.0 : Lier une application cliente au serveur OAuthSD

  publié le par i-Tego WM

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