Os pacotes de Node.js para OAuth 2.0 ainda têm muito a melhorar. Eles não são flexíveis e geralmente forçam o desenvolvedor a ajustar seus servidores OAuth 2.0 para se adaptarem ao que já existe.
Se você trabalha num lugar que usa IdentityServer4 e sua empresa tem várias tecnologias como Node.js, os desenvolvedores podem ter problemas com um AuthServer rodando no IdentityServer4.
Componentes
Quando se trabalha com uma API Node que precisa validar um Bearer Token que não vem de servidores OAuth 2.0 da Okta ou Auth0, a integração com AuthServers diferentes, como o IdentityServer4, pode ser complicada.
Procurando componentes para validar Access Tokens, JWTs ou Bearer Tokens, você vai encontrar recursos de lugares como Okta ou Auth0. Exemplos conhecidos incluem:
- @okta/jwt-verifier - Okta
- jwks-rsa - Auth0
- jsonwebtoken - Auth0
Esses componentes só usam algoritmos RSA, mesmo com a recomendação atual da RFC para usarmos ECDsa.
Por exemplo, o Custom Authorizer da Okta é baseado no projeto node-lambda-oauth2-jwt-authorizer. Este só aceita JWTs em Bearer Token e ignora múltiplas Audiences, algo comum nos tokens do IdentityServer4.
Os componentes funcionam quase sempre dentro do modelo de configuração dos servidores OAuth 2.0 enlatados.
O Problema
Usar esses componentes em diferentes Auth Servers faz o desenvolvedor precisar saber mais sobre OAuth 2.0, o que complica as coisas.
Isso abre espaço para adaptações meio perdidas. Às vezes, até requer mudar configurações do seu IdentityServer4, o que afeta suas APIs e o frontend do cliente.
Se você usa IdentityServer4, vai encontrar dificuldade com algumas implementações. A Okta, por exemplo, não tolera tokens com mais de uma Audience, algo comum com IdentityServer4. Nos tutoriais simples, você verá JWTs como este:
// Exemplo de JWT
<script src="https://gist.github.com/brunobritodev/8922b82c8878939c500ec0a6e1fd618e.js"></script>
Mudar seu IdentityServer4 para não ter várias Audiences impacta suas aplicações.
Eles são ruins?
Não, de forma alguma. Um dos criadores da RFC 6750 é um arquiteto de segurança da Okta. Inclusive, a Okta mantém o site do OAuth 2.0.
Os materiais mais completos sobre OAuth 2.0 provavelmente vêm da Auth0.
O verdadeiro problema é que os componentes são muito vinculados à empresa que os fez, complicando o uso em outros contextos, como o IdentityServer4.
E o .NET?
No mundo .Net, os componentes são muito bons. Eles seguem as RFCs direitinho, o que permite integração com qualquer servidor de OAuth 2.0.
Não há limitação de algoritmos, aceitando quase todos citados na RFC, como RSA e ECDsa.
Há uma diferença clara entre Resource Server e Client. Muitos artigos em outras línguas não têm essa separação, o que confunde quando uma API é Client e quando é Resource Server. Isso atrapalha o entendimento do protocolo e cria implementações duvidosas.
Se alguém quer aprender sobre OAuth 2.0, recomendaria o IdentityServer4 como a escola definitiva.
Alternativas
Com poucas alternativas, fiz dois componentes em Node.js para facilitar a criação de APIs Node integradas com um AuthServer OAuth 2.0.
Validação de Access Token
Este pacote se baseia no IdentityModel.AccessTokenValidation, do pessoal do IdentityServer4. Ele valida tanto Bearer Tokens quanto Reference Tokens, aceitando RSA e ECDsa. Segue o mesmo modelo de configuração do Asp.Net.
Você encontra no meu GitHub.
Custom Authorizer
É um modelo para o Custom Authorizer do API Gateway da Amazon. Baseia-se na Validação de Access Tokens, permitindo ao API Gateway validar tokens de qualquer servidor OAuth 2.0 sem precisar de uma Audience única.
Disponível no meu GitHub.
TypeScript
Ambos são feitos com TypeScript, que é bem aceito na nossa comunidade.
Conclusão
No futuro, vou criar um tutorial sobre como configurar o API Gateway e integrar com o IdentityServer4.
Por agora, estou compartilhando rapidamente para ajudar você e outros desenvolvedores de forma mais rápida. Um tutorial demora mais para fazer.
Espero que você goste e que minha contribuição seja útil! Comente aí!
Download
Os projetos:
Fale conosco