1. Introduction

OAuth permet aux clients d'accéder aux ressources protégées en obtenant un jeton d'accès (Access Token), qui est défini dans « The OAuth 2.0 Authorization Framework » [RFC6749] comme « une chaîne représentant une autorisation d'accès émise au client », plutôt qu'en utilisant directement les informations d'identification du propriétaire de la ressource.

Les jetons sont émis aux clients par un serveur d'autorisation avec l'approbation du propriétaire de la 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. Cette spécification décrit comment effectuer des requêtes de ressources protégées lorsque le jeton d'accès OAuth est un jeton porteur (Bearer Token).

Cette spécification définit l'utilisation des jetons porteur sur HTTP/1.1 [RFC2616] en utilisant Transport Layer Security (TLS) [RFC5246] pour accéder aux ressources protégées. TLS est obligatoire à implémenter et à utiliser avec cette spécification ; d'autres spécifications peuvent étendre cette spécification pour une utilisation avec d'autres protocoles. Bien que conçue pour être utilisée avec les jetons d'accès résultant des flux d'autorisation OAuth 2.0 [RFC6749] pour accéder aux ressources protégées OAuth, cette spécification définit en réalité une méthode d'autorisation HTTP générale qui peut être utilisée avec des jetons porteur de n'importe quelle source pour accéder à toutes les ressources protégées par ces jetons porteur. Le schéma d'authentification Bearer est principalement destiné à l'authentification du serveur en utilisant les en-têtes HTTP WWW-Authenticate et Authorization, mais n'exclut pas son utilisation pour l'authentification proxy.

1.1. Conventions de notation (Notational Conventions)

Les mots-clés « doit (MUST) », « ne doit pas (MUST NOT) », « requis (REQUIRED) », « doit (SHALL) », « ne doit pas (SHALL NOT) », « devrait (SHOULD) », « ne devrait pas (SHOULD NOT) », « recommandé (RECOMMENDED) », « peut (MAY) » et « optionnel (OPTIONAL) » dans ce document doivent être interprétés comme décrit dans « Key words for use in RFCs to Indicate Requirement Levels » [RFC2119].

Ce document utilise la notation Augmented Backus-Naur Form (ABNF) de [RFC5234]. De plus, les règles suivantes sont incluses de HTTP/1.1 [RFC2617] : auth-param et auth-scheme ; et de « Uniform Resource Identifier (URI): Generic Syntax » [RFC3986] : URI-reference.

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

1.2. Terminologie (Terminology)

Jeton porteur (Bearer Token) : Un jeton de sécurité avec la propriété que toute partie en possession du jeton (un « porteur ») peut utiliser le jeton de la même manière que toute autre partie en possession de celui-ci. L'utilisation d'un jeton porteur ne nécessite pas qu'un porteur prouve la possession de matériel de clé cryptographique (preuve de possession).

Tous les autres termes sont définis comme dans « The OAuth 2.0 Authorization Framework » [RFC6749].

1.3. Vue d'ensemble (Overview)

OAuth fournit une méthode pour que les clients accèdent à une ressource protégée au nom d'un propriétaire de ressource. Dans le cas général, avant qu'un client puisse accéder à une ressource protégée, il doit d'abord obtenir une autorisation du propriétaire de la ressource, puis échanger l'autorisation contre un jeton d'accès. Le jeton d'accès représente la portée, la durée et d'autres attributs accordés par l'autorisation. Le client accède à la ressource protégée en présentant le jeton d'accès au serveur de ressources. Dans certains cas, un client peut présenter directement ses propres informations d'identification à un serveur d'autorisation pour obtenir un jeton d'accès sans avoir à obtenir d'abord une autorisation d'un propriétaire de ressource.

Le jeton d'accès fournit une abstraction, remplaçant différentes constructions d'autorisation (par exemple, nom d'utilisateur et mot de passe, assertion) par un jeton unique compris par le serveur de ressources. Cette abstraction permet d'émettre des jetons d'accès valides pendant une courte période, et supprime également le besoin pour le serveur de ressources de comprendre une large gamme de schémas d'authentification.

  +--------+                               +---------------+
  |        |--(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 de protocole abstrait

Le flux OAuth 2.0 abstrait illustré à la Figure 1 décrit l'interaction entre le client, le propriétaire de la ressource, le serveur d'autorisation et le serveur de ressources (décrit dans [RFC6749]). Les deux étapes suivantes sont spécifiées dans ce document :

(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 et, s'il est valide, traite la requête.

Ce document impose également des exigences sémantiques sur le jeton d'accès renvoyé à l'étape (D).

---