Português (Portugal)
  • jwt
  • autenticação
  • sessão
  • token
  • revogar jwt

JWT vs autenticação de sessão

Aprenda as diferenças entre autenticação baseada em sessão e JWT. Explore os compromissos, vantagens e casos de uso para escolher o esquema de autenticação adequado para suas aplicações.

Ran
Ran
Product & Design
Darcy Ye
Darcy Ye
Developer

De um modo geral, o primeiro passo ao usar uma aplicação é a autenticação, onde o usuário final fornece suas credenciais de identidade para fazer login com sucesso. Após esse passo, o sistema de identidade (ou seja, fornecedor de identidade, servidor de autenticação, etc.) sabe quem é o usuário e a que recursos ele tem acesso.

Dado que o HTTP é inerentemente sem estado, cada pedido numa sessão é independente e não recorda informações de pedidos anteriores. Re-autenticar os usuários para cada ação é complicado e prejudica a experiência do usuário.

Vamos falar sobre autenticação baseada em sessão e autenticação JWT (JSON Web Tokens), dois métodos populares para manter o estado de autenticação. Cada um tem vantagens e compromissos únicos, e a escolha entre eles depende das necessidades específicas da sua aplicação. Se você está decidindo entre os dois, este guia está aqui para ajudar.

O que é a autenticação baseada em sessão?

A autenticação baseada em sessão depende do servidor para manter um registro do estado de autenticação do usuário. Criando e gerenciando sessões, o servidor permite que os usuários permaneçam conectados e continuem interagindo com uma aplicação sem precisar digitar as credenciais a cada solicitação.

Como funciona a autenticação baseada em sessão?

Criação de sessão

  1. Um usuário se autentica e fornece algumas credenciais (por exemplo, e-mail e senha).
  2. Se as credenciais são válidas, o servidor cria um registro persistente representando essa sessão. A sessão contém informações como uma string aleatória, identificador do usuário, tempo de início da sessão, tempo de expiração da sessão, etc.
  3. O SessionID é armazenado na base de dados e retornado ao cliente do usuário como um cookie.

Validação de sessão

  1. O processo pode ser acionado manualmente pelo usuário (por exemplo, clicando numa aba, atualizando uma página) ou automaticamente pelo cliente (por exemplo, durante carregamentos iniciais de página ou via chamadas API com um SessionID).
  2. Cada chamada subsequente envia um pedido HTTP do cliente contendo o cookie de sessão para o servidor.
  3. O servidor valida o SessionID consultando os dados da sessão armazenados no servidor.
  4. Se válido, o servidor processa o pedido e autoriza o usuário.

Como revogar uma sessão?

Sessões podem ser invalidadas em tempo real, o que é útil em situações em que a revogação rápida de acesso é necessária.

  • Usuários fazem logout manualmente: O servidor apaga o registro de sessão, efetivamente desconectando o usuário.
  • Admins forçam logout do usuário: Administradores ou sistemas podem terminar sessões específicas deletando-as da base de dados. Por exemplo, durante uma violação de segurança.
  • Expiração de sessões: As sessões podem expirar automaticamente após uma duração definida de inatividade, ou um limite de tempo fixo.

Vantagens da autenticação baseada em sessão

  • Simples e confiável: O registro da sessão fornece uma fonte clara e centralizada, permitindo um alto grau de confiança e tomando decisões de autorização mais confiáveis.
  • Revogação em tempo real: Ao deletar ou invalidar o registro da sessão, o acesso de um usuário pode ser rapidamente revogado.

Desvantagens da autenticação baseada em sessão

  • Latência em sistema distribuído: Manter dados de sessão em vários servidores sempre requer a sincronização de um armazenamento de sessão. Isso introduz latência adicional porque o servidor tem que verificar o armazenamento de sessão cada vez que um pedido é feito.
  • Consumo elevado de recursos: Cada sessão ocupa recursos do servidor, impactando o desempenho quando a base de usuários se expande.
  • Risco de segurança: Sequestro de sessão (via cookies de sessão roubados) pode permitir acesso não autorizado a contas de usuários.
  • Uso limitado para APIs: A autenticação baseada em sessão não é ótima para aplicativos móveis. Armazena dados de sessão no servidor, o que pode aumentar a carga e complexidade com muitos usuários. Além disso, usa cookies, que são mais difíceis de manusear em dispositivos móveis.

