Comment migrer une webapp héritée existante pour utiliser OAuth2

J'ai actuellement une webapp monolithique héritée de 15 ans avec près de 1 million d'utilisateurs, utilisant un système d'autorisation et d'authentification maison: JAAS, noms d'utilisateurs et magasin pwds dans une base de données avec hachage de mot de passe de base, quelques questions de vérification personnelle 2FA (avec différentes algorithmes de hachage, etc.).

Je réviserai l'application au cours des 12 à 18 prochains mois, principalement en se concentrant sur l'interface utilisateur, mais en mettant également à niveau lentement les parties sous-jacentes (mise à niveau vers Spring, Spring Security, etc.). Dans le cadre de ce projet, nous avons décidé de nous attaquer à la mise à niveau de l'interface utilisateur module par module; rendre chaque module disponible une fois terminé; une occasion parfaite de diviser le monolithe en applications Web individuelles (toutes conservant le même design UX).

Là où je suis coincé à essayer de planifier cela, c'est au niveau de l'authentification et de l'autorisation. J'ai besoin d'une solution transversale qui s'étendra sur tous les modules, de sorte que lorsqu'un utilisateur est dirigé d'une application Web à une autre, il s'agit d'une transition transparente - il ne saura même pas qu'il se trouve sur différentes applications Web. OAuth2 semble être la solution parfaite.

Je suis coincé à essayer de comprendre comment intégrer cela. Dois-je créer mon propre serveur OAuth2 personnalisé? Cela me frappe comme une terrible idée. Mais comment puis-je:

1. migrer tous mes comptes d'utilisateurs et processus d'autorisation vers un serveur OAuth2 tiers
2. personnaliser l'apparence pour qu'elle corresponde au reste de mon application (je ne sais pas avec quelle facilité / probabilité ce sera)
3. empêcher la fenêtre typique "Application XYZ voudrait la permission d'accéder à votre compte ..." lors de la connexion via un serveur tiers? (ex: Google OpenID, Facebook, etc.).

Mon objectif est de fournir une transition transparente pour l'utilisateur de l'état actuel au nouvel état, mais en offrant la possibilité de créer des webapps distinctes qui s'authentifient et autorisent toutes en dehors de la webapp.

Divulgation : je suis ingénieur chez Auth0 .

Cela dépend d'un point majeur ... vous devez décider si:

1. vous souhaitez consacrer directement (et indirectement de l'argent) un temps considérable à la création et / ou à la maintenance de votre propre fournisseur d'identité et serveur d'autorisation
2. ou vous préférez dépenser directement de l'argent et utiliser un fournisseur d'authentification tiers comme Auth0.

Les deux options sont parfaitement viables du point de vue de vos besoins fonctionnels. Avec le développement personnalisé, vous contrôlez pleinement les fonctionnalités que vous décidez de prendre en charge, je vais donc concentrer une partie de la réponse sur la façon dont Auth0 peut répondre aux exigences que vous avez répertoriées .

Cependant, avant de passer à cela, quelle que soit votre décision, pour l'authentification, vous devez vous concentrer sur OpenID Connect au lieu d'OAuth2. Ce dernier sera plus applicable si vous prévoyez d'avoir également des API dans le mélange et pas seulement de diviser le monolithe en applications Web distinctes.

Comment migrer des utilisateurs existants vers un système basé sur Auth0?

Vous pouvez soit décider de continuer à utiliser votre base de données et compter sur Auth0 pour fournir toute la conformité avec les protocoles liés à l'authentification que vous devrez peut-être utiliser, soit migrer vos utilisateurs vers des bases de données gérées Auth0 et cesser de vous soucier de la façon dont vous stockez et validez les mots de passe.

Si vous préférez continuer à utiliser votre base de données, voir Authentifier les utilisateurs avec un nom d'utilisateur et un mot de passe à l'aide d'une base de données personnalisée

Les applications s'appuient souvent sur des bases de données utilisateur pour l'authentification. Auth0 vous permet de vous connecter facilement à ces référentiels et de les utiliser comme fournisseurs d'identité tout en préservant les informations d'identification de l'utilisateur et en fournissant de nombreuses fonctionnalités supplémentaires.

_{(Les documents font référence à MySQL à titre d'exemple, d'autres moteurs de base de données sont pris en charge)}

D'autre part, vous pouvez déplacer en toute transparence les informations d'identification de l'utilisateur vers les bases de données Auth0 en tirant parti du processus de migration décrit dans Migrer les utilisateurs vers Auth0

Auth0 prend en charge la migration automatique des utilisateurs vers Auth0 à partir d'une connexion de base de données personnalisée. Cette fonctionnalité ajoute vos utilisateurs à la base de données Auth0 une par une à chaque connexion et évite de demander à vos utilisateurs de réinitialiser leurs mots de passe en même temps.

Vous pouvez également créer tous vos utilisateurs dans Auth0 via l'API de gestion si vous préférez que tous commencent à utiliser notre algorithme de hachage de mot de passe à la fois. Cela a pour effet secondaire d'obliger les utilisateurs à réinitialiser leur mot de passe.

Comment continuer à utiliser l'authentification en deux étapes personnalisée (questions de vérification)?

Le pipeline d'authentification fourni par Auth0 est entièrement personnalisable grâce à l'utilisation de règles . Cela signifie que même si vous n'avez eu à implémenter aucun élément lié au protocole, vous pouvez toujours affiner les petits détails sur la façon dont l'authentification se produit dans votre application.

Cela inclut la possibilité de continuer à utiliser vos questions de vérification existantes comme moyen de procéder à un processus d'authentification en deux étapes où l'utilisateur fournit un mot de passe initial vérifié par Auth0, puis vous lui demandez des informations supplémentaires à partir d'une règle personnalisée. (les règles sont juste Javascript donc les possibilités sont infinies)

Cependant, vous pouvez également décider de supprimer les questions de vérification et d'utiliser plutôt Auth0 Guardian pour augmenter la sécurité du processus d'authentification.

Comment personnaliser l'apparence de l'interface utilisateur d'authentification?

Avec Auth0, vous pouvez avoir une interface utilisateur d'authentification propre en un rien de temps en tirant parti des pages de connexion par défaut ou des widgets d'authentification comme Lock . Tous ces éléments prennent en charge un certain degré de personnalisation et vous pouvez toujours décider de faire votre propre interface utilisateur vous-même et d'utiliser à la place les bibliothèques Auth0 de niveau inférieur ( Auth0.js ) qui ne font aucune contrainte sur l'interface utilisateur.

Pour plus d'informations sur la personnalisation:

• Personnalisation de l'apparence de Lock 10
• Comment personnaliser les pages hébergées

Comment empêcher les pages de consentement explicite?

Vous pouvez utiliser Auth0 à la fois comme fournisseur d'identité à des fins d'authentification et également comme serveur d'autorisation OAuth2 (actuellement disponible uniquement dans la région des États-Unis) pour vos API.

En tant que fournisseur d'identité, vous n'avez pas à vous soucier des pages de consentement, l'utilisateur s'authentifie avec ses informations d'identification gérées par Auth0 puis est redirigé vers votre application - c'est tout.

Dans OAuth2 en tant que scénario de service lorsque le consentement est activé, la feuille de route inclut l'autorisation de contourner les pages de consentement pour certaines applications.

Sur une note finale, cela semble être un projet très intéressant et stimulant que vous avez obtenu, donc bonne chance indépendamment de votre décision finale.

J'ai déjà vécu quelque chose de similaire lors d'un précédent travail lorsque j'ai dû réimplémenter le système d'authentification d'une application héritée. Nous avons implémenté notre propre fournisseur d'identité et serveur d'autorisation et pour être honnête, j'ai toujours le sentiment que nous avons peut-être oublié quelque chose de vraiment essentiel.

Je pense que c'est le plus gros problème avec le déploiement de votre propre sécurité, il y aura des occasions où les délais imposent des raccourcis et la sécurité n'est pas vraiment un bon domaine pour faire des raccourcis.

Si vous avez d'autres questions, faites-moi savoir si vous pensez que je pourrai être utile.