Coincidiendo con mis dos centavos, como desarrollador de Passport .
Antes de desarrollar Passport, evalué everyauth y determiné que no cumplía con mis requisitos. Entonces, me puse a implementar una solución diferente que lo haría. Los puntos principales que quería abordar son:
Idiomatic Node.js
everyauth hace un uso extensivo de las promesas, en lugar del enfoque de Node de usar devoluciones de llamada y cierres. Las promesas son un enfoque alternativo para la programación asíncrona. Si bien es útil en algunas situaciones de alto nivel, no me sentía cómodo con una biblioteca de autenticación que obligara esta elección a mi aplicación.
Además, creo que el uso adecuado de devoluciones de llamada y cierres produce un código conciso y bien diseñado (estilo casi funcional). Gran parte del poder de Node en sí proviene de este hecho, y Passport hace lo mismo.
Modular
Passport emplea un patrón de diseño de estrategia para definir una clara separación de preocupaciones entre el módulo central y varios mecanismos de autenticación. Esto tiene una serie de beneficios, que incluyen un tamaño de código general más pequeño e interfaces bien definidas y comprobables.
Para una ilustración básica, compare la diferencia entre correr $ npm install passporty $ npm install everyauth. Passport le permite crear su aplicación utilizando solo las dependencias que realmente necesita.
Esta arquitectura modular ha demostrado ser adaptable, facilitando una comunidad que ha implementado el soporte para una amplia variedad de mecanismos de autenticación, incluidos OpenID, OAuth, BrowserID, SAML, etc.
Flexible
Passport es solo middleware , usando la fn(req, res, next)convención establecida por Connect y Express.
Esto significa que no hay sorpresas , ya que define dónde desea sus rutas y cuándo desea usar la autenticación. Tampoco hay dependencias en un marco específico. Las personas están usando Passport con éxito con otros marcos como Flatiron
Por el contrario, cualquier módulo en everyauth puede insertar rutas en su aplicación. Esto puede dificultar la depuración, ya que no es obvio cómo se distribuirá una ruta y conduce a un acoplamiento estrecho con un marco específico.
Passport también comete errores de una manera totalmente convencional, junto al middleware de manejo de errores como lo define Express.
En contraste, everyauth tiene sus propias convenciones, que no se ajustan bien al espacio del problema, causando problemas abiertos de larga data como el # 36
Autenticación API
El mayor logro de cualquier biblioteca de autenticación es su capacidad para manejar la autenticación API de manera tan elegante como el inicio de sesión basado en la web.
No voy a elaborar mucho sobre este punto. Sin embargo, animo a las personas a buscar en los proyectos hermanos de Passport, OAuthorize y OAuth2orize . Con estos proyectos, puede implementar la autenticación de "pila completa", tanto para aplicaciones web basadas en sesión / HTML como para clientes API.
De confianza
Finalmente, la autenticación es un componente crítico de una aplicación, y uno en el que desea estar completamente seguro. everyauth tiene una larga lista de problemas, muchos de los cuales permanecen abiertos y resurgen con el tiempo. En mi opinión, esto se debe a la baja cobertura de prueba de la unidad, lo que sugiere que las interfaces internas en everyauth no están definidas adecuadamente.
En contraste, las interfaces de Passport y sus estrategias están bien definidas y ampliamente cubiertas por pruebas unitarias. Los problemas presentados contra Passport tienden a ser principalmente solicitudes de características menores, en lugar de errores relacionados con la autenticación.
A pesar de ser un proyecto más joven, este nivel de calidad sugiere una solución más madura que es más fácil de mantener y confiar en el futuro.