O que é a autenticação JWT?

JSON Web Tokens (JWTs) adotam uma abordagem diferente, incorporando todas as informações relevantes do usuário diretamente num token, usando um objeto JSON. Ao contrário dos métodos baseados em sessão, os JWTs são sem estado, o que significa que o servidor não gerencia registros de autenticação.

Como funciona a autenticação JWT?

Um JWT consiste em três partes: cabeçalho, conteúdo, e assinatura.

  • O cabeçalho contém o algoritmo de assinatura (por exemplo, HS256) e o tipo do token (JWT).
  • O conteúdo contém as principais declarações, como a identidade do usuário, função do usuário e tempo de expiração.
  • A assinatura usa uma chave para assinar o cabeçalho e o conteúdo, permitindo verificar se a assinatura foi adulterada.

image.png

Emissão do JWT

  1. O cliente envia credenciais de usuário para o servidor de autenticação (Um fornecedor de identidade universal é particularmente benéfico para gerenciar acesso através de vários domínios.)
  2. Após a autenticação bem-sucedida, o servidor gera um JWT que inclui cabeçalho, conteúdo, e assinatura.
  3. O AuthServer envia o token emitido ao Cliente. O cliente armazena o JWT (por exemplo, em cookies, localStorage, ou sessionStorage).

Os fluxos baseados em sessão seguem um processo semelhante. No entanto, após a autenticação, a informação do usuário é armazenada no servidor dentro de uma sessão, enquanto os JWTs dependem de tokens enviados ao cliente para armazenamento e uso subsequente.

Validação do Token

  1. Para pedidos subsequentes de API, o cliente envia o JWT no cabeçalho Authorization (Bearer <token>).
  2. O servidor verifica a assinatura do JWT usando uma chave secreta ou pública e verifica suas declarações (por exemplo, expiração, emissor).
  3. Se o token for válido, o servidor concede ao cliente acesso aos recursos solicitados.

A autenticação baseada em sessão requer que o servidor consulte um armazenamento de sessão, o que pode ser lento, especialmente se depende de bases de dados externas ou centralizadas. Em contraste, a autenticação JWT é sem estado, com todas as informações necessárias armazenadas no token do cliente, e utiliza assinatura para garantir a segurança. Isso elimina a necessidade de gerenciamento de sessões, tornando-o mais rápido e escalável, especialmente em sistemas distribuídos.

Como revogar um JWT?

No lado do cliente, sair geralmente significa limpar a sessão local e remover tokens (ID, acesso, token de atualização) do armazenamento. No entanto, para autenticação JWT, isso apenas desconecta o usuário localmente, deixando a sessão centralizada no servidor de autorização intacta. Como resultado, os usuários ainda podem acessar outras aplicações sob a mesma sessão até que o token expire ou seja manualmente terminado.

Revogar um JWT (JSON Web Token) é mais desafiador do que a autenticação baseada em sessão porque JWTs são sem estado e não podem ser invalidados uma vez emitidos, a menos que estratégias específicas sejam implementadas. Métodos comuns incluem:

  • Tempos curtos de expiração: Define uma declaração exp curta (por exemplo, 15 minutos) para o JWT. Uma vez expirado, o usuário deve re-autenticar. Isso minimiza o risco se um token for comprometido, já que o atacante só pode usá-lo por um tempo limitado. Para manter uma experiência de usuário contínua, o token de atualização pode ser usado para minimizar o inconveniente da re-autenticação.
  • Lista negra de tokens: Para casos críticos (por exemplo, logout do usuário, mudanças de senha), mantenha uma lista negra de tokens revogados. O servidor verifica os tokens recebidos contra esta lista de bloqueio e rejeita qualquer correspondência. Embora eficaz, essa abordagem requer rastrear tokens revogados, o que vai contra a natureza sem estado dos JWTs e pode se tornar ineficiente se a lista crescer muito.
  • Ponto de revogação: Introduza um ponto de revogação no servidor de autorização onde tokens (por exemplo, tokens de atualização) possam ser invalidados. Uma vez que um token de atualização é revogado, qualquer token de acesso emitido a partir dele não será mais renovado. Este método funciona bem em fluxos OAuth2.

Vantagens da autenticação JWT

  • Rápido e mais informativo: A natureza autocontida dos JWTs torna a verificação do lado do cliente mais rápida e eficiente, sem a necessidade de interação com o servidor. Eles também podem incluir declarações personalizadas (por exemplo, funções de usuário ou outros dados relevantes) dentro do token, permitindo que os servidores determinem funções sem consultar uma base de dados.
  • Segurança aprimorada: JWTs usam técnicas de assinatura e criptografia, dificultando ataques.
  • Suporte a múltiplos domínios: JWTs são perfeitos para Single Sign-On (SSO) e autenticação entre domínios. Permitem que os usuários autentiquem através de múltiplos domínios ou serviços com o mesmo token.
  • Amigável a dispositivos móveis: JWTs funcionam muito bem para aplicações móveis que precisam de autenticação sem estado. Os tokens podem ser armazenados no lado do cliente e enviados a cada requisição, aumentando a eficiência e facilidade de uso.

Desvantagens da autenticação JWT

  • JWT não é atualizado em tempo real

    Uma vez que um JWT é assinado, ele não pode ser revogado ou atualizado, e será considerado válido enquanto a assinatura for válida e não tiver expirado.

    Se as permissões de acesso de um usuário mudam (geralmente são degradadas), o usuário ainda terá acesso removido aos recursos até que o JWT expire. Da mesma forma, se um JWT contém informações de autorização baseadas em funções, o novo escopo de autorização não entrará em vigor até que o antigo JWT expire. Em outras palavras, os JWTs não são adequados para revogação em tempo real e os usuários podem definir um tempo de expiração apropriado para mitigar esse problema.

  • Dilema de múltiplos dispositivos e revogação

    Não é possível validar todos os JWTs emitidos antes de expirarem para implementar a revogação de usuário em todos os dispositivos. Embora seja teoricamente possível revogar a chave de assinatura para tornar o JWT inválido, isso também invalidaria todos os JWTs usando essa chave, e o processo de gerenciamento de chaves de cache tornaria essa abordagem impraticável para operações simples de revogação de usuário.

Alguns fornecedores de identidade podem ter soluções pré-construídas para esses problemas de JWT. Para mais informações, confira "Melhores Práticas para Melhorar a Experiência de Autenticação JWT."

Qual a diferença entre JWT e Sessão?

Sessões e JWTs são duas abordagens populares para persistir o contexto de autenticação e autorização num mundo HTTP sem estado. Embora ambas as abordagens tenham seus prós e contras, oferecem diferentes benefícios e desvantagens.

Sessões, fornecem garantias mais fortes para autorização de pedido individual e são mais simples de implementar com segurança. No entanto, sua dependência de validação de base de dados no lado do servidor introduz um custo de latência, que pode impactar negativamente a experiência do usuário para aplicativos altamente responsivos.

JWTs, por outro lado, são vantajosos para uma autorização mais rápida e interoperabilidade com aplicativos externos, mas requerem mais esforço do desenvolvedor para abordar complexidades de segurança. Por exemplo, podemos usar webhooks para notificar os clientes quando o acesso do usuário é revogado, para que os clientes possam limpar o JWT em cache e forçar o usuário a re-autenticar.

Como a autenticação baseada em token é mais adequada para escalabilidade, com desvantagens ainda gerenciáveis, está sendo adotada por mais e mais aplicações modernas.

Sessão vs. JWT: Escolhendo o método certo

Seu método de autenticação deve corresponder à arquitetura da sua aplicação e necessidades específicas. Aqui está um guia rápido para te ajudar a decidir:

Quando usar autenticação baseada em sessão

A autenticação baseada em sessão funciona melhor quando você precisa de controle de sessão em tempo real, precisa de gestão centralizada, ou escalabilidade não é uma grande preocupação. Aqui é onde ela se destaca:

  • Aplicações web com sessões persistentes

    Para plataformas como sites de compras online, as sessões são essenciais para rastrear usuários, carrinhos de compras, e preferências durante sua visita.

  • Aplicações que requerem controle de sessão em tempo real

    Aplicações como serviços bancários ou financeiros beneficiam de dados de sessão controlados pelo servidor, garantindo gestão de acesso robusta e segurança.

  • Sistemas de servidor único ou de pequeno porte

    Ferramentas internas ou aplicativos de pequeno porte sem grandes necessidades de escalabilidade prosperam com a gestão simples de sessões para facilidade de uso e confiabilidade.

Quando usar autenticação JWT

A autenticação JWT é mais adequada para aplicativos que priorizam escalabilidade, eficiência, e sistemas distribuídos. É particularmente útil para interações sem estado entre clientes e servidores. Considere a autenticação baseada em token para o seguinte:

  • Single Sign-On (SSO)

    Os JWTs são perfeitos para Single Sign-On, permitindo que usuários autentiquem uma vez e acessem sem problemas múltiplos serviços ou aplicativos usando o mesmo token. Compartilhe uma explicação detalhada sobre aplicações seguras baseadas em nuvem usando OAuth 2.0 e OIDC, com formato JWT para ambos tokens de acesso e tokens de ID.

  • Aplicações móveis

    Aplicativos móveis muitas vezes preferem JWTs para autenticação, já que tokens podem ser armazenados com segurança no dispositivo e enviados com cada pedido à API. Explore a integração rápida de autenticação JWT para Android / iOS.

  • Arquiteturas de microsserviços

    Em ambientes de microsserviços, os JWTs permitem que cada serviço valide o token de forma independente, sem depender de um armazenamento de sessão central, garantindo escalabilidade e eficiência.

  • Autenticação entre domínios

    Os JWTs se destacam em cenários envolvendo múltiplos domínios ou subdomínios (por exemplo, api.example.com, dashboard.example.com, e docs.example.com). Ao contrário dos cookies, os JWTs permitem autenticação entre domínios sem dependências adicionais.

  • APIs e serviços web

    APIs RESTful e serviços web comumente usam JWTs para autenticação porque são leves, portáteis, e eliminam a necessidade de gestão de sessão no lado do servidor. Saiba mais sobre autenticação máquina-a-máquina em cenários onde seu aplicativo precisa comunicar diretamente com recursos.

Melhores práticas para melhorar a experiência de autenticação JWT

A autenticação JWT é uma ótima ferramenta, mas pode enfrentar desafios que afetam a experiência do usuário. Logto oferece uma solução fácil e confiável para superar esses obstáculos, tornando-se uma escolha principal para autenticação segura e eficiente.

Lidando com problemas de saída de usuário com JWT

Um problema comum com a autenticação JWT é garantir uma experiência adequada de saída de usuário. Logto simplifica este processo com seu SDK pré-configurado.

  • Ao limpar tokens e sessões locais no lado do cliente e redirecionar os usuários para o endereço final de sessão do Logto, você pode facilmente terminar sessões tanto na aplicação cliente quanto no servidor.
  • Além disso, o Logto suporta logout pelo canal de fundo, permitindo que o AuthServer notifique todas as aplicações cliente que compartilham a mesma sessão quando um usuário faz logout.

Isso garante gestão de sessão consistente e segura em todo o seu ecossistema. Saiba mais sobre mecanismos de saída e como implementar a saída.

Lidando com mudanças de permissões de usuário

Gerenciar mudanças em tempo real nos permissões de usuários com JWT também pode ser complicado. Como JWTs são projetados para ser sem estado, qualquer permissões ou funções atualizadas podem não surtir efeito até que o token expire. Logto oferece estratégias para lidar com isso de forma eficaz:

  • Para diminuir permissões desse usuário: Use tempos de expiração curtos para tokens de acesso ou verifique dinamicamente permissões via um pedido API.
  • Para adicionar novas permissões a esse usuário: Atualize o AuthServer para incluir o novo escopo de permissões e reconsenta usuários para aplicar essas mudanças.

Essas soluções ajudam a manter permissões atualizadas e garantem um sistema mais seguro e responsivo. Saiba mais sobre gerenciar mudanças em tempo real para permissões de usuários.

Logto, que é uma infraestrutura escalável de gestão de acesso à identidade, fornece uma solução completa de identidade com ambos serviço em nuvem e versão de código aberto disponíveis.