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

JWT vs Autenticação de Sessão

Conheça 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 as 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 utilizador final fornece as suas credenciais de identidade para iniciar sessão com sucesso. Após este passo, o sistema de identidade (ou seja, o fornecedor de identidade, servidor de autenticação, etc.) sabe quem é o utilizador e a que recursos tem acesso.

Dado que o HTTP é inerentemente sem estado, cada pedido numa sessão é independente e não recorda informação de pedidos anteriores. Re-autenticar os utilizadores para cada ação é cansativo e prejudica a experiência do utilizador.

Vamos abordar a Autenticação baseada em sessão e a 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 está a decidir entre os dois, este guia está aqui para ajudar.

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

A autenticação baseada em sessão depende do servidor para manter um registo do estado de autenticação do utilizador. Ao criar e gerir sessões, o servidor permite que os utilizadores continuem a interagir com uma aplicação sem ter que reintroduzir as credenciais a cada pedido.

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

Criação de sessão

  1. O utilizador autentica-se e fornece algumas credenciais (por exemplo, email e senha).
  2. Se as credenciais forem válidas, o servidor cria um registo persistente que representa essa sessão. A sessão contém informações como uma string aleatória, identificador de utilizador, 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 utilizador como um cookie.

Validação da sessão

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

Como revogar uma sessão?

As sessões podem ser invalidadas em tempo real, o que é útil em situações onde é necessário uma revogação rápida do acesso.

  • Utilizadores fazem logout manualmente: O servidor apaga o registo da sessão, efetivamente fazendo o logout do utilizador.
  • Admins forçam o logout do utilizador: Admins ou sistemas podem terminar uma sessão específica ao apagá-la da base de dados. Por exemplo, durante uma violação de segurança.
  • Expiração das sessões: As sessões podem expirar automaticamente após uma determinada duração de inatividade, ou um limite de tempo fixo.

Vantagens da autenticação baseada em sessão

  • Simples e confiável: O registo da sessão fornece uma fonte clara e centralizada, permitindo um elevado grau de confiança e tornando as decisões de autorização mais confiáveis.
  • Revogação em tempo real: Ao eliminar ou invalidar o registo da sessão, o acesso de um utilizador pode ser rapidamente revogado.

Desvantagens da autenticação baseada em sessão

  • Latência em sistemas distribuídos: Manter dados de sessão em vários servidores exige sempre 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 a cada pedido realizado.
  • Alto consumo de recursos: Cada sessão ocupa recursos do servidor, impactando o desempenho quando a base de utilizadores aumenta.
  • Risco de segurança: O sequestro de sessão (via cookies de sessão roubados) pode permitir acesso não autorizado a contas de utilizadores.
  • Uso limitado para APIs: A autenticação baseada em sessão não é ideal para aplicações móveis. Armazena dados de sessão no servidor, o que pode aumentar a carga e a complexidade com muitos utilizadores. Além disso, usa cookies, que são mais difíceis de lidar em dispositivos móveis.

O que é autenticação JWT?

JSON Web Tokens (JWTs) adotam uma abordagem diferente ao incorporar todas as informações relevantes do utilizador 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 registos de autenticação.

Como funciona a autenticação JWT?

Um JWT consiste em três partes: um header, um payload e uma signature.

  • O header contém o algoritmo de assinatura (por exemplo, HS256) e o tipo de token (JWT).
  • O payload contém claims principais, como a identidade do utilizador, a função do utilizador e o tempo de expiração.
  • A signature usa uma chave para assinar o header e o payload, permitindo a verificação de se a assinatura foi adulterada.

image.png

Emissão de JWT

  1. O cliente envia credenciais do utilizador ao servidor de autenticação (um fornecedor de identidade universal é particularmente benéfico para gerenciar acessos em vários domínios).
  2. Após autenticação bem-sucedida, o servidor gera um JWT que inclui header, payload e signature.
  3. O AuthServer envia o token emitido para o 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 utilizador é armazenada no servidor dentro de uma sessão, enquanto os JWTs se baseiam em tokens enviados para o cliente para armazenamento e uso subsequente.

