Vous êtes convaincu(e) par l'architecture microservices ? La transition est en place, il vous manque juste la gestion de votre authentification ? Antonin Ribeaud vous explique la suite grâce à l’exemple de notre expérience d’OAuth2 et OpenID Connect, que nous avons utilisés pour la transition en microservices d’Ubeeqo.
Commençons par introduire OAuth2. Il s’agit d’un protocole de délégation d’autorité. Ici, nous devons d’abord distinguer le serveur d’autorisation du serveur de ressources. Dans un processus simplifié, l’utilisateur s’authentifie sur le serveur d’autorisation et récupère une preuve d’identité, ce qui permet au serveur de ressources de vérifier cet utilisateur auprès du serveur d’autorisation.
La preuve d’identité est composée d’un duo “access token” et “refresh token”. L'access token correspond à la preuve d’identité envoyée à chaque requête sur le serveur de ressources et a une durée de vie très limitée. Le refresh token permet, lui, de récupérer un nouvel access token si le précédent est expiré.
Antonin poursuit et vous présente le processus de demande d'accès. Ce dernier passe par le serveur d’autorisation, son “scope” permet de préciser les accès octroyés au client. Pour illustrer le propos, vous retrouvez dans cette vidéo quelques exemples d’utilisation de OAuth2 ainsi qu’une démonstration via un login Facebook.
Et pour les microservices, alors ? Après le processus OAuth2 l’utilisateur passe par l’API Gateway, dont le rôle est de contacter le serveur d’autorisation et suite à cette validation, nous fournit un UUID. Cet identifiant, propagé à toutes nos requêtes, sert à relier et identifier l’utilisateur sur chacun de nos services.
Pour plus de détails sur ce sujet, nous vous invitons à visionner ce Matters Meetup dans lequel vous trouverez la présentation complète d’Antonin, ainsi qu’une session de questions/réponses sur la transition vers une architecture en micro-services.
