Conversando com meus dois centavos, como desenvolvedor do Passport .
Antes de desenvolver o Passport, avaliei tudo e determinei que ele não atendia aos meus requisitos. Então, comecei a implementar uma solução diferente que seria. Os principais pontos que eu queria abordar são:
Idiomatic Node.js
everyauth faz uso extensivo de promessas, em vez da abordagem do Node de usar retornos de chamada e fechamentos. As promessas são uma abordagem alternativa à programação assíncrona. Embora útil em algumas situações de alto nível, não me senti à vontade com uma biblioteca de autenticação forçando essa escolha no meu aplicativo.
Além disso, acho que o uso adequado de retornos de chamada e fechamentos gera código conciso e bem arquitetado (estilo quase funcional). Grande parte do poder do Node vem desse fato, e o Passport segue o exemplo.
Modular
O Passport emprega um padrão de design de estratégia para definir uma clara separação de preocupações entre o módulo principal e vários mecanismos de autenticação. Isso tem vários benefícios, incluindo tamanho geral menor do código e interfaces bem definidas e testáveis.
Para uma ilustração básica, compare a diferença entre execução $ npm install passporte$ npm install everyauth . O Passport permite que você crie seu aplicativo usando apenas as dependências realmente necessárias.
Essa arquitetura modular provou ser adaptável, facilitando uma comunidade que implementou suporte para uma ampla variedade de mecanismos de autenticação, incluindo OpenID, OAuth, BrowserID, SAML, etc.
Flexível
O passaporte é apenas middleware , usando a fn(req, res, next)convenção estabelecida pelo Connect e Express.
Isso significa que não há surpresas , pois você define onde deseja suas rotas e quando deseja usar a autenticação. Também não há dependências em uma estrutura específica. As pessoas estão usando o Passport com sucesso com outras estruturas, como o Flatiron
Por outro lado, qualquer módulo em tudo pode inserir rotas no seu aplicativo. Isso pode dificultar a depuração, pois não é óbvio como uma rota será despachada e leva a um acoplamento rígido com uma estrutura específica.
O Passport também erros de uma maneira totalmente convencional, próximo ao middleware de tratamento de erros, conforme definido pelo Express.
Por outro lado, everyauth tem suas próprias convenções, que não se encaixam bem no espaço do problema, causando problemas abertos de longa data, como # 36
Autenticação de API
A principal conquista de qualquer biblioteca de autenticação é sua capacidade de lidar com a autenticação da API de maneira tão elegante quanto a conexão baseada na Web.
Não vou elaborar muito sobre esse ponto. No entanto, incentivo as pessoas a olharem para os projetos irmãos do Passport, OAuthorize e OAuth2orize . Usando esses projetos, você pode implementar a autenticação "pilha completa", para aplicativos Web baseados em HTML / sessão e clientes API.
Confiável
Por fim, a autenticação é um componente crítico de um aplicativo e você deseja se sentir totalmente confortável em confiar. everyauth tem uma longa lista de problemas, muitos dos quais permanecem abertos e ressurgem com o tempo. Na minha opinião, isso se deve à baixa cobertura do teste de unidade, o que sugere que as interfaces internas em todos os itens não estão definidas adequadamente.
Por outro lado, as interfaces do Passport e suas estratégias são bem definidas e amplamente cobertas por testes de unidade. Os problemas arquivados no Passport tendem a ser principalmente solicitações menores de recursos, em vez de erros relacionados à autenticação.
Apesar de ser um projeto mais jovem, esse nível de qualidade sugere uma solução mais madura, mais fácil de manter e confiar no futuro.