Validação do token

  1. Para pedidos API subsequentes, 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 claims (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 exige que o servidor consulte um armazenamento de sessão, o que pode ser lento, especialmente se depender 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 a assinatura para garantir a segurança. Isso elimina a necessidade de gestão de sessão, tornando-a mais rápida e escalável, especialmente em sistemas distribuídos.

Como revogar um JWT?

Do lado do cliente, sair normalmente significa limpar a sessão local e remover tokens (ID, acesso, token de atualização) do armazenamento. No entanto, para a autenticação JWT, isso apenas desconecta o utilizador localmente, deixando a sessão centralizada no servidor de autorização intacta. Consequentemente, os utilizadores ainda podem acessar outras aplicações na 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 os 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 de expiração curtos: Defina um claim exp curto (por exemplo, 15 minutos) para o JWT. Uma vez expirado, o utilizador deve se re-autenticar. Isso minimiza o risco caso um token seja comprometido, já que o atacante só pode usá-lo por um tempo limitado. Para manter uma experiência de utilizador perfeita, pode-se usar um token de atualização para minimizar o inconveniente da re-autenticação.
  • Lista negra de tokens: Para casos críticos (por exemplo, logout de utilizador, alterações de senha), mantenha uma lista negra de tokens revogados. O servidor verifica tokens recebidos contra esta lista e rejeita qualquer correspondência. Embora eficaz, essa abordagem requer o acompanhamento de tokens revogados, o que vai contra a natureza sem estado dos JWTs e pode tornar-se ineficiente se a lista crescer demasiado.
  • Endpoint de revogação: Introduza um endpoint de revogação no servidor de autorização onde tokens (por exemplo, tokens de atualização) podem ser invalidados. Uma vez revogado um token de atualização, 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ápida e mais informativa: A natureza auto-contida 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 claims personalizados (por exemplo, papéis de utilizador ou outros dados relevantes) dentro do token, permitindo que os servidores determinem papéis sem consultar uma base de dados.
  • Segurança aprimorada: Os JWTs usam técnicas de assinatura e criptografia, tornando os ataques mais difíceis.
  • Suporte a múltiplos domínios: Os JWTs são ideais para Single Sign-On (SSO) e autenticação entre domínios. Eles permitem que os utilizadores autentiquem-se através de múltiplos domínios ou serviços com o mesmo token.
  • Compatível com móvel: Os JWTs funcionam bem para aplicações móveis que precisam de autenticação sem estado. Os tokens podem ser armazenados do lado do cliente e enviados com cada pedido, melhorando a eficiência e a facilidade de uso.

Desvantagens da autenticação JWT

  • JWT não é atualizado em tempo real

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

    Se as permissões de acesso de um utilizador mudarem (geralmente diminuindo), o utilizador ainda terá acesso removido aos recursos até que o JWT expire. Da mesma forma, se um JWT contiver informações de autorização baseadas em papéis, o novo escopo de autorização não terá efeito até que o velho JWT expire. Em outras palavras, os JWTs não são adequados para revogação em tempo real e os utilizadores podem definir um tempo de expiração adequado para mitigar esta questão.

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

    Não é possível validar todos os JWTs emitidos antes que expirem para implementar a revogação de utilizador em todos os dispositivos. Embora seja teoricamente possível revogar a chave de assinatura para invalidar o JWT, isso também invalidaria todos os JWTs que usam essa chave, e o processo de manipulação de chaves de cache tornaria essa abordagem impraticável para operações simples de revogação de utilizador.

Alguns provedores de identidade podem ter soluções predefinidas para essas questões 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.

As sessões fornecem garantias mais fortes para a autorização de pedidos individuais e são mais simples de implementar de forma segura. No entanto, a sua dependência da validação de base de dados do lado do servidor introduz um overhead de latência, que pode impactar negativamente a experiência do utilizador para aplicações altamente responsivas.

Os JWTs, por outro lado, são vantajosos para uma autorização mais rápida e interoperabilidade com aplicações externas, mas exigem mais esforço do desenvolvedor para abordar as complexidades de segurança. Por exemplo, podemos usar webhooks para notificar os clientes quando o acesso do utilizador é revogado, de modo que os clientes possam limpar o JWT armazenado em cache e forçar o utilizador a se re-autenticar.

Uma vez que a autenticação baseada em token é mais adequada para escalar e as suas desvantagens ainda são gerenciáveis, ela é adotada por cada vez mais aplicações modernas.

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

O método de autenticação deve corresponder à arquitetura e necessidades específicas da sua aplicação. Aqui está um guia rápido para ajudá-lo 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 a escalabilidade não é uma grande preocupação. Aqui está 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 utilizadores, carrinhos de compras e preferências durante a visita deles.

  • 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 uma gestão de acesso robusta e segurança.

  • Sistemas de servidor único ou de pequena escala

    Ferramentas internas ou aplicações de pequena escala sem grandes necessidades de escalabilidade prosperam em gestão de sessão simples para facilidade de uso e confiabilidade.

Quando usar autenticação JWT

A autenticação JWT é mais adequada para aplicações 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 aos utilizadores autenticar-se uma vez e acessar perfeitamente múltiplos serviços ou aplicações usando o mesmo token. Compartilhe uma explicação detalhada sobre aplicações baseadas em nuvem seguras usando OAuth 2.0 e OIDC, com formato JWT tanto para tokens de acesso quanto para tokens de ID.

  • Aplicações móveis

    As aplicações móveis muitas vezes preferem JWTs para autenticação, já que os tokens podem ser armazenados de forma segura no dispositivo e enviados com cada pedido API. Explore a integração rápida da autenticação JWT para Android / iOS.

  • Arquiteturas de microserviços

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

  • Autenticação entre domínios

    Os JWTs sobressaem em cenários que envolvem 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 geralmente usam JWTs para autenticação porque são leves, portáteis, e eliminam a necessidade de gestão de sessão do lado do servidor. Saiba mais sobre autenticação máquina a máquina para cenários onde a sua aplicação precisa comunicar-se diretamente com recursos.

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

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

Lidando com problemas de logout de utilizador com JWT

Um problema comum com a autenticação JWT é garantir uma experiência adequada de logout do utilizador. Logto simplifica este processo com o seu SDK pronto para uso.

  • Ao limpar tokens e sessões locais do lado do cliente e redirecionar os utilizadores para o endpoint de fim de sessão do Logto, é possível encerrar facilmente as sessões tanto na aplicação cliente quanto no servidor.
  • Além disso, o Logto suporta o logout pelo canal de volta, permitindo que o AuthServer notifique todas as aplicações clientes que compartilham a mesma sessão quando um utilizador se desconecta.

Isso garante uma gestão de sessão consistente e segura em todo o seu ecossistema. Saiba mais sobre como lidar com o logout.

Lidando com alterações de permissões de utilizador

Gerir alterações em tempo real nas permissões de utilizador com JWT também pode ser complicado. Uma vez que os JWTs são sem estado por design, qualquer permissão ou função atualizada pode não ter efeito até que o token expire. Logto oferece estratégias para lidar com isso efetivamente:

  • Para diminuir permissões para este utilizador: Use tempos de expiração de token de acesso curtos ou verifique as permissões dinamicamente através de uma chamada API.
  • Para adicionar novas permissões para este utilizador: Atualize o AuthServer para incluir o novo escopo de permissão e obter novo consentimento dos utilizadores para aplicar essas alterações.

Essas soluções ajudam a manter as permissões atualizadas e garantem um sistema mais seguro e responsivo. Saiba mais sobre como lidar com alterações de permissões.

Logto, que é uma infra-estrutura escalável de gestão de acesso à identidade, fornece uma solução de identidade completa com serviço em nuvem e versão open-source disponíveis.