7 mai 2015

OAuth 2.0 - Principes et Fonctionnement


OAuth 2.0 permet de gérer l'authentification et les droits d'accès aux informations d'un utilisateur via un serveur d'autorisation.

Plus complexe qu'une authentification simple, OAuth 2.0 permet d'effectuer du Single Sing-On entre services et entre serveurs distants.

Pour bien comprendre OAuth 2.0 il faut connaître les rôles et les types de jeton suivants :

Rôles

  • Resource Owner : Le propriétaire / détenteur des ressources
    • Par exemple: l'utilisateur qui a déposé ses photos sur le serveur de ressources
  • Resource Server : Le serveur de ressources qui contient les ressources protégées appartenant au Ressource Owner
    • Par exemple: le serveur de ressources qui contient les photos d'un utilisateur que l'on peut récupérer via des requêtes HTTP REST
  • Client Application : l'application cliente qui demande les ressources au serveur de ressources
    • Par exemple: Une application Android qui souhaite récupérer les photos de l'utilisateur qui sont stockées sur le serveur de ressources
  • Authorization Server : Le serveur d'autorisation délivre le jeton d'accès (Access Token) aux ressources protégées à l'application cliente dans le cas où le Resource Owner valide cet accès
    • Par exemple: l'application Android récupère un jeton d'accès pour récupérer les images d'un utilisateur depuis le serveur de ressources

Jetons (Token)

Le jeton est une chaîne de caractères aléatoire généré par le serveur d'autorisation.

Il existe deux types de jeton :
  • Access Token : le jeton d'accès permet au client d'accéder à une partie des ressources protégées du serveur de ressources
  • Refresh Token : le jeton de renouvellement permet le renouvellement du jeton d'accès lorsque celui-ci arrive à expiration

Jeton d'accès (Access Token)

Le jeton d'accès permet au client d'accéder à une partie des ressources protégées du serveur de ressources.

Paramètre scope

Le paramètre scope du jeton d'accès contient la liste des types ressources accessibles via le jeton d'accès. Ceci permet de limiter l'accès par l'application cliente à une partie des ressources stockées sur le serveur de ressources.

Exemple de types de ressources : identifiant de l'utilisateur, adresse mail de l'utilisateur, informations du profil de l'utilisateur (nom, prénom, âge), accès à ses photos, etc.

La liste des types de ressources demandées par l'application cliente sera présentée par le serveur d'autorisation au détenteur de ressources, c'est à dire l'utilisateur, afin qu'il accepte ou non que l'application cliente ait accès à ses informations et ressources, par exemple ses photos.

Scénario de récupération et d'utilisation du jeton d'accès

  • L'application cliente reçoit le jeton d'accès de la part du serveur d'autorisation.
  • L'application cliente fournit ce jeton d'accès au serveur de ressources qui met alors à disposition la ou les ressources demandées et autorisées par le scope de ce jeton d'accès.
    • Les ressources demandées doivent être dans la liste des ressources accessibles par le paramètre scope du jeton d'accès

Contraintes du jeton d'accès

  • Le jeton d'accès a une durée de vie limitée définie par le serveur d'autorisation
  • Il doit rester confidentiel : 
    • le jeton d'accès doit être non visible du détenteur des contenus (Resource Owner)

Jeton de renouvellement (Refresh Token)

Le jeton de renouvellement sert à renouveller le jeton d'accès lorsque celui-ci est arrivé à expiration.

Le jeton de renouvellement et le jeton d'accès sont fournis en même temps à l'application cliente par le serveur d'autorisation.

Scénario de récupération et d'utilisation du jeton de rafraîchissement

  • L'application cliente reçoit le jeton d'accès et le jeton de renouvellement de la part du serveur d'autorisation
  • L'application cliente ne fournit que le jeton d'accès au serveur de ressources pour accéder aux ressources protégées
  • Lorsque le jeton d'accès arrive à expiration, l'application cliente demande un renouvellement du jeton d'accès au serveur d'autorisation
  • Le jeton d'accès est alors renouvelé et peut de nouveau être utilisé pour accéder aux ressources du serveur de ressources

Limitation du jeton de rafraîchissement

Le jeton de renouvellement n'est pas obligatoire et n'est pas toujours fourni par le serveur d'autorisation pour des raisons de sécurité.

Dans ce cas, sans jeton de renouvellement, il faut alors faire une demande auprès du serveur d'autorisation pour avoir un nouveau jeton d'accès.

Enregistrement de l'application cliente

L'application cliente doit s'enregistrer auprès du serveur d'autorisation via les paramètres suivants :
  • Application name : nom de l'application cliente
  • Redirect URLs : URLs de redirection vers une des pages de l'application cliente.
    • La redirection contient le jeton d'accès (Access Token) et le code d'autorisation
  • Grant Types : les types d'autorisation qui sont demandées par l'application cliente au détenteur de ressources (l'utilisateur) pour l'accès aux ressources
  • Javascript Origin (optionnel) : le nom de domaine autorisé lors des appels au serveur de ressources
A l'enreigstrement, l'application cliente reçoit de la part du serveur d'autorisation :
  • Client id : chaîne de caractères unique générée aléatoirement
  • Client Secret : clé secrète qui ne doit être connue que par l'application cliente

Sécurité

Protocole HTTPS

OAuth2 impose l'utilisation de HTTPS pour les échanges entre le client et le serveur d'autorisation afin de protéger les données sensibles.

Cependant, il est possible de mettre en place son propre serveur d'autorisation sans utiliser le protocole HTTPS.

Le fait de ne pas utiliser le protocole de sécurité HTTPS expose l'application a une grosse faille de sécurité.

Failles de sécurité

La documentation en anglais suivante liste les failles de sécurité de OAuth 2 : 


Modes d'autorisation

Nous allons voir les 4 modes d'autorisation supportés par OAuth 2.0 :




Mode d'autorisation n°1 - Autorisation par un code d'autorisation


Ce mode d'autorisation est adapté à une demande d'autorisation émise par une application Web auprès de l'utilisateur (Resource Owner) afin que celui-ci accepte ou non que l'application Web accède aux informations et fichiers de l'utilisateur hébergées sur le serveur de ressource.

Un code d'autorisation sera transmis par le serveur d'autorisation au navigateur Web pour que celui-ci le transmette à l'application Web. Cette dernière peut alors demander le jeton d'accès au serveur d'autorisation. Ainsi le navigateur Web ne reçoit jamais le jeton d'accès ce qui empêche un vol du jeton d'accès via le navigateur.

Les échanges s'effectuent via de nombreuses redirections HTTP qui contiennent les codes et jetons émises entre l'application Web, le serveur d'autorisation et le serveur de ressources.

C'est pourquoi il est important que ces échanges s'effectuent de manière sécurisée en HTTPS pour éviter le vol des codes d'autorisation et des jetons d'accès et de rafraîchissement.

Rôles


  • Resource Owner : L'utilisateur
  • Client Application : L'application Web
  • Authorization Server : Le serveur d'autorisation
  • Resource Server : Le serveur de ressources

Scénario



Cliquer sur l'image pour l'agrandir.

  1. L'application Web (client) envoie une redirection HTTP au navigateur Web de l'utilisateur vers la page d'authentification et d'autorisation du serveur d'autorisation.
    •  Cette redirection HTTP contient les informations suivantes :
      • response_type : a pour valeur "code". 
        • Ceci indique que le type d'autorisation s'effectue via un code d'autorisation
      • client_id : l'identifiant de l'application Web (client) auprès du serveur d'autorisation
      • scope  : les types de ressources demandées par l'application Web
      • redirect_uri : L'URL de redirection vers une des pages de l'application Web une fois que l'authentification et l'autorisation auront réussi ou non auprès du serveur d'autorisation
      • state : utilisé pour garantir la sécurité (Cross-Site Request Forgery - CSRF): il s'agit d'une chaîne de caractères générée par l'application Web qui lui permettra de savoir que la future requête de réponse du serveur d'autorisation est bien la réponse à cette requête de demande d'autorisation (cela évite les usurpations). La requête de réponse du serveur d'autorisation devra inclure cette chaîne de caractères dans le paramètre state.
  2. Le navigateur envoie la requête de redirection au serveur d'autorisation
  3. Le serveur d'autorisation renvoie la page d'authenfication et d'autorisation au navigateur
  4. Le navigateur affiche la page d'authentification et d'autorisation à l'utilisateur (Resource Owner)
  5. L'utilisateur s'authentifie et autorise ou refuse les autorisations
  6. Le navigateur transmet la réponse de l'utilisateur au serveur d'autorisation
  7. Le serveur d'autorisation renvoie une requête de redirection vers une des pages de l'application Web (client).
    • Cette requête de redirection contient:
      • code : Le code d'autorisation pour les types de ressources demandées par l'application Web (Client) et autorisé par l'utilisateur (Resource Owner)
      • state : La chaîne de caractères qui indique que cette requête de redirection correspond bien à la requête initiale de demande d'autorisation. Cette chaîne de caractère doit être identique à celle du paramètre state de la requête initiale.
  8. Le navigateur transmet la requête HTTP de redirection à l'application Web (client)
  9. L'application Web reçoit le code d'autorisation et émet une requête contenant ce code au serveur d'autorisation
    • La requête HTTP pour récupérer le jeton d'accès contient :
      • grant_type : a pour valeur "authorization_code"
        • Ceci indique que nous souhaitons récupérer le jeton d'accès à partir du code d'autorisation
      • code : le code d'autorisation émis par le serveur d'autorisation
      • client_id : l'identifiant de l'application Web auprès du serveur d'autorisation
      • redirect_uri : cette URL doit être celle qui a été émise dans la requête de l'étape 1 de ce scénario
  10. Le serveur d'autorisation retourne le jeton d'accès (Access Token) ainsi que le jeton de rafraîchissement (Refresh Token) correspondant au code d'autorisation transmis par l'application Web
    • La requête HTTP de réponse contient le jeton d'accès et de rafraîchissement, ainsi que la durée avant expiration:
        • HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "token_type":"example",
       "example_parameter":"example_value"
     }
  11. L'application Web peut maintenant utiliser le jeton d'accès (Access Token) pour accéder aux ressources. Elle émet une requête HTTP au serveur de ressources. Cette requête HTTP contient le jeton d'accès.
  12. Le serveur de ressources vérifie que le jeton d'accès n'est pas expiré et que la ressource demandée est bien dans le scope du jeton d'accès. Le serveur de ressources renvoie la ressource protégée demandée à l'application Web


Mode d'autorisation n°2 : Droit implicite


Ce mode d'autorisation est utile dans le cas où l'application se trouve au niveau du navigateur Web, comme dans le cas d'une application AngularJS.

Le jeton d'accès est transmis directement au navigateur Web. Nous pouvons avoir plus facilement un vol du jeton d'accès. C'est pourquoi ce mode d'autorisation n'est pas préconisé.

Aucun jeton de rafraîchissement n'est émis dans ce mode d'autorisation.

Rôles

  • Resource Owner : L'utilisateur
  • Client Application : L'application Javascript dans le navigateur Web
  • Authorization Server : Le serveur d'autorisation
  • Resources Server : Le serveur de ressources

Scénario


Cliquer sur l'image pour l'agrandir.

  1. L'application Web (client) envoie une redirection HTTP au navigateur Web de l'utilisateur vers la page d'authentification et d'autorisation du serveur d'autorisation.
    •  Cette redirection HTTP contient les informations suivantes :
      • response_type : a pour valeur "token". 
        • Ceci indique que le type d'autorisation s'effectue via une autorisation implicite
      • client_id : l'identifiant de l'application Web (client) auprès du serveur d'autorisation
      • scope  : les types de ressources demandées par l'application Web
      • redirect_uri : L'URL de redirection vers une des pages de l'application Web une fois que l'authentification et l'autorisation auront réussi ou non auprès du serveur d'autorisation
      • state : utilisé pour garantir la sécurité (Cross-Site Request Forgery - CSRF): il s'agit d'une chaîne de caractères générée par l'application Web qui lui permettra de savoir que la future requête de réponse du serveur d'autorisation est bien la réponse à cette requête de demande d'autorisation (cela évite les usurpations). La requête de réponse du serveur d'autorisation devra inclure cette chaîne de caractères dans le paramètre state.
  2. Le navigateur envoie la requête de redirection au serveur d'autorisation
  3. Le serveur d'autorisation renvoie la page d'authenfication et d'autorisation au navigateur
  4. Le navigateur affiche la page d'authentification et d'autorisation à l'utilisateur (Resource Owner)
  5. L'utilisateur s'authentifie et autorise ou refuse les autorisations
  6. Le navigateur transmet la réponse de l'utilisateur au serveur d'autorisation
  7. Le serveur d'autorisation renvoie une requête de redirection vers une des pages de l'application Web (client).
    • Cette requête de redirection contient:
      • access_token : Le jeton d'accès aux types de ressources demandées par l'application Web (Client) et autorisé par l'utilisateur (Resource Owner)
      • token_type : Le type de jeton
      • expires_in : délai avant expiration du jeton d'accès
      • scope : Liste des types de ressources autorisés par l'utilisateur (Resource Owner)
      • state : La chaîne de caractères qui indique que cette requête de redirection correspond bien à la requête initiale de demande d'autorisation. Cette chaîne de caractère doit être identique à celle du paramètre state de la requête initiale.
  8. Le navigateur utilise la requête HTTP de redirection retourné par le serveur d'autorisation.  
  9. La requête HTTP redirige vers une page contenant un script Javascript qui va retourner le jeton d'accès au navigateur
  10. Le navigateur transmet le jeton d'accès à l'application Javascript
  11. L'application Javascript reçoit le jeton d'accès. Elle peut émettre des requêtes vers le serveur de ressources pour récupérer des ressources protégées autorisées par le jeton d'accès
  12. Le serveur de ressources vérifie que le jeton d'accès n'est pas expiré et que la ressource demandée est bien dans le scope du jeton d'accès. Le serveur de ressources renvoie la ressource protégée demandée à l'application Javascript


Mode d'autorisation n°3 : Autorisation par le mot de passe de l'utilisateur



L'utilisateur fournit son login et mot de passe à l'application Web et c'est ce dernier qui transmet le login et mot de passe de l'utilisateur au serveur d'autorisation pour authentifier l'utilisateur et pour récupérer le jeton d'accès aux ressources de l'utilisateur.

Ce mode d'authentification correspond au cas où le serveur d'autorisation et l'application Web sont liés et se connaissent. Ce peut être le cas où le serveur d'autorisation et l'application Web sont sur le même serveur ou dans la même DMZ car la confiance doit être totale entre le serveur d'autorisation et l'application Web.

Rôles

  • Resource Owner : L'utilisateur
  • Client Application : L'application Web
  • Authorization Server : Le serveur d'autorisation
  • Resources Server : Le serveur de ressources

Scénario

Cliquer sur l'image pour l'agrandir.

  1. L'utilisateur (Resource Owner) saisit son login et son mot de passe dans un formulaire fourni par l'application Web (Client)
  2. Le navigateur transmet la requête HTTP contenant le login et le mot de passe de l'utilisateur à l'application Web
  3. L'application Web envoie une requête HTTP contenant le login et le mot de passe de l'utilisateur au serveur d'autorisation
  4. Le serveur d'autorisation vérifie le login et le mot de passe de l'utilisateur. Si l'authentification réussit, le serveur d'autorisation renvoie le jeton d'accès et de rafraîchissement dans la réponse à la requête précédente.
  5. L'application Web peut utiliser le jeton d'accès pour récupérer les ressources protégées de l'utilisateur hébergées sur le serveur de ressource. L'application Web émet une requête HTTP contenant le jeton d'accès au serveur de ressources
  6. Le serveur de ressources vérifie que le jeton d'accès n'est pas expiré et que la ressource demandée est bien dans le scope du jeton d'accès. Après validation, le serveur retourne la ressource demandée dans la réponse de la requête HTTP précédente


Mode d'autorisation n°4 : Autorisation par authentification du client (Serveur à Serveur)


    Ce mode d'autorisation est à utiliser lorsque l'application Web (client) est le détenteur (Resource Owner) des ressources.

    Elle s'enregistre alors directement auprès du serveur d'autorisation afin de récupérer le jeton d'accès à ses propres ressources situées sur le serveur de ressource.

    Rôles

    • Resource Owner : L'application Web
    • Client Application : L'application Web
    • Authorization Server : Le serveur d'autorisation
    • Resources Server : Le serveur de ressources

    Scénario


    Cliquer sur l'image pour l'agrandir.

    1. L'application Web tarnsmet une requête HTTP pour s'authentifier auprès du serveur d'autorisation à l'aide de son identifiant client (client id) et demander le jeton d'accès
    2. Le serveur d'autorisation retourne le jeton d'accès et de rafraîchissement
    3. L'application Web dispose du jeton d'accès pour récupérer ses ressources hébergées sur le serveur de ressources. L'application Web transmet une requête contenant le jeton d'accès au serveur de ressources.
    4. Le serveur de ressources vérifie que le jeton d'accès n'est pas arrivé à expiration. Après validation, le serveur de ressources retourne la ressource demandée.

    Conclusion

    Nous venons de voir les 4 modes d'autorisation de OAuth 2.0.

    OAuth 2.0 permet de gérer différentes situations suivant qui est le propriétaire des ressources et qui souhaite accéder et utiliser ses ressources.

    Il est possible d'utiliser OAuth pour faire du Single Sign-On entre services et applications pour éviter que l'utilisateur n'ait à se reconnecter sur chaque application et pour éviter que l'application cliente n'ait à s'authentifier de nouveau à chaque accès à u service REST situé sur des serveurs différents. 

    Références

    Libellés : ,