Mergulho Profundo na Autenticação em Microservices

O que é o Serviço de Autenticação

Autenticação é o processo de verificar a identidade de um usuário para conceder acesso e as permissões necessárias para utilizar o sistema. O serviço que fornece essa função é o serviço de autenticação. Em uma aplicação de software monolítica tradicional, tudo isso acontece dentro da mesma aplicação, mas em uma arquitetura de microsserviços, o sistema é composto por vários serviços. Cada microsserviço tem suas próprias tarefas nessa arquitetura, portanto, implementar o processo de autorização e autenticação separadamente para cada microsserviço não funciona completamente.

Este artigo comparará a autenticação tradicional com a autenticação em microsserviços. E demonstrará as mudanças na autenticação trazidas pelas mudanças na arquitetura. Por fim, analisaremos os diversos serviços de autenticação na arquitetura de microsserviços e seus prós e contras em suas implementações.

Serviço de Autenticação na Arquitetura Tradicional

Nos primeiros dias, quando as empresas desenvolviam serviços, todas as funções eram implementadas na mesma aplicação. Chamamos esse modelo de "monolítico" para distingui-lo da arquitetura mais moderna e predominante de "microsserviços".

Uma aplicação monolítica consiste em uma única unidade indivisível. Geralmente, é desenvolvida de forma independente por diferentes linhas de negócios e combinada no mesmo ambiente quando implantada. Todos esses componentes são fortemente integrados para fornecer todas as funcionalidades em uma única unidade. Essa unidade possui todos os recursos necessários. A vantagem de uma aplicação monolítica é que ela é fácil de implantar e iterar. É adequada para empresas mais independentes com menos linhas de negócios.

À medida que os negócios desenvolvidos pelas empresas se tornam cada vez mais complexos, percebemos que serviços únicos não conseguem mais atender às necessidades de iteração rápida na vida real. Precisamos dividir esse sistema gigante e garantir que as chamadas entre as funções existentes possam ser realizadas normalmente. Para resolver esse problema, o ESB (Enterprise Service Bus) surgiu.

O "barramento de serviços corporativos" é um pipeline que conecta vários serviços empresariais. A existência do ESB é integrar diferentes serviços com diferentes protocolos. O ESB fornece serviços como tradução e roteamento de solicitações de clientes, para que diferentes serviços possam se interconectar facilmente. Como o nome sugere, seu conceito é inspirado no modelo de comunicação no princípio da composição de computadores - o barramento, onde todos os sistemas que precisam se comunicar com sistemas externos se conectam ao ESB. Você pode usar o sistema existente para construir um novo sistema distribuído heterogêneo e fracamente acoplado.

O ESB traduziu e roteou as solicitações para que diferentes serviços pudessem se comunicar entre si. O método tradicional de invocação de serviço do ESB é que, a cada vez, o chamador deve primeiro ser roteado pelo ESB central para o serviço.

Arquitetura Monolítica

A autenticação do usuário e o gerenciamento de sessão são relativamente simples: a autenticação e a autorização ocorrem na mesma aplicação, geralmente usando um esquema de autenticação baseado em sessão. Uma vez autenticado, uma sessão é criada e armazenada no servidor. Qualquer componente pode acessá-la e usá-la para notificar e autorizar solicitações subsequentes. O ID da sessão é enviado ao cliente e usado para associar todas as solicitações subsequentes à sessão atual.

Arquitetura ESB

Na arquitetura ESB, todos os processos entre serviços são processados pelo barramento ESB. Como a arquitetura ESB deriva da arquitetura monolítica, o método de autenticação não mudou em comparação com a arquitetura monolítica.

Serviço de Autenticação na Arquitetura de Microsserviços

A migração de uma arquitetura monolítica para uma arquitetura de microsserviços traz muitas vantagens. No entanto, como uma arquitetura distribuída, a arquitetura de microsserviços tem uma superfície de ataque maior, tornando mais desafiador compartilhar o contexto do usuário. Portanto, diferentes serviços de autenticação são necessários na arquitetura de microsserviços para responder a desafios de segurança mais significativos.

Podemos dividir os serviços de autenticação na arquitetura de microsserviços nas seguintes três categorias:

1. Implementar autenticação em cada microsserviço
2. Implementar autenticação por meio de um serviço de autenticação
3. Implementar autenticação por meio do gateway de API

Cada abordagem tem suas vantagens e desvantagens específicas.

Implementar Autenticação em Cada Microsserviço

Como cada microsserviço é dividido da arquitetura monolítica, uma transição natural para implementar a autenticação é que cada microsserviço a implemente por conta própria.

Cada microsserviço deve implementar suas próprias garantias de segurança, aplicadas em cada ponto de entrada. Essa abordagem capacita as equipes de microsserviços a tomar decisões autônomas sobre a implementação de suas soluções de segurança. No entanto, essa abordagem tem várias desvantagens:

• A lógica de segurança precisa ser implementada repetidamente em cada microsserviço. Isso leva à duplicação de código entre serviços.
• Distrai a equipe de desenvolvimento do foco em seu serviço principal.
• Cada microsserviço depende de dados de autenticação do usuário que não possui.
• Difícil de manter e monitorar.

Uma opção para melhorar essa solução é usar uma biblioteca de autenticação compartilhada carregada em cada microsserviço. Isso evitará a duplicação de código, e a equipe de desenvolvimento se concentrará apenas em seu domínio de negócios. No entanto, ainda há deficiências que essa melhoria não pode resolver. Como a biblioteca de autenticação compartilhada ainda precisa ter os dados de identidade do usuário correspondentes, também é necessário garantir que cada microsserviço use a mesma versão da biblioteca de autenticação. A biblioteca de autenticação compartilhada é mais como o resultado de uma divisão ruim de serviços.

Vantagens: implementação rápida, forte independência

Desvantagens: duplicação de código entre serviços; violação do princípio da responsabilidade única; dificuldade de manutenção

Implementar Autenticação por Meio de um Serviço de Autenticação

Como é difícil para cada microsserviço implementar a autenticação por si só, e usar uma biblioteca de autenticação compartilhada viola a intenção original da divisão de microsserviços, podemos atualizar a biblioteca de autenticação compartilhada para um serviço de autenticação dedicado?

Nesse caso, todo o acesso é controlado pelo mesmo serviço, semelhante à função de autenticação em uma aplicação monolítica. Cada serviço de negócios deve enviar uma solicitação de autorização separada ao módulo de controle de acesso ao realizar uma operação.

No entanto, essa abordagem retarda o serviço e aumenta a interconexão entre os serviços. E cada microsserviço dependerá desse serviço de autenticação "único". Ele é vulnerável a um ponto único de falha e a uma reação em cadeia que causa danos adicionais.

Vantagens: Cada microsserviço tem uma única responsabilidade, e a autenticação é centralizada

Desvantagens: Ponto único de falha; aumento da latência das solicitações

Implementar Autenticação por Meio do Gateway de API

Ao migrar para uma arquitetura de microsserviços, uma questão que precisa ser respondida é como os microsserviços se comunicam entre si. O ESB mencionado acima é uma abordagem, mas mais comumente, um gateway de API é empregado. O gateway de API é um ponto de entrada único para todas as solicitações. Ele fornece flexibilidade ao atuar como uma interface central para consumir esses microsserviços. Um microsserviço que precisa acessar outros microsserviços (a partir de agora, nos referiremos a ele como "cliente" para distingui-lo do microsserviço que ele acessa) não tem acesso direto aos serviços, mas envia a solicitação ao gateway de API responsável por rotear o cliente para o serviço upstream.

Como todas as solicitações devem passar primeiro pelo gateway de API, ele é um excelente candidato para impor questões de autenticação. Ele reduz a latência (chamadas para serviços de autenticação) e garante que o processo de autenticação seja consistente em toda a aplicação.

Por exemplo, usando o plugin jwt-auth do APISIX, podemos implementar a autenticação no gateway.

1. Devemos configurar várias informações de identidade do usuário (nome, chave, etc.) no APISIX.
2. De acordo com a chave do usuário fornecida, iniciamos uma solicitação de assinatura para o APISIX para obter o token JWT do usuário.
3. Então, quando o cliente precisa acessar um serviço upstream, ele traz o token JWT, e o APISIX atua como o gateway de API para intermediar esse acesso.
4. Finalmente, o APISIX completará a operação de autenticação usando o token JWT.

Claro, tudo tem vantagens e desvantagens, e nenhuma tecnologia é completa sem desvantagens. Usar um gateway de API para completar a autenticação ainda tem alguns problemas. Resolver esse problema no gateway é menos seguro do que completar a autenticação dentro de cada microsserviço. Por exemplo, se o gateway de API for comprometido, ele exporá todos os microsserviços por trás dele. Mas o risco é relativo. Comparado com o serviço de autenticação único, o problema de usar um gateway de API é leve.

Vantagens: Proteção eficaz dos microsserviços de backend; os microsserviços não precisam lidar com nenhuma lógica de autenticação

Desvantagem: Ponto único de falha

Resumo

Em diferentes cenários, precisaremos de diferentes esquemas de autenticação. Em uma aplicação monolítica, a autenticação acontece dentro da mesma aplicação, e o servidor salva todas as sessões. Na era dos microsserviços, as aplicações monolíticas evoluíram para serviços distribuídos, e os métodos tradicionais de autenticação não se aplicam. Na arquitetura de microsserviços, temos três métodos de autenticação para escolher:

1. Implementar autenticação em cada microsserviço
2. Implementar autenticação por meio de um serviço de autenticação
3. Implementar autenticação por meio do gateway de API

Cada opção tem suas próprias vantagens e desvantagens, que precisam ser analisadas detalhadamente de acordo com as circunstâncias.