21 Mar 2016

OAuth : Comprendre l’OAuth 2.0 par l’exemple

En 2016 l’état va proposer à chacun d’entre nous de se connecter sur les sites du service public à l’aide d’outils de gestion d’identité numérique. Cette opération est baptisée France Connect.

Même si c’est un grand pas dans la gestion technologique point de vue administratif (qui n’a jamais prononcé le moindre petit juron en tentant de se connecter sur le site des impôts ?) ce n’est pas vraiment une révolution technique. Depuis un petit moment déjà on se connecte à l’aide de son compte Facebook, Google ou autre sur des sites de manière simple et sécurisée.

Toutes ces technologies ont une chose en commun : l’OAuth.

Cette technologie n’est ni un outil, ni un package, pas un plugin et encore moins un langage de programmation, c’est une spécification : la RFC 6749

Afin de vous en facilité la lecture, plus que laborieuse, je vais vous proposer ici un petit résumé simplifié. Pour plus de détails, il n’y a pas de miracle, vous trouverez les réponses dans la RFC.

Les rôles

Avant toute chose il est important de distinguer les acteurs à travers leurs rôles. Nous allons prendre un exemple simple : un site internet lambda (Endomondo pour l’exemple) sur lequel on s’identifie à l’aide de l’outil Facebook Connect.

Se connecter avec Facebook

Se connecter avec Facebook

  • Le détenteur des ressources (Resource Owner) : en général il s’agit de l’utilisateur final (vous !). C’est simplement l’entité (physique ou logicielle) qui peut procéder à l’acceptation de l’accès aux données protégées. Il passe à travers un User Agent ou plus simplement via son navigateur.
  • Le serveur de ressources (Resources Server) : serveur contenant les ressources protégées (ici Facebook)
  • Le Client : l’application voulant accéder aux données protégées (ici Endomondo)
  • Le serveur d’autorisation (Authorization Server): Serveur qui va fournir le token d’accès au client. Ce token sera ensuite fourni par le client au serveur de ressource comme ticket d’entrée pour récupérer les données protégées. Très souvent le serveur d’autorisation et le serveur de ressources ne font qu’un (ici Facebook donc)

Les tokens

Les tokens peuvent être enregistrés coté client ou coté serveur, en mémoire ou sur des cookies. Ils permettent d’accéder aux ressources protégées. Ils sont représentés par une chaîne de caractères générée par le serveur et opaque pour le client.

Le token d’accès (access token) est un laisser-passer, un peu comme un ticket de cinéma. Il permet donc au client d’accéder à une ressource spécifique pour une durée déterminée.

Le token de renouvellement (refresh token) permet de redemander au serveur d’autorisation un nouveau token d’accès. Un peu comme une carte d’abonnement qui permet de redemander un ticket de cinéma.

Les clients

Les clients ne peuvent utiliser le protocole OAuth sans être connu du serveur. Pour cela il lui faut donc s’enregistrer auprès du serveur d’autorisation. Pour cela il doit fournir un ensemble de données :

  • Nom de l’application
  • Url du site
  • Url de retour
  • Informations diverses en fonction du demandeur (logo, url javascript, description, etc.)

En échange, le serveur fournira un identifiant et un code secret (client id et client secret) sous forme de chaîne de caractère, qui permettra au client de s’identifier.

Les différents types d’autorisation

Il existe actuellement quatre type d’autorisation. Chacune possède son domaine spécifique d’utilisation.

  • Authorization Code Grant : autorisation via un code
  • Implicite Grant : autorisation implicite
  • Resource Owner Password Credentials Grant : Autorisation par mot de passe
  • Client Credentials Grant : autorisation de serveur à serveur.

Le plus sécurisé : Authorization Grant

Dans ce cas, le serveur Web stocke le code d’autorisation, et l’utilisateur final (via son navigateur Web), n’a jamais accès aux tokens. A chaque fois c’est directement le serveur client (Endomondo) qui appellera le serveur de ressources (Facebook Data).

Autorisation par code

Autorisation par code

Dans ce type d’autorisation les étapes sont les suivantes :

  1. Le client redirige l’utilisateur (via son navigateur) vers le serveur Facebook
  2. Le serveur d’autorisation Facebook identifie l’utilisateur final et lui demande son consentement
  3. Une fois l’accès validé, Facebook redirige le navigateur vers Endomondo avec le code d’autorisation
  4. Le Serveur Endomondo échange directement avec le Serveur Facebook pour récupérer les tokens
  5. Les requêtes de serveur à serveur sont sécurisées.

Pour les applications javascript : l’implicit Grant

Cette méthode est avant utilisée par les applications mobile et les applications Web. Elle est donc de plus en plus répandue. Le principe est de demander un unique token d’accès. Son petit inconvénient est qu’il expose le token qui est stocké directement sur le navigateur car utilisé par des requêtes javascript par exemple.

Autorisation implicite

Autorisation implicite

Dans ce type d’autorisation les étapes sont les suivantes :

  1. Le client redirige l’utilisateur (via son navigateur) vers le serveur Facebook
  2. Le serveur d’autorisation Facebook identifie l’utilisateur final et lui demande son consentement
  3. Une fois l’accès validé, Facebook renvoi directement un token
  4. Les requêtes javascript font appel au serveur Facebook directement depuis le navigateur de façon sécurisée avec le token d’accès

Dans un même domaine de confiance : l’autorisation via mot de passe

Cette autorisation via mot de passe est peu utilisée. Son utilisation se fait entre deux entités se faisant une confiance absolue. Pour notre exemple, ce n’est pas le cas entre le client (Endomondo) et le serveur de ressource (Facebook), nous allons donc partir du principe que Facebook a créé son propre site de gestion de suivi d’activité : SportBook. Ils sont de la même entreprise et donc se font une confiance sans faille.

Autorisation par échange de mot de passe

Autorisation par échange de mot de passe

Dans ce type d’autorisation les étapes sont les suivantes :

  1. L’utilisateur va sur Sportbook et est authentifié
  2. Le serveur Sportbook récupère directement un token auprès du serveur Facebook
  3. Les requêtes de serveur à serveur sont sécurisées.

Encore plus simplifié : l’autorisation de serveur à serveur

On est ici dans le même cas, sauf que le serveur est lui même détenteur de ressource. Peut être utilisé dans le cas d’un stockage de ressource sur le cloud par exemple. Dans ce cas, l’échange de token se fait exactement de la même façon, sauf que le client final n’entre pas dans l’équation.

  1. Le serveur client récupère directement un token auprès du serveur cloud
  2. Les requêtes de serveur à serveur sont sécurisées. Le client récupère ses fichiers.

Conclusion

Nous avons décrit ici les bases de l’OAuth, ce qui nous permettra par la suite de voir son implémentation avec Owin dans une second partie, ainsi que de son utilisation dans le cas de requêtes Javascript dans une troisième partie.

Ressources

Je vous parlais de France Connect, j’ai lu l’info sur Presse Citron, plus d’info sur le site France Connect. Un des fournisseur d’identité sera la poste avec son Identité numérique.

Plus d’informations sur l’OAuth 2 directement sur la RFC.

Les diagrammes de séquences ont été générés avec WebSequenceDiagrams.

 

 

Share