1. Introduction

Dans le modèle traditionnel d'authentification client-serveur, le client demande une ressource à accès restreint (ressource protégée) sur le serveur en s'authentifiant auprès du serveur au moyen des informations d'identification du propriétaire de ressource. Pour donner à des applications tierces l'accès à des ressources restreintes, le propriétaire de ressource partage ses informations d'identification avec le tiers. Cela crée plusieurs problèmes et limitations :

• les applications tierces doivent conserver les informations d'identification du propriétaire de ressource pour un usage ultérieur, typiquement un mot de passe en clair ;
• les serveurs doivent prendre en charge l'authentification par mot de passe, malgré les faiblesses de sécurité inhérentes aux mots de passe ;
• les applications tierces obtiennent un accès trop large aux ressources protégées du propriétaire de ressource, sans que celui-ci puisse limiter la durée ou restreindre l'accès à un sous-ensemble de ressources ;
• les propriétaires de ressource ne peuvent pas révoquer l'accès d'un tiers particulier sans révoquer l'accès de tous les tiers, et doivent le faire en changeant le mot de passe du tiers ;
• la compromission d'une application tierce compromet le mot de passe de l'utilisateur final et toutes les données protégées par ce mot de passe.

OAuth répond à ces problèmes en introduisant une couche d'autorisation et en séparant le rôle du client de celui du propriétaire de ressource. Dans OAuth, le client demande l'accès à des ressources contrôlées par le propriétaire de ressource et hébergées par le serveur de ressources, et reçoit un ensemble d'informations d'identification différent de celui du propriétaire de ressource.

Au lieu d'utiliser les informations d'identification du propriétaire de ressource pour accéder aux ressources protégées, le client obtient un jeton d'accès -- une chaîne indiquant une portée, une durée de vie et d'autres attributs d'accès particuliers. Les jetons d'accès sont émis aux clients tiers par un serveur d'autorisation avec l'approbation du propriétaire de ressource. Le client utilise le jeton d'accès pour accéder aux ressources protégées hébergées par le serveur de ressources.

Par exemple, une utilisatrice finale (propriétaire de ressource) peut accorder à un service d'impression (client) l'accès à ses photos protégées stockées chez un service de partage de photos (serveur de ressources), sans partager son nom d'utilisateur ni son mot de passe avec le service d'impression. Elle s'authentifie directement auprès d'un serveur approuvé par le service de partage de photos (serveur d'autorisation), qui émet au service d'impression des informations d'identification propres à cette délégation (jeton d'accès).

Cette spécification est conçue pour être utilisée avec HTTP ([RFC2616]). L'utilisation d'OAuth sur tout protocole autre que HTTP sort du périmètre de cette spécification.

Le protocole OAuth 1.0 ([RFC5849]), publié comme document d'information, résultait d'un petit effort communautaire ad hoc. La présente spécification sur la voie des standards s'appuie sur l'expérience de déploiement d'OAuth 1.0, ainsi que sur des cas d'utilisation et des exigences d'extensibilité supplémentaires recueillis auprès de la communauté IETF plus large. Le protocole OAuth 2.0 n'est pas rétrocompatible avec OAuth 1.0. Les deux versions peuvent coexister sur le réseau, et les implémentations peuvent choisir de prendre en charge les deux. Toutefois, l'intention de cette spécification est que les nouvelles implémentations prennent en charge OAuth 2.0 tel qu'il est spécifié dans ce document, et qu'OAuth 1.0 ne soit utilisé que pour prendre en charge les déploiements existants. OAuth 2.0 partage très peu de détails d'implémentation avec OAuth 1.0. Les implémenteurs familiers d'OAuth 1.0 devraient aborder ce document sans présumer de sa structure ni de ses détails.

1.1. Rôles

OAuth définit quatre rôles :

propriétaire de ressource
Entité capable d'accorder l'accès à une ressource protégée. Lorsque le propriétaire de ressource est une personne, il est appelé utilisateur final.

serveur de ressources
Serveur qui héberge les ressources protégées et qui peut accepter des demandes de ressources protégées utilisant des jetons d'accès et y répondre.

client
Application qui effectue des demandes de ressources protégées au nom du propriétaire de ressource et avec son autorisation. Le terme « client » n'implique aucune caractéristique d'implémentation particulière, par exemple le fait que l'application s'exécute sur un serveur, un ordinateur de bureau ou d'autres appareils.

serveur d'autorisation
Serveur qui émet des jetons d'accès au client après avoir authentifié avec succès le propriétaire de ressource et obtenu l'autorisation.

L'interaction entre le serveur d'autorisation et le serveur de ressources sort du périmètre de cette spécification. Le serveur d'autorisation peut être le même serveur que le serveur de ressources, ou une entité distincte. Un seul serveur d'autorisation peut émettre des jetons d'accès acceptés par plusieurs serveurs de ressources.

1.2. Flux du protocole

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Figure 1 : Flux abstrait du protocole

Le flux abstrait OAuth 2.0 illustré à la Figure 1 décrit l'interaction entre les quatre rôles et comprend les étapes suivantes :

(A) Le client demande une autorisation au propriétaire de ressource. La demande d'autorisation peut être faite directement au propriétaire de ressource, comme illustré, ou de préférence indirectement via le serveur d'autorisation agissant comme intermédiaire.

(B) Le client reçoit une autorisation, c'est-à-dire une information d'identification représentant l'autorisation du propriétaire de ressource, exprimée au moyen de l'un des quatre types d'autorisation définis dans cette spécification ou d'un type d'autorisation d'extension. Le type d'autorisation dépend de la méthode utilisée par le client pour demander l'autorisation et des types pris en charge par le serveur d'autorisation.

(C) Le client demande un jeton d'accès en s'authentifiant auprès du serveur d'autorisation et en présentant l'autorisation.

(D) Le serveur d'autorisation authentifie le client et valide l'autorisation ; si elle est valide, il émet un jeton d'accès.

(E) Le client demande la ressource protégée au serveur de ressources et s'authentifie en présentant le jeton d'accès.

(F) Le serveur de ressources valide le jeton d'accès ; s'il est valide, il sert la demande.

La méthode préférée pour que le client obtienne une autorisation du propriétaire de ressource (étapes (A) et (B)) consiste à utiliser le serveur d'autorisation comme intermédiaire, comme l'illustre la Figure 3 de la Section 4.1.

1.3. Autorisation

Une autorisation est une information d'identification représentant l'autorisation du propriétaire de ressource, utilisée par le client pour obtenir un jeton d'accès. Cette spécification définit quatre types d'autorisation -- code d'autorisation, implicite, informations d'identification par mot de passe du propriétaire de ressource et informations d'identification du client -- ainsi qu'un mécanisme d'extensibilité pour définir des types supplémentaires.

1.3.1. Code d'autorisation

Le code d'autorisation est obtenu en utilisant un serveur d'autorisation comme intermédiaire entre le client et le propriétaire de ressource. Au lieu de demander l'autorisation directement au propriétaire de ressource, le client oriente le propriétaire de ressource vers un serveur d'autorisation via son agent utilisateur, comme défini dans [RFC2616], lequel renvoie ensuite le propriétaire de ressource vers le client avec le code d'autorisation.

Avant de renvoyer le propriétaire de ressource vers le client avec le code d'autorisation, le serveur d'autorisation authentifie le propriétaire de ressource et obtient l'autorisation. Comme le propriétaire de ressource ne s'authentifie qu'auprès du serveur d'autorisation, ses informations d'identification ne sont jamais partagées avec le client.

Le code d'autorisation procure quelques avantages de sécurité importants, notamment la possibilité d'authentifier le client, ainsi que la transmission du jeton d'accès directement au client sans le faire passer par l'agent utilisateur du propriétaire de ressource et sans l'exposer potentiellement à d'autres parties, y compris le propriétaire de ressource.

1.3.2. Implicite

L'autorisation implicite est un flux de code d'autorisation simplifié, optimisé pour les clients implémentés dans un navigateur au moyen d'un langage de script tel que JavaScript. Dans le flux implicite, au lieu de recevoir un code d'autorisation, le client reçoit directement un jeton d'accès à la suite de l'autorisation du propriétaire de ressource. Le type est dit implicite car aucune information d'identification intermédiaire, telle qu'un code d'autorisation, n'est émise puis utilisée pour obtenir un jeton d'accès.

Lorsqu'il émet un jeton d'accès dans le flux implicite, le serveur d'autorisation n'authentifie pas le client. Dans certains cas, l'identité du client peut être vérifiée au moyen de l'URI de redirection utilisée pour remettre le jeton d'accès au client. Le jeton d'accès peut être exposé au propriétaire de ressource ou à d'autres applications ayant accès à l'agent utilisateur du propriétaire de ressource.

Les autorisations implicites améliorent la réactivité et l'efficacité de certains clients, par exemple un client implémenté comme application dans le navigateur, car elles réduisent le nombre d'allers-retours nécessaires pour obtenir un jeton d'accès. Toutefois, cette commodité doit être mise en balance avec les implications de sécurité des autorisations implicites, telles que celles décrites dans les Sections 10.3 et 10.16, en particulier lorsque le type d'autorisation par code d'autorisation est disponible.

1.3.3. Informations d'identification par mot de passe du propriétaire de ressource

Les informations d'identification par mot de passe du propriétaire de ressource, c'est-à-dire le nom d'utilisateur et le mot de passe, peuvent être utilisées directement comme autorisation pour obtenir un jeton d'accès. Elles ne devraient être utilisées que lorsqu'il existe un degré élevé de confiance entre le propriétaire de ressource et le client, par exemple lorsque le client fait partie du système d'exploitation de l'appareil ou est une application à privilèges élevés, et lorsque d'autres types d'autorisation ne sont pas disponibles, comme un code d'autorisation.

Même si ce type d'autorisation exige que le client accède directement aux informations d'identification du propriétaire de ressource, celles-ci sont utilisées pour une seule demande et échangées contre un jeton d'accès. Ce type d'autorisation peut éviter au client de stocker les informations d'identification du propriétaire de ressource pour une utilisation future, en les échangeant contre un jeton d'accès de longue durée ou un jeton de rafraîchissement.

1.3.4. Informations d'identification du client

Les informations d'identification du client, ou d'autres formes d'authentification du client, peuvent être utilisées comme autorisation lorsque la portée de l'autorisation est limitée aux ressources protégées sous le contrôle du client, ou à des ressources protégées préalablement convenues avec le serveur d'autorisation. Les informations d'identification du client sont typiquement utilisées comme autorisation lorsque le client agit pour son propre compte, c'est-à-dire qu'il est aussi le propriétaire de ressource, ou lorsqu'il demande l'accès à des ressources protégées sur la base d'une autorisation préalablement convenue avec le serveur d'autorisation.

1.4. Jeton d'accès

Les jetons d'accès sont des informations d'identification utilisées pour accéder aux ressources protégées. Un jeton d'accès est une chaîne représentant une autorisation émise au client. La chaîne est généralement opaque pour le client. Les jetons représentent des portées et des durées d'accès particulières, accordées par le propriétaire de ressource et appliquées par le serveur de ressources et le serveur d'autorisation.

Le jeton peut désigner un identifiant utilisé pour récupérer les informations d'autorisation, ou il peut contenir lui-même les informations d'autorisation d'une manière vérifiable, par exemple une chaîne composée de données et d'une signature. Des informations d'authentification supplémentaires, hors du périmètre de cette spécification, peuvent être requises pour que le client utilise un jeton.

Le jeton d'accès fournit une couche d'abstraction, remplaçant différentes constructions d'autorisation, par exemple nom d'utilisateur et mot de passe, par un jeton unique compris par le serveur de ressources. Cette abstraction permet d'émettre des jetons d'accès plus restrictifs que l'autorisation utilisée pour les obtenir, et évite au serveur de ressources de devoir comprendre une grande variété de méthodes d'authentification.

Les jetons d'accès peuvent avoir différents formats, structures et méthodes d'utilisation, par exemple des propriétés cryptographiques, selon les exigences de sécurité du serveur de ressources. Les attributs des jetons d'accès et les méthodes utilisées pour accéder aux ressources protégées sortent du périmètre de cette spécification et sont définis par des spécifications complémentaires telles que [RFC6750].

1.5. Jeton de rafraîchissement

Les jetons de rafraîchissement sont des informations d'identification utilisées pour obtenir des jetons d'accès. Ils sont émis au client par le serveur d'autorisation et servent à obtenir un nouveau jeton d'accès lorsque le jeton d'accès courant devient invalide ou expire, ou à obtenir des jetons d'accès supplémentaires de portée identique ou plus étroite. Les jetons d'accès peuvent avoir une durée de vie plus courte et moins de permissions que celles autorisées par le propriétaire de ressource. L'émission d'un jeton de rafraîchissement est facultative et relève de la discrétion du serveur d'autorisation. Si le serveur d'autorisation émet un jeton de rafraîchissement, il l'inclut lors de l'émission du jeton d'accès, c'est-à-dire à l'étape (D) de la Figure 1.

Un jeton de rafraîchissement est une chaîne représentant l'autorisation accordée au client par le propriétaire de ressource. La chaîne est généralement opaque pour le client. Le jeton désigne un identifiant utilisé pour récupérer les informations d'autorisation. Contrairement aux jetons d'accès, les jetons de rafraîchissement sont destinés à être utilisés uniquement avec les serveurs d'autorisation et ne sont jamais envoyés aux serveurs de ressources.

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

Figure 2 : Rafraîchissement d'un jeton d'accès expiré

Le flux illustré à la Figure 2 comprend les étapes suivantes :

(A) Le client demande un jeton d'accès en s'authentifiant auprès du serveur d'autorisation et en présentant une autorisation.

(B) Le serveur d'autorisation authentifie le client et valide l'autorisation ; si elle est valide, il émet un jeton d'accès et un jeton de rafraîchissement.

(C) Le client effectue une demande de ressource protégée auprès du serveur de ressources en présentant le jeton d'accès.

(D) Le serveur de ressources valide le jeton d'accès ; s'il est valide, il sert la demande.

(E) Les étapes (C) et (D) se répètent jusqu'à l'expiration du jeton d'accès. Si le client sait que le jeton d'accès a expiré, il passe à l'étape (G) ; sinon, il effectue une autre demande de ressource protégée.

(F) Comme le jeton d'accès est invalide, le serveur de ressources renvoie une erreur de jeton invalide.

(G) Le client demande un nouveau jeton d'accès en s'authentifiant auprès du serveur d'autorisation et en présentant le jeton de rafraîchissement. Les exigences d'authentification du client dépendent du type de client et des politiques du serveur d'autorisation.

(H) Le serveur d'autorisation authentifie le client et valide le jeton de rafraîchissement ; s'il est valide, il émet un nouveau jeton d'accès et, éventuellement, un nouveau jeton de rafraîchissement.

Les étapes (C), (D), (E) et (F) sortent du périmètre de cette spécification, comme décrit à la Section 7.

1.6. Version de TLS

Chaque fois que cette spécification utilise Transport Layer Security (TLS), la ou les versions appropriées de TLS varient au fil du temps, selon le déploiement répandu et les vulnérabilités de sécurité connues. Au moment de la rédaction, TLS version 1.2 [RFC5246] est la version la plus récente, mais sa base de déploiement est très limitée et elle peut ne pas être facilement disponible pour les implémentations. TLS version 1.0 [RFC2246] est la version la plus largement déployée et fournit la meilleure interopérabilité.

Les implémentations peuvent également prendre en charge d'autres mécanismes de sécurité de la couche transport qui satisfont à leurs exigences de sécurité.

1.7. Redirections HTTP

Cette spécification utilise largement les redirections HTTP, dans lesquelles le client ou le serveur d'autorisation dirige l'agent utilisateur du propriétaire de ressource vers une autre destination. Bien que les exemples de cette spécification montrent l'utilisation du code d'état HTTP 302, toute autre méthode disponible via l'agent utilisateur pour accomplir cette redirection est autorisée et considérée comme un détail d'implémentation.

1.8. Interopérabilité

OAuth 2.0 fournit un cadre d'autorisation riche avec des propriétés de sécurité bien définies. Toutefois, en tant que cadre riche et très extensible comportant de nombreux composants facultatifs, cette spécification seule est susceptible de produire un large éventail d'implémentations non interopérables.

De plus, cette spécification laisse quelques composants requis partiellement ou entièrement non définis, par exemple l'enregistrement des clients, les capacités du serveur d'autorisation et la découverte des points de terminaison. Sans ces composants, les clients doivent être configurés manuellement et spécifiquement pour un serveur d'autorisation et un serveur de ressources donnés afin d'interopérer.

Ce cadre a été conçu avec l'attente claire que des travaux futurs définiront les profils prescriptifs et les extensions nécessaires pour obtenir une interopérabilité complète à l'échelle du Web.

1.9. Conventions notationnelles

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans cette spécification doivent être interprétés comme décrit dans [RFC2119].

Cette spécification utilise la notation Augmented Backus-Naur Form (ABNF) de [RFC5234]. De plus, la règle URI-reference est incluse depuis "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986].

Certains termes liés à la sécurité doivent être compris au sens défini dans [RFC4949]. Ces termes comprennent notamment, sans s'y limiter, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate" et "verify".

Sauf indication contraire, tous les noms et valeurs de paramètres du protocole sont sensibles à la casse.