Je suis venu avec mes deux cents, en tant que développeur de Passport .
Avant de développer Passport, j'ai évalué chaque auth et déterminé qu'il ne répondait pas à mes exigences. Alors, je me suis mis à mettre en œuvre une solution différente qui le ferait. Les principaux points que je voulais aborder sont:
Node.js idiomatique
everyauth fait un usage intensif des promesses, au lieu de l'approche de Node consistant à utiliser des rappels et des fermetures. Les promesses sont une approche alternative à la programmation asynchrone. Bien qu'utile dans certaines situations de haut niveau, je n'étais pas à l'aise avec une bibliothèque d'authentification forçant ce choix à mon application.
De plus, je trouve que l'utilisation appropriée des rappels et des fermetures donne un code concis et bien structuré (style presque fonctionnel). Une grande partie de la puissance de Node lui-même vient de ce fait, et Passport fait de même.
Modulaire
Passport utilise un modèle de conception de stratégie pour définir une séparation claire des préoccupations entre le module central et divers mécanismes d'authentification. Cela présente un certain nombre d'avantages, notamment une taille de code globale plus petite et des interfaces bien définies et testables.
Pour une illustration de base, comparez la différence entre l'exécution $ npm install passportet $ npm install everyauth. Passport vous permet de créer votre application en utilisant uniquement les dépendances dont vous avez réellement besoin.
Cette architecture modulaire s'est avérée adaptable, facilitant une communauté qui a implémenté la prise en charge d'une grande variété de mécanismes d'authentification, notamment OpenID, OAuth, BrowserID, SAML, etc.
Souple
Passport n'est qu'un middleware , utilisant la fn(req, res, next)convention établie par Connect et Express.
Cela signifie qu'il n'y a pas de surprises , car vous définissez où vous voulez vos itinéraires et quand vous voulez utiliser l'authentification. Il n'y a pas non plus de dépendances sur un framework spécifique. Les gens utilisent avec succès Passport avec d'autres frameworks tels que Flatiron
En revanche, n'importe quel module de everyauth peut insérer des routes dans votre application. Cela peut rendre le débogage difficile, car il n'est pas évident de savoir comment une route sera distribuée et conduit à un couplage étroit avec un cadre spécifique.
Passport a également des erreurs d'une manière tout à fait conventionnelle, proche du middleware de gestion des erreurs tel que défini par Express.
En revanche, everyauth a ses propres conventions, qui ne correspondent pas bien à l'espace du problème, provoquant des problèmes ouverts de longue date tels que # 36
Authentification API
Le couronnement de toute bibliothèque d'authentification est sa capacité à gérer l'authentification API aussi élégamment que la connexion basée sur le Web.
Je ne développerai pas grand chose sur ce point. Cependant, j'encourage les gens à se pencher sur les projets frères de Passport, OAuthorize et OAuth2orize . À l'aide de ces projets, vous pouvez implémenter l'authentification «full-stack», à la fois pour les applications Web HTML / basées sur une session et les clients API.
Fiable
Enfin, l'authentification est un composant essentiel d'une application et sur lequel vous voulez vous fier pleinement. everyauth a une longue liste de problèmes dont beaucoup restent ouverts et refont surface avec le temps. À mon avis, cela est dû à une faible couverture des tests unitaires, ce qui suggère en soi que les interfaces internes de everyauth ne sont pas correctement définies.
En revanche, les interfaces de Passport et ses stratégies sont bien définies et largement couvertes par des tests unitaires. Les problèmes déposés contre Passport sont généralement des demandes de fonctionnalités mineures, plutôt que des bogues liés à l'authentification.
Bien qu'il s'agisse d'un projet plus jeune, ce niveau de qualité suggère une solution plus mature, plus facile à maintenir et à faire confiance à l'avenir.