Arquitetura Stateless e Stateful

Refere-se ao estado da aplicação, ou seja, à condição ou qualidade dela em um determinado momento. Em uma autenticação stateless, não existe uma sessão ou usuário armazenado, contendo apenas conteúdos estáticos. Isso difere do stateful, que se trata de um conteúdo dinâmico.

Um processo stateless é um recurso isolado, que não faz referência a nenhum outro serviço ou interação com outro sistema. Ele opera apenas naquela parte do código, sem trazer informações de transações antigas, pois a autenticação stateless não armazena esse tipo de dado; cada operação é feita do zero.

A autenticação stateful permite que as informações sejam utilizadas mais de uma vez e são executadas com base no contexto das transações anteriores. Por isso, em aplicações onde se necessita aguardar uma resposta ou um dado preexistente, seja ele presente em outro sistema ou base de dados, utiliza-se o stateful.

Autenticação Stateless

A autenticação stateless consiste em uma estratégia na qual, após informar as credenciais, o usuário recebe um token de acesso como resposta. Esse token já contém todas as informações necessárias para identificar o usuário que o gerou, sem a necessidade de consultar continuamente o serviço que emitiu o token ou uma base de dados.

Esse token é armazenado do lado do cliente (navegador), de modo que o servidor só tem a capacidade de verificar a validade do token, confirmando se o payload e a assinatura correspondem.

JWT de autenticação Stateless

JSON Web Token (JWT) são chaves com padrões estabelecidos na RFC-7519, contendo uma entidade em forma de declarações, que são independentes, sem a necessidade de chamar o servidor para revalidar o token.

São strings codificadas no padrão base64 por meio de uma secret key, como no exemplo:

Vantagens e Desvantagens

Vantagens:

• Baixo consumo de memória do servidor.
• Excelente em termos de escalabilidade.
• Ideal para aplicações distribuídas, como APIs e microsserviços.
• Geração e distribuição do token em uma aplicação isolada, sem dependência de terceiros.
• Facilidade na interpretação e validação dos dados do usuário do token.

Desvantagens:

• Dificuldade no controle de acesso.
• Não é possível revogar o token a qualquer momento com facilidade.
• Pode facilitar a entrada de terceiros mal-intencionados, caso alguém tenha acesso ao token.
• A sessão não pode ser alterada até a expiração do token.
• O token JWT é mais complexo e pode se tornar desnecessário em aplicações centralizadas, como monolitos.

Autenticação Stateful

Comumente utilizada em várias aplicações, principalmente naquelas que não exigem tanta escalabilidade, a sessão com estado é criada no back-end da aplicação, e a referência da sessão é enviada de volta ao usuário correspondente. Cada vez que o usuário faz uma requisição, uma parte da aplicação gera o token. A partir desse momento, a cada nova requisição, esse token será enviado novamente para a aplicação para revalidar o acesso. Nesse modelo, caso haja alguma alteração nos dados do usuário, o token pode ser facilmente revogado.

São tokens de acesso opacos, ou seja, uma string simples de formato proprietário que não contém qualquer identificador ou dado do usuário referente àquele token. O destinatário precisa chamar o servidor que criou o token para validá-lo.

Exemplo de token: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

Esse ID deve ser armazenado em alguma base de dados junto ao usuário proprietário do token.

Vantagens e Desvantagens

Vantagens:

• Lógica de implementação centralizada.
• Gestão e controle de acesso simplificados.
• Excelente para monolitos, aplicações MVC e processos internos.
• Mais seguro contra terceiros mal-intencionados.

Desvantagens:

• Pode ocorrer uma sobrecarga na API responsável por validar o token.
• Falha no quesito escalabilidade.
• Maior dificuldade em distribuir a autenticação entre microsserviços.
• Em uma aplicação distribuída, caso o serviço de autenticação falhe, todos os outros serviços ficam indisponíveis.
• Maior complexidade de implementação.
• Maior dificuldade de integração com sistemas de terceiros.

Quando utilizar cada abordagem?

Quando utilizar um Token JWT e Autenticação Stateless

• Quando é necessária maior performance sem a preocupação com a sobrecarga de uma API.
• Quando se tem várias comunicações distribuídas entre serviços.
• Quando é preciso identificar qual usuário está realizando uma ação no sistema em diferentes serviços.
• Quando não se pretende persistir dados de um usuário, apenas seu registro inicial.
• Se for preciso gerar acessos externos ao serviço.
• Se for necessário manipular os dados de quem está realizando uma determinada ação com o mínimo de impacto no sistema.

Quando utilizar um Token Opaco e Autenticação Stateful

• Se for necessário o controle total de acesso dos usuários de um sistema, principalmente para definição de hierarquia de acesso.
• Em uma aplicação centralizada, sem serviços distribuídos e sem comunicação com serviços externos.

Considerações Finais:

• Em alguns trechos, como "estrese da API", o termo pode ser substituído por "sobrecarga da API" para maior clareza.
• A seção sobre "Token JWT" poderia incluir uma explicação mais detalhada sobre o que são as "declarações" mencionadas na RFC-7519, caso o público-alvo precise de mais contexto.
• Na seção sobre autenticação stateful, a frase "uma parte de aplicação irá gerar o token" poderia ser esclarecida explicando qual parte específica da aplicação é responsável por isso.