Vous avez développé une superbe solution SaaS avec NodeJS.
Vous en êtes très content, ça tourne du feu de Dieu. L’authentification est gérée par Passport, avec un hash des mots de passe bien costaud et une stratégie de définition de mot de passe qui va être un vrai challenge pour l’imagination de vos utilisateurs. Majuscules, minuscules, chiffres, caractères spéciaux sur 54 caractères minimum sonnent le glas des traditionnels “12345678”, “toto” et autre “inserez-ici-le-nom-de-votre-chat”.
Et puisque vous êtes dans l’air du temps, vous avez mis en place tout ça sous forme d’une API Rest, avec Json Web Token et tout le tralala.
Non franchement, vous avez de quoi être fier de vous. Moi, je le serais, à votre place, rien que parce que vous n’enregistrez pas les mots de passe en clair dans votre base, parce que si si, on en voit encore, des apps qui stockent les mots de passe en clair.
Le hic, c’est que vous avez oublié quelque chose en terme de besoin client.
Beaucoup d’entreprises utilisent Azure AD au quotidien
Azure Active Directory, c’est la version moderne du traditionnel Active Directory que tout bon administrateur certifié Microsoft côtoie tous les jours. Moderne parce qu’on parle ici d’un AD dans le cloud géré par Microsoft.
Si votre produit est destiné au marché B2B, vous avez de fortes chances de devoir prendre ça en considération afin de répondre aux exigences techniques de votre client ou tout simplement de faciliter la vie des utilisateurs.
Ca tombe bien, chez Klapoti, on a à coeur de simplifier la vie des collaborateurs et de leur fournir une expérience agréable. C’est aussi ce genre de choses qui stimule l’engagement.
Bref, vous allez voir : au fond, implémenter une authentification à travers Azure Active Directory, c’est loin d’être insurmontable, loin de là.
Pré requis et spécs
Avant d’aller plus loin, pensez à vous créer un compte gratuit chez Microsoft Azure. Ca prend 5 minutes et un numéro de carte bleue, et ça vous permettra de créer un environnement de test, assez sommaire, mais suffisant pour de la mise en pratique :
https://azure.microsoft.com/fr-fr/free/
C’est bon pour vous ?
Etant donné que votre api est développée avec NodeJS, le meilleur choix qui s’offre à vous pour créer une interconnexion entre votre endpoint d’authentification et l’authentification Azure AD est d’utiliser le package NPM Passport Azure AD, gérée directement par Microsoft.
Plusieurs stratégies s’offrent à vous, toutes en relation avec Passport. On va s’intéresser ici à SAML, mais avant ça, plantons le décor !
On veut que :
- lors de leur accès à votre application, les utilisateurs soient invités à se connecter via leur compte dans la popup Microsoft
- si l’utilisateur est bien identifié et existe bien dans votre base d’une façon ou une autre (j’y reviens juste en dessous), il soit automatiquement loggé à votre app
- que l’utilisateur connecté soit soumis aux mêmes régles d’expiration du token JWT (refresh token, expiration…)
- que votre client soit content, accessoirement
Pour comparer les utilisateurs AD et ceux de votre base, plusieurs solutions existent. On partira ici sur le fait que vous disposez d’un export des utilisateurs et que vous les avez importé dans votre base, et disons aussi que l’on va se baser sur l’adresse E-Mail des utilisateurs pour chercher une correspondance.
(Je vous) Azure (que z’est zimple)
Désolé. Mais avouez que z’était tentant.
On va avoir besoin de configurer Azure AD pour :
- Autoriser notre API à discuter chiffons avec l’API Microsoft en inscrivant une application à page unique (SPA)
- créer un jeton valide pour lancer le processus de connexion côté front
- récupérer un jeton issu de la connexion de l’utilisateur
- valider le jeton en question auprès de l’API MS
- Récupérer des informations (scope) de l’utilisateur. En l’occurence ici, son adresse E-Mail pour pouvoir comparer cette information avec celles stockées en base
On dira ce qu’on voudra de Microsoft, mais s’il y a bien un truc sur lequel ils ne plaisantent pas, c’est bien sur la documentation :
https://docs.microsoft.com/fr-fr/azure/active-directory/manage-apps/configure-saml-single-sign-on
Je vous invite également à consulter ce post Medium qui vous donnera des informations complémentaires pour l’authentification SAML / Azure et NodeJS :
https://medium.com/@pradeep1991singh/getting-started-with-saml-azure-and-nodejs-341879c64b01
En deux mots, vous devez :
- inscrire une application au sein de votre AD (Allez dans Azure AD puis dans Inscription d’applications) et inscrivez une nouvelle application
- définir une ou plusieurs URL de redirection (http://localhost:3000/auth, https://votresuperapp.com/auth…)
- Sélectionner le type de comptes pris en charge
- Définir le type d’application. Dans notre cas, une SPA (single page application)
Les informations que vous allez obtenir sont de ce type :
authority: https://login.microsoftonline.com/common/
identityMetadata: https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
clientID: votre clientID,
issuer: https://login.microsoftonline.com/votre-id-de-locataire/v2.0
audience: votre clientID
Comme vu précédemment, les informations vous nous permettre de :
- Générer un token pour lancer la popup de connexion Microsoft
- De récupérer et de valider le token renvoyé par Microsoft à l’issu de la connexion
- D’obtenir des informations relatives à l’utilisateur
C’est le moment de souffler !
Dans notre prochain article, ce sera le moment de retrousser nos manches et de découvrir le code à implémenter en front et en back.
A ce stade, rien ne vous empêche de reproduire les processus de connexion en utilisant votre navigateur et Postman, l’idée étant de manipuler les urls et les informations en query string pour communiquer avec l’API Azure.
Rédigé par Grégory Babonaux,
CTO klapoti