Les social logins, comment ça marche ?

Comment ça fonctionne ?

Le protocole de base sur lequel tout repose est Oauth2. On va donc commencer par lui.

Oauth2

Si il y a un 2, ça veut dire que c’est la deuxième version.

La première version, Oauth, présente de multiples failles de sécurité. Ne l’utilisez jamais.

Oauth2 est le protocole qui gère l’autorisation. Il permet à un appareil d’accéder à des ressources, des données présentes sur un serveur.

Pour ça, il utilise des scopes. Ce sont des paramètres qui demandent l’accès à telle ou telle ressource.

Par exemple : le scope « profile » demande l’accès aux informations du profil de l’utilisateur.

Le serveur renvoie un claim. C’est une représentation des données demandées.

Donc pour le scope « profile », on a le claim :

{
  name: Alice le Lapin,
  firstname: Alice,
  lastname: le Lapin
}

Ce protocole peut gèrer différentes méthodes permettant l’autorisation mais dans le cas du social login, une seule nous intéresse.

Octroi d’un code d’autorisation (authorization code grant)

Cette méthode d’authentification permet à un service d’autoriser la connexion d’un utilisateur sans son mot de passe mais en faisant confiance à un serveur d’autorisation.

Voici le fonctionnement :

• l’utilisateur veut se connecter à un service
• le service redirige l’utilisateur vers la page d’accès du serveur d’autorisation
• l’utilisateur se connecte au serveur d’autorisation si ce n’est pas déjà le cas (il utilise son mot de passe à ce moment-là sur le serveur d’autorisation)
• le serveur d’autorisation présente à l’utilisateur le panneau lui demandant confirmation s’il veut réellement se connecter au service
• l’utilisateur confirme
• le serveur redirige alors l’utilisateur vers le service avec un code d’autorisation
• le service utilise le code d’autorisation reçu pour demander un code (token) d’accès au serveur d’autorisation
• le serveur d’autorisation accepte la connexion du service pour l’utilisateur
• l’utilisateur est connecté au service

Comme vous le voyez, l’utilisateur n’a jamais mis son mot de passe dans le service. Le stockage des mots de passe est réalisé uniquement sur le serveur d’autorisation.

OpenID Connect

Cette extension de Oauth2 est gérée par la fondation OpenID. Cette fondation gère aussi l’OpenID original qui a son propre fonctionnement.

Cette extension gère l’authentification (l’identité). Elle se sert du serveur d’autorisation comme serveur d’authentification.

En s’appuyant sur le fonctionnement de l’ « Authorization code grant », elle vérifie l’identité de l’utilisateur auprès du serveur grâce aux informations renvoyées par celui-ci (un identifiant unique, généralement l’email même si le mieux serait un UUID).

De plus, cette extension a des options :

• Le point d’accès UserInfo fourni par le serveur d’authentification : permet de récupérer dynamiquement des informations du profil utilisateur ;
• Le point d’accès Session fourni par le serveur d’authentification : permet de vérifier la session, pour synchroniser les sessions par exemple, faire en sorte que la session de l’utilisateur sur le service se termine en même temps que celle sur le serveur ;
• Un flux de déconnexion qui permet de déconnecter l’utilisateur de tous les services quand il se déconnecte du serveur d’authentification ;
• Un flux de connexion implicite appelé « Single Sign On » qui permet à l’utilisateur de se connecter à un service de façon transparente. Le service et le serveur semblent unifiés dans une seule et même application. Chez Limawi nous avons mis en place un tel système en interne pour le Blog.

Les avantages

Ce système permet de lier des services entre eux sans utiliser de mots de passe pour chacun de ce services (ce qui augmente la sécurité).

De même, cela permet la synchronisation d’informations (données) entre les services en ayant un silo d’informations (un endroit où elles sont stockées) qui fait référence. Cela réduit les conflits d’informations, quand c’est bien fait.

Les risques

Utiliser un tel système requiert d’avoir toute confiance dans le fournisseur d’autorisation. Ce dernier peut avoir accès aux informations au sein des services qui lui sont liés, car il peut se faire passer pour l’utilisateur et obtenir un code d’autorisation à la place de celui-ci.

La synchronisation des identités et des objets (données) n’est pas toujours bien réalisée. On peut se retrouver avec plusieurs comptes sur un même service simplement parce qu’on a changé son email sur le serveur d’autorisation. Le service basé sur l’email ne retrouve plus le compte antérieur et il en crée un nouveau.

La déconnexion n’est souvent pas implémentée. Les grands fournisseurs de social login ayant un fonctionnement de session permanente, beaucoup de services n’implémentent pas de vérification de déconnexion. On peut se retrouver avec des services ouverts (l’utilisateur est connecté) alors que le serveur d’authentification est fermé (l’utilisateur s’est déconnecté de Facebook, Google).

Si le serveur d’autorisation est attaqué, corrompu, fragilisé, tous vos services liés sont fragilisés.

Les attaques

Clickjacking (détournement de clic)

Un hacker peut créer un service malicieux où il charge le serveur d’autorisation dans une iframe transparente.

Pour simplifier, imaginez que votre serveur d’authentification soit un smartphone.

Vous cliquez sur le bouton au milieu de l’écran de votre smartphone pour accepter le service.

Dans le clickjacking, le hacker a glissé une feuille transparente sur l’écran de votre smartphone et quand vous cliquez sur le bouton, vous cliquez en fait sur la feuille, et vous avez accepté sans le savoir l’accès du service malicieux à vos données.

Pour les développeurs, pensez à implémenter le header « X-Frame-Options » et contraignez-le au maximum (« SameOrigin » par exemple) et/ou des framebusting en javascript.

Cross-site request forgery (falsification de requête entre sites)

Un hacker peut faire en sorte que l’utilisateur clique sur un bouton d’autorisation du serveur qui redirige, non pas vers le service que le client souhaite, mais vers le service malicieux du hacker. Le service malicieux récupère le code d’autorisation et redirige l’utilisateur vers le bon service.

L’utilisateur n’a rien vu mais le service malicieux possède le token d’autorisation et donc celui d’accès.

Pour les développeurs, forcez les services à utiliser une url de redirection fixée à l’avance.

Il y a d’autres CSRF (contraction de l’attaque) possibles, j’irai plus en détails dans un futur article.

Confused deputy problem (problème du délégué confus)

C’est le problème qui arrive avec les services qui ne vérifient pas correctement l’identité de l’utilisateur qui utilise le serveur d’autorisation.

Un utilisateur malicieux peut se connecter sur le serveur d’autorisation et faire croire au service que c’est un autre en manipulant l’information que le service utilise pour identifier l’utilisateur.

Si le service n’a pas pris une information fiable pour identifier correctement l’utilisateur, il est trompé et ouvre l’accès au mauvais compte.

Par exemple :

Un service utilise un serveur d’autorisation qui donne un UUID et un nom.

Le serveur d’autorisation a deux comptes :

• Alice avec UUID : 46d07175-dbf2-46e2-80fc-c6493e481479
• Oscar avec UUID : 362b862b-51b3-41f4-82c7-82eb677a9aa4

Le serveur d’autorisation fournit les UUID comme identifiants uniques et s’attend à ce que le service s’en serve.

Mais non, le service choisit d’utiliser le nom comme identifiant unique.

Oscar change donc son nom pour Alice (ce qui est autorisé par le serveur puisque, pour lui, l’identifiant unique est le UUID).

Maintenant, quand Oscar se connecte sur le service il accède directement au compte d’Alice (puisque, pour le service, l’identifiant unique est le nom).

Pour les développeurs, veillez à choisir vraiment un identifiant unique. Les UUID sont faits pour ça. Ils ne transportent pas d’information utilisateur donc ça n’empêche pas un utilisateur de changer toutes les informations qu’il souhaite (même son email).