COMMENT NOUS AVONS CHOISI NOTRE SOLUTION D’AUTHENTIFICATION

Dans le cadre d’un projet de modernisation de notre espace client, nous avions besoin d’un nouveau composant en charge de l’authentification utilisateur.

Nos critères étaient assez simples

• Respecter le protocole OAuth2 et le standard Open Id Connect afin d’être compatible avec les outils et applications du marché
• Avoir une authentification unique : SSO
• Personnalisation :
• Pouvoir personnaliser l’affichage et les comportements
• Adapter le niveau de sécurité à nos besoins
• Etre capable de lier des évènements métiers à la brique d’authentification
• Gestion multi langue
• Connexion à notre fournisseur d’envoi de mail / SMS

Pour faire notre choix nous avons évalué 3 options :

• Développer une solution maison
• Utiliser une solution du marché
• Utiliser un projet Open Source

La solution maison :

En tant que développeur, on a tendance à vouloir développer soi-même un composant pour avoir la main dessus et maîtriser tous les aspects.
Nous avons rapidement écarté cette option pour des raisons assez simples :

• Temps de développement élevé
• Nous n’avons aucune valeur ajoutée à le faire nous même

Solutions du marché :

Il y a pas mal d’outils qui existent sur le marché pour répondre à ce besoin.
Nous avons évalué et comparé Azure B2C et Auth0.
Pourquoi ces 2 produits ? Azure B2C car nous utilisons déjà quelques composants Azure et Auth0, au moment de notre étude, ressortait comme un des leaders.

Les 2 solutions présentent pas mal d’avantages. La mise en place est assez simple et rapide.
On trouve beaucoup de documentations et de tutoriels. Il y a même des cours Pluralsight (Auth0 & Azure Ad B2C) qui en parlent.
Pour notre besoin, nous avons trouvé quelques freins.

• En fonction des solutions, il n’est pas possible d’utiliser notre propre service d’envoi d’email.
• Il ne nous était pas possible de personnaliser certains comportements et certaines règles.
• Enfin, le coût mensuel estimé était élevé pour notre projet.
• C’est en partie lié au fait que ces solutions offrent beaucoup de fonctionnalités dont nous n’avons pas besoin.

Projet Open Source :

En regardant les différents projets, nous avons retenu Identity Server.
Le projet est très actif, ils en sont déjà à la version 4. Nous avons considéré ça comme un gage de maturité.
La mise en place est très simple, en peu de temps notre POC était fonctionnel et répondait à nos exigences techniques et à nos besoins fonctionnels.
Ce Framework est écrit en AspNet Core :

• Ça tombe bien, nous utilisons déjà cette techno
• Avantage non négligeable, il peut donc être hébergé sur différents OS.

Conclusion :

Finalement, nous avons donc opté pour Identity Server. C’est le bon compromis entre un développement maison et une solution externe clé en main.
Nous avons profité des fonctionnalités de ce Framework tout en gardant la main sur la personnalisation et l’adaptation en fonction de nos besoins.

Est-ce que cette solution a répondu à notre besoin ?

Oui !

Est-ce que Identity Server est la réponse à votre besoin ?

• Je vais vous faire une réponse de Normand : Peut-être
• Il n’existe pas de solution « Silver Bullet ».
• Essayez et comparez

Un exemple d’implémentation d’Identity Server fera l’objet d’un article sur ce blog. Au programme :

• Présentation de notre POC
• Utilisation d’AspNet Identity Core pour stocker les données
• Comment personnaliser des données utilisateurs
• Un exemple concret de SSO entre plusieurs applications