OAuth : Comment ça marche ?

connexion_RS

Vous avez sûrement remarqué que certains sites nous proposent de nous authentifier à partir de nos comptes Facebook ou Twitter ou encore Google + et ainsi récupérer les informations de notre  profil. En tant qu’utilisateur cela est bien pratique, mais savez-vous ce qui se passe dans les coulisses ?

Cette fonctionnalité est rendue possible grâce à une API sécurisée proposée par Facebook, Twitter, Google+. Ces derniers proposent également plusieurs API permettant de faire un peu de tout avec votre compte. En ayant connaissance de cette information, il est donc possible que le site sur lequel vous vous connectez puisse tout faire avec votre compte. Avez-vous intérêt à vous y connecter, à lui fournir vos identifiants de connexion ?

Pour pallier ces craintes, la solution est de mettre en place un mécanisme de délégation d’autorisation entre les différentes entités. OAuth a été crée dans ce sens.

Qu’est-ce que OAuth ?

OAuth 2.0

OAuth est un protocole libre qui permet d'autoriser une application client à utiliser l'API sécurisée d'une autre application pour le compte d'un utilisateur.

L'intérêt majeur d'OAuth vient du fait que l'utilisateur n'a plus besoin de fournir ses informations d’identification à une application tierce car la connexion se passe sur l’application de l'API. Cela suppose que l'utilisateur lui a à priori fait confiance.

Actuellement, OAuth est à la version 2.0. Voyons ensembles les notions de base de l’OAuth.

Les rôles

OAuth propose 4 rôles :

  • Ressource Owner (Le détenteur des données)

Il s’agit d’une entité capable d’accorder l’accès à une ressource protégée. Lorsque le propriétaire de la ressource est une personne, il est désigné en tant qu’utilisateur final.

  • Ressource Server (Le serveur de ressources)

Il s’agit d’un serveur qui héberge les ressources protégées, qui est capable d'accepter et de répondre aux demandes de ressources protégées en utilisant des jetons d'accès (Access Token).

  • Client (Le client)

Il s’agit d’une application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Cela peut-être une application PHP côté serveur,  une application JavaScript côté client, une application mobile.

  • Authorization Server (Le serveur d’autorisation)

Il s’agit d’un serveur qui délivre des jetons d'accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part.

Ci-dessous un résumé des flux du protocole OAuth :

Résumé des flux du protocole OAuth 2.0Résumé des flux du protocole OAuth 2.0

 

Le token

Le token est une chaîne de caractères, il est émit par le serveur d’autorisation à la demande du client. Le serveur d’autorisation définit sa durée de vie et les valeurs des autres paramètres.

  • Access token (jeton d'accès)

Le jeton d’accès permet au client d’accéder aux ressources protégées d’un utilisateur sur le serveur de ressources. A chacune des requêtes du client vers le serveur de ressources, le token est envoyé soit en paramètre soit dans un header de la requête. Il doit rester confidentiel dès que possible.

Refresh token (jeton de renouvellement)

Le jeton de renouvellement est un token pour renouveler le jeton d’accès lorsque ce dernier est expiré. Le client envoie le jeton de renouvellement au serveur d’autorisation pour obtenir un nouveau jeton d’accès. Le jeton de renouvellement est délivré en même temps que le jeton d’accès, cependant il n’est pas envoyé à chaque requête du client.

Les scopes

Le scope est un paramètre qui définit la portée des droits de la demande d’autorisation. La liste des scopes est définie au niveau du serveur d’autorisation.

Le client doit préciser le ou les scopes qu’il souhaite utiliser lors de la demande d’autorisation.

HTTPS

OAuth impose l’utilisation de HTTPS pour les échanges entre le client et le serveur d’autorisation du fait des données sensibles qui transitent entre les deux (jeton d’accès, éventuellement des identifiants et des mots de passe).

HTTP est un protocole de communication client-serveur développé pour le World Wide Web.

HTTPS n’est autre que la combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS.

Les types de Client

OAuth a défini deux types de client, basés sur leur capacité à s’authentifier en toute sécurité sur le serveur d’autorisation.

Confidentiel (Confidential)

Il s’agit d’un client qui a la capacité de maintenir la confidentialité de ses informations d'identification ou de sécuriser l'authentification client à l'aide d'autres moyens.

Public (Public)

Il s’agit d’un client qui a les aptitudes inverses d’un client confidentiel.

Les différents profils de client

OAuth a défini trois profils client :

Application web (Web application)

Une application Web est un client de type confidentiel qui fonctionne sur un serveur web.

La ressource protégée du propriétaire est accessible par le client via une interface utilisateur en HTML rendu par un user-agent (par exemple, navigateur Web) d’un dispositif utilisé par le propriétaire de la  ressource.

Les informations d'identification du client ainsi que le jeton d’accès émis au client sont stockés sur le serveur web et sont non exposés ou non accessibles par le propriétaire de la ressource.

Application basée sur un user-agent (User-agent-based application)

Une application basée sur un user-agent est un client de type public dans lequel le code client est téléchargé à partir d'un serveur Web et exécuté sur un user-agent (par exemple, navigateur Web) d’un dispositif utilisé par le propriétaire de la  ressource.

Les données du protocole et les informations d'identification sont facilement accessibles (et souvent visibles) pour le propriétaire de la ressource.

Application native (Native application)

Une application native est un client de type public installé et exécuté sur un dispositif utilisé par propriétaire de la ressource.

Les données du protocole et les informations d'identification sont facilement accessibles (et souvent visible) au propriétaire de la ressource. Cela suppose que les informations d'identification inclues dans l’application peuvent être extraites.

Enregistrement du client

Avant d’utiliser le protocole OAuth, il faut que le client s’enregistre auprès du serveur d’autorisation.

Le protocole a défini des paramètres qui doivent être renseignés par le client :

  • Spécifier le type de client
  • Fournir les URL de redirection du client
  • Fournir d’autres informations requises par le serveur d’autorisation

Exemple :

  • Application Name: le nom de l’application
  • Redirect URLs: les URLs du client vers lesquelles les redirections (contenant le code d’autorisation et le token d’accès) seront effectuées par le serveur d’autorisation
  • Grant Type(s): les types d’autorisation qui seront utilisées par le client
  • Javascript Origin (optionnel): le nom de domaine qui sera autorisé à effectuer des requêtes XMLHttpRequest vers le serveur de ressource

En retour de l’enregistrement du client, le serveur d’autorisation renvoie les paramètres suivants :

  • Client Id: chaîne de caractères unique et générée aléatoirement
  • Client Secret: clé secrète qui doit le rester en toute circonstance

Les types d’autorisation

Pour demander un jeton d'accès, le client doit obtenir une autorisation du propriétaire de la ressource.

OAuth a défini quatre types d’autorisation : Authorization Code Grant, Implicit Grant, Resource Owner Password Credentials Grant, Client Credentials Grant

L’autorisation via un code (Authorization Code Grant)

L’autorisation via un code est utilisée pour obtenir en même temps un jeton d’accès et un jeton de renouvellement ce qui permet d’obtenir un jeton d’accès de longue durée. Il est optimisé pour un client de type Confidentiel.

Ses avantages sont :

  • le jeton d’accès n’est pas visible par le propriétaire de la ressource
  • le jeton d’accès n’est pas exposé côté client
L’autorisation via un code Diagramme de séquence - L’autorisation via un code

Exemple :

  • Détenteur des données (Resource Owner) : vous
  • Serveur de ressources (Resource Server) : un serveur Facebook
  • Client (Client Application) : un site internet quelconque
  • Serveur d’autorisation (Authorization Server) : un serveur Facebook

Scénario :

  1. Le client souhaite accéder aux informations de votre profil Facebook.
  2. Vous êtes redirigé par le client vers le serveur d’autorisation.
  3. Si vous autorisez l’accès, le serveur d’autorisation envoie un code d’autorisation au client.
  4. Ce code est échangé par un token d’accès de façon transparente pour vous.
  5. Le client peut donc maintenant utiliser ce token d’accès pour accéder aux données de votre profil par le serveur de ressources.

 

L’autorisation implicite (Implicit Grant)

L’autorisation implicite est utilisée pour obtenir seulement un jeton d’accès. Il ne permet pas d’obtenir le jeton de renouvellement. Il est optimisé pour un client de type public qui est généralement mis en œuvre dans un navigateur en utilisant un langage de script.

L’inconvénient :

  • Il expose le jeton d’accès côté client
L’autorisation implicite Diagramme de séquence - L’autorisation implicite

Exemple :

  • Détenteur des données (Resource Owner) : vous
  • Serveur de ressources (Resource Server) : un serveur Facebook
  • Client (Client Application) : un site internet utilisant AngularJS par exemple
  • Serveur d’autorisation (Authorization Server) : un serveur Facebook

Scénario :

  1. Le client souhaite accéder aux informations de votre profil Facebook.
  2. Vous êtes redirigé par le navigateur web vers le serveur d’autorisation.
  3. Si vous autorisez l’accès, le serveur d’autorisation vous redirige sur le client et met à disposition le token d’accès dans le fragment de l’url (non envoyé au serveur web). Exemple de callback : http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
  4. Ce token d’accès peut maintenant être utilisé (après avoir été validé) pour faire des appels à l’API Facebook via Javascript (par exemple https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN).

L’autorisation via mot de passe (Resource Owner Password Credentials Grant)

L’autorisation via mot de passe est utilisée dans le cas où le propriétaire de la ressource a une relation de confiance avec le client. En effet, les informations d’identification du propriétaire de ressource sont envoyées au client.

Elle est utilisée pour obtenir en même temps un jeton d’accès et un jeton de renouvellement en échange des informations d’identification auprès du serveur d’autorisation.

L’autorisation via mot de passeDiagramme de séquence - L'autorisation via mot de passe

Exemple :

  • Détenteur des données (Resource Owner) : vous ayant un compte sur le site acme.com de la société Acme
  • Serveur de ressources (Resource Server) : la société Acme exposant son API à api.acme.com
  • Client (Client Application) : le site internet acme.com de la société Acme
  • Serveur d’autorisation (Authorization Server) : un serveur de la société Acme

Scénario :

  1. La société Acme fait les choses bien et a pensé à mettre à disposition à des applications tierces une API RESTful exposant tout plein de méthodes pratiques pour récupérer des données diverses et variées de ses utilisateurs.
  2. Cette société se dit qu’il serait pratique d’utiliser sa propre API pour éviter de réinventer la roue et de maintenir du code à plusieurs endroits.
  3. Elle a donc besoin d’un token d’accès pour appeler les méthodes de son API.
  4. Pour cela elle vous demande de renseigner vos identifiants de connexion via un formulaire HTML classique tel que vous le faites habituellement.
  5. L’application côté serveur (le site acme.com) va échanger vos identifiants contre un token d’accès auprès du serveur d’autorisation (si vos identifiants sont valides bien évidemment).
  6. L’application peut donc maintenant utiliser ce token d’accès auprès du serveur de ressources (api.acme.com).

 

L’autorisation serveur à serveur (Client Credentials Grant)

L’autorisation serveur à serveur est utilisée dans le cas où le client est lui-même détenteur de données. Il n’y a pas d’autorisation à obtenir de la part de l’utilisateur final.

Le client peut demander un jeton d'accès en utilisant uniquement ses informations d'identification client lorsqu’il a demandé l'accès à des ressources protégées sous son contrôle.

L’autorisation serveur à serveurDiagramme de séquence - L'autorisation serveur à serveur

Exemple :

  • Détenteur des données (Resource Owner) : un site internet quelconque
  • Serveur de ressources (Resource Server) : Google Cloud Storage
  • Client (Client Application) : le détenteur des données
  • Serveur d’autorisation (Authorization Server) : un serveur Google

Scénario :

  1. Un site internet quelconque stocke des fichiers de toute sorte sur Google Cloud Storage.
  2. Le site internet doit passer par l’API Google pour récupérer ou modifier des fichiers et doit donc s’authentifier auprès du serveur d’autorisation.
  3. Une fois authentifié, le site internet obtient un token d’accès qu’il peut désormais utiliser auprès du serveur de ressources .

 

Conclusion

Nous avons vu les notions de base du protocole OAuth 2.0 . OAuth 2.0 est devenu un standard pour la délégation d’autorisation entre différentes applications. Les grands firmes l’ont adopté et pourquoi pas vous ?
Enfin une dernière chose, si vous souhaitez utiliser ce protocole dans vos applications, il faut veiller scrupuleusement à la sécurité. Le protocole propose des solutions plus ou moins facile à mettre en œuvre.

Ressources Web

OAuth 2.0 : http://oauth.net/2/ , http://tools.ietf.org/html/rfc6749
Sécurités OAuth 2.0 : http://tools.ietf.org/html/rfc6819

 

7 commentaires

  1. Merci pour cet article. C’est bien utile pour pouvoir comprendre comment utiliser au mieux les différentes API proposées par les gros, même si c’est pas si simple.

  2. Salut, merci pour cet excellent article.
    Il me semble qu’il y a une inversion entre les diagrammes

    L’autorisation via mot de passe (Resource Owner Password Credentials Grant)
    L’autorisation serveur à serveur (Client Credentials Grant)

    Pour garantir la confidentialité, il faut que la requête entre le resource owner et l’authentification server soit sécurisée il faut qu’elle soit en https de bout en bout or, si le resource owner poste sont login/password sur le client dont le formulaire ne serait pas en https, et que ce soit le serveur client qui demande le jeton (là en https) le mot de passe sera transmis en clair dans la première trame sans que le serveur d’authentification puisse en être informé.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *