Compartilhamento de Sessão em Sistemas Distribuídos

Em uma arquitetura distribuída, o compartilhamento de sessão permite que múltiplos servidores acessem os mesmos dados de sessão de um usuário. Tradicionalmente, esses dados ficam armazenados no servidor que processou a requisição, o que não funciona quando as requisições são direcionadas para nós diferentes.

Estratégias de Compartilhamento

Existem diversas abordagens para resolver este problema:

• Replicação de Sessão: Os dados da sessão são copiados para todos os nós. Garante disponibilidade, mas consome muitos recursos e pode causar problemas de consistência.
• Armazenamento Centralizado: As sessões são mantidas em um repositório único (ex.: Redis ou banco de dados), acessível por qualquer servidor. Oferece melhor escalabilidade e consistência.
• Sessões Adesivas: O balanceador de carga direciona todas as requisições de um usuário para o mesmo servidor. Simplifica o armazenamento, mas reduz a flexibilidade de escalonamento.
• Gerenciamento Distribuído: Utilização de sistemas especializados para gerenciar dados de sessão, oferecendo alta disponibilidade e segurança.

JWT: Autenticação Baseada em Token

O JSON Web Token (JWT) é um padrão aberto (RFC 7519) que define um método compacto e autônomo para transmitir informações entre duas partes como um objeto JSON. Essas informações são verificáveis digitalmente, pois são assinadas digitalmente.

Fluxo de Autenticação com JWT

O processo típico de autenticação segue estas etapas:

1. O cliente envia credenciais (nome de usuário e senha) para o endpoint de autenticação.
2. O servidor valida as credenciais. Se forem válidas, gera um JWT contendo informações relevantes e o retorna.
3. O cliente armazena o JWT (geralmente no armazenamento local ou em um cookie seguro).
4. Para acessar recursos protegidos, o cliente inclui o JWT no cabeçalho Authorization das requisições.
5. O servidor verifica a assinatura do JWT, sua validade (expiração) e os dados contidos.
6. Se a verificação for bem-sucedida, a requisição é processada.

Exemplo de cabeçalho de requisição:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Vantagens sobre Sessões Tradicionais

• Sem Estado (Stateless): O servidor não precisa armazenar informações de sessão. O token carrega todas as informações necessárias.
• Escalabilidade: Ideal para arquiteturas de microsserviços, pois qualquer serviço pode verificar o token independentemente.
• Suporte a Múltiplas Plataformas: Funciona igualmente bem em aplicações web, mobile e outros clientes.
• Segurança: Não depende de cookies, evitando ataques CSRF e problemas com restrições de origem cruzada (CORS).

Anatomia de um JWT

Um JWT é composto por três partes, separadas por pontos (.):

1. Cabeçalho (Header)

Especifica o algoritmo de assinatura e o tipo do token.

{
  "alg": "RS256",
  "typ": "JWT"
}

2. Carga Útil (Payload)

Contém as declarações (claims) sobre a entidade (geralmente, o usuário) e dados adicionais. Existem três tipos de declarações: registradas, públicas e privadas.

{
  "sub": "a3f1b2c4d5e6",
  "name": "Maria Silva",
  "admin": false,
  "iss": "auth.example.com",
  "exp": 1714523800
}

Atenção: A carga útil é apenas codificada em Base64, não criptografada. Evite incluir informações sensíveis como senhas.

3. Assinatura (Signature)

Criptografa o cabeçalho e a carga útil usando um segredo conhecido apenas pelo servidor. Garante a integridade do token.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  seu_segredo_super_secreto
)