1. Introduction
Dans le modèle traditionnel d'authentification client-serveur, le client (Client) demande une ressource protégée sur le serveur en s'authentifiant avec les informations d'identification du propriétaire de ressource (Resource Owner). Pour fournir un accès aux ressources restreintes à des applications tierces, le propriétaire de ressource doit partager ses informations d'identification avec le tiers. Cela crée plusieurs problèmes et limitations.
OAuth (OAuth) résout ces problèmes en introduisant une couche d'autorisation (Authorization Layer) et en séparant le rôle du client de celui du propriétaire de ressource. Dans OAuth, le client demande l'accès aux ressources contrôlées par le propriétaire de ressource et hébergées par le serveur de ressources (Resource Server), et reçoit un ensemble d'informations d'identification différent de celles 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 (Access Token) — une chaîne représentant une portée (Scope), une durée de vie et d'autres attributs d'accès spécifiques. Les jetons d'accès sont émis aux clients tiers par un serveur d'autorisation (Authorization Server) 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.
Cette spécification est conçue pour être utilisée avec HTTP (<RFC2616>). L'utilisation d'OAuth sur tout autre protocole que HTTP est hors de portée de cette spécification.
1.1. Rôles (Roles)
OAuth définit quatre rôles.
Propriétaire de ressource (Resource Owner)
Une 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 (End-User).
Serveur de ressources (Resource Server)
Le serveur hébergeant les ressources protégées, capable d'accepter et de répondre aux demandes de ressources protégées en utilisant des jetons d'accès.
Client
Une application effectuant 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, si l'application s'exécute sur un serveur, un ordinateur de bureau ou d'autres appareils).
Serveur d'autorisation (Authorization Server)
Le serveur émettant 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 dépasse le cadre 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 (Protocol Flow)
Le flux OAuth 2.0 abstrait illustre les interactions entre les quatre rôles et comprend les étapes suivantes.
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
(A) Le client demande l'autorisation au propriétaire de ressource.
(B) Le client reçoit une autorisation (Authorization Grant).
(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, valide l'autorisation et émet un jeton d'accès.
(E) Le client demande la ressource protégée au serveur de ressources en présentant le jeton d'accès.
(F) Le serveur de ressources valide le jeton d'accès et traite la demande si elle est valide.
1.3. Autorisation (Authorization Grant)
Une autorisation (Authorization Grant) 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 du propriétaire de ressource et informations d'identification du client) ainsi qu'un mécanisme d'extension pour définir des types supplémentaires.
1.3.1. Code d'autorisation (Authorization Code)
Le code d'autorisation (Authorization Code) est obtenu en utilisant le serveur d'autorisation comme intermédiaire entre le client et le propriétaire de ressource.
1.3.2. Implicite (Implicit)
L'autorisation implicite (Implicit Grant) est une version simplifiée du flux de code d'autorisation, optimisée pour les clients implémentés dans un navigateur en utilisant un langage de script tel que JavaScript.
1.3.3. Informations d'identification du propriétaire de ressource (Resource Owner Password Credentials)
Les informations d'identification du propriétaire de ressource (nom d'utilisateur et mot de passe) peuvent être utilisées directement comme autorisation pour obtenir un jeton d'accès.
1.3.4. Informations d'identification du client (Client Credentials)
Les informations d'identification du client (Client Credentials) 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.
1.4. Jeton d'accès (Access Token)
Un jeton d'accès (Access Token) est une information d'identification utilisée pour accéder aux ressources protégées. Il représente une chaîne caractérisant la portée, la durée de vie et d'autres attributs d'accès spécifiques autorisés par le propriétaire de ressource et appliqués par le serveur de ressources et le serveur d'autorisation.
1.5. Jeton de rafraîchissement (Refresh Token)
Un jeton de rafraîchissement (Refresh Token) est une information d'identification utilisée pour obtenir des jetons d'accès. Les jetons de rafraîchissement sont émis au client par le serveur d'autorisation et sont utilisés pour obtenir un nouveau jeton d'accès lorsque le jeton d'accès actuel devient invalide ou expire.