JWT não é sessão: expiração, refresh e revogação

JWT não é sinônimo de sessão. A RFC 7519 define JSON Web Token como um formato compacto para representar claims entre partes. Ele pode ser usado como credencial dentro de uma sessão autenticada, por exemplo como access token, mas o padrão JWT não define sozinho login, duração da sessão, logout, renovação ou revogação. Essas regras pertencem à arquitetura de autenticação e autorização.

A consequência prática é importante: um JWT continuar válido até seu campo de expiração não significa que a aplicação precise considerar a sessão do usuário ativa até aquele instante, e um usuário clicar em "sair" não torna automaticamente inválida toda cópia de um JWT já emitido. Para entender o ciclo completo, é preciso separar quatro conceitos: token, sessão, expiração e revogação.

JWT, sessão, access token e refresh token não são a mesma coisa

Elemento	O que representa	Quem normalmente valida ou usa	O que não resolve sozinho
JWT	Um formato para transportar um conjunto de claims, protegido por JWS ou JWE conforme o caso.	A parte que recebe o token e aplica as regras de validação do perfil usado.	Não define política de sessão, logout, armazenamento ou revogação.
Sessão autenticada	O estado lógico em que a aplicação reconhece uma identidade autenticada e aplica um ciclo de vida.	Aplicação, servidor de autorização e outros componentes envolvidos no estado autenticado.	Não exige JWT. Pode usar um identificador opaco associado a estado no servidor.
Access token	Credencial usada para acessar recursos protegidos. No OAuth 2.0, seu formato pode variar.	Resource server ou API.	Não é necessariamente JWT e não deve ser confundido com refresh token.
Refresh token	Credencial usada para obter novos access tokens quando o atual expira ou deixa de ser válido.	Authorization server. A RFC 6749 diz que ele não é enviado aos resource servers.	Não autoriza diretamente uma chamada normal à API e sua emissão é opcional.

Isso também evita uma frase enganosa: "autenticação JWT" pode descrever uma arquitetura que usa JWTs como credenciais, mas JWT é o formato do token, não o protocolo completo de autenticação nem a sessão em si. Um sistema pode ter sessão com cookie e identificador opaco, access token JWT, access token opaco, ou combinações diferentes.

O que a expiração de um JWT realmente faz

O claim exp da RFC 7519 identifica o instante a partir do qual o JWT não deve mais ser aceito para processamento. A especificação permite pequena tolerância para diferenças de relógio, e o uso de exp é opcional no padrão geral, embora perfis e aplicações normalmente imponham regras próprias.

Esse mecanismo responde a uma pergunta específica: "este token ainda está dentro da janela temporal em que pode ser aceito?". Ele não responde, por si só, a "o usuário ainda está logado?", "o usuário clicou em sair?", "a conta foi bloqueada?", "a senha foi trocada?" ou "um administrador encerrou todas as sessões?". Essas decisões exigem estado ou sinais adicionais na arquitetura.

Imagine um access token JWT válido por dez minutos. Se o usuário sair no segundo minuto e a API só verificar assinatura, emissor, audiência e exp, uma cópia desse token que já tenha sido obtida pode continuar sendo aceita até o fim da janela. Para interromper o uso antes da expiração é necessário algum mecanismo de revogação, checagem de estado ou uma credencial de sessão cuja validade possa ser encerrada no servidor.

O fluxo arquitetural: login, access token, expiração, refresh e revogação

Login: a aplicação autentica o usuário e estabelece o estado necessário para aquele desenho, que pode incluir uma sessão no servidor, emissão de tokens ou ambos.
Access token: o cliente recebe uma credencial para acessar a API. Se ela for um JWT, a API valida não apenas o tempo, mas também as regras criptográficas e os claims exigidos pelo perfil.
Uso normal: enquanto o token for aceitável, ele pode autorizar chamadas dentro dos privilégios, audiência e demais restrições estabelecidas.
Expiração: quando exp é atingido, aquele JWT deixa de ser aceito. Isso encerra a utilidade daquela credencial específica, não necessariamente toda a experiência autenticada.
Refresh: se a arquitetura usar refresh token e ele continuar válido, o cliente pode pedir um novo access token ao authorization server sem repetir imediatamente todo o login.
Revogação ou logout: a arquitetura invalida a sessão ou as credenciais relevantes no servidor. Dependendo do desenho, isso pode incluir revogar refresh tokens, marcar identificadores como inválidos, encerrar uma sessão server-side ou consultar um estado de revogação.

Portanto, expiração e logout são eventos diferentes. Expiração é uma regra temporal de aceitação de uma credencial. Logout é uma ação do ciclo de sessão que deve provocar invalidação adequada do estado ou das credenciais que permitiriam continuar autenticado.

Onde entra o refresh token

No OAuth 2.0, refresh tokens são credenciais usadas para obter novos access tokens. Eles costumam ter vida mais longa que o access token e ficam expostos a um risco diferente: se um refresh token for roubado e continuar utilizável, o atacante pode conseguir novas credenciais mesmo depois de access tokens antigos expirarem.

Por isso, o refresh token não deve ser tratado apenas como "um JWT que dura mais". Seu formato é separado da função que exerce. A RFC 6749 observa que ele costuma ser opaco para o cliente, e a RFC 9700, atual Best Current Practice de segurança do OAuth 2.0, exige para clientes públicos proteção contra replay por meio de refresh tokens vinculados ao remetente ou rotação de refresh token.

Na rotação, cada uso bem-sucedido produz um novo refresh token e invalida o anterior, mantendo no servidor informação suficiente para detectar reutilização indevida. Isso reintroduz estado deliberadamente no authorization server, o que é uma escolha de segurança e de controle de ciclo de vida, não uma falha do modelo.

Revogação: como encerrar validade antes do relógio

Revogar significa tornar uma credencial ou autorização inutilizável antes de ela se tornar inválida apenas pelo tempo. Existem estratégias diferentes, e cada uma muda o equilíbrio entre simplicidade, escalabilidade e controle imediato.

Sessão com estado no servidor

O cliente mantém um identificador, normalmente em cookie, e o servidor consulta um registro de sessão. Logout pode invalidar esse registro imediatamente. A vantagem é controle central; o custo é manter e consultar estado de sessão.

Access token JWT curto sem checagem de revogação

A API consegue validar localmente o token, o que reduz dependência de uma consulta central em cada requisição. Em contrapartida, a revogação imediata é limitada: um token copiado tende a continuar utilizável até expirar. Reduzir a vida do access token diminui essa janela, mas não a transforma em zero.

JWT com lista ou status de revogação

A aplicação pode manter estado de revogação, por exemplo associado a um identificador de token, ou consultar um mecanismo de status. A OWASP descreve denylist como uma forma de tratar o problema de invalidação em arquiteturas com JWT, ao mesmo tempo em que alerta que a implementação precisa considerar detalhes como identificadores adequados e validação estrita.

Revogação no OAuth 2.0

A RFC 7009 define um endpoint pelo qual o cliente informa ao authorization server que um token não é mais necessário. A especificação exige suporte à revogação de refresh tokens e recomenda suporte à revogação de access tokens. O efeito exato pode depender do tipo de token e da política do servidor.

Troca de chave não é um mecanismo de logout individual

Rotacionar ou retirar uma chave de assinatura pode invalidar muitos tokens de uma vez e é útil para gestão criptográfica ou resposta a comprometimento. Como estratégia de logout de um único usuário, porém, é grosseira demais porque afeta todos os tokens dependentes daquela chave.

Trade-offs dos desenhos mais comuns

Desenho	Estado central	Logout imediato	Vantagem principal	Custo principal
Cookie + sessão server-side	Sim	Direto, ao invalidar a sessão	Controle simples do ciclo de vida	Armazenamento e consulta de sessão
Access token JWT autocontido, sem revogação	Pouco durante a validação do access token	Não para uma cópia já emitida, salvo medidas adicionais	Validação local e desacoplada	Janela até a expiração
JWT curto + refresh token controlado no servidor	Sim no fluxo de refresh	Pode bloquear novas renovações; access tokens atuais ainda dependem de sua janela ou de revogação adicional	Combina access tokens curtos com sessão renovável	Mais componentes e políticas de rotação, armazenamento e revogação
JWT + checagem de status ou denylist	Sim	Pode ser rápido conforme a checagem	Revogação antes de exp	Perde parte do benefício de validação totalmente local e exige gestão de estado

Não existe um desenho universalmente melhor. Uma API interna, um aplicativo bancário, uma aplicação web tradicional e um ecossistema distribuído têm diferentes requisitos de risco, latência, escala e capacidade de revogação. A decisão arquitetural deve começar pelo ciclo de vida desejado e pelas ameaças relevantes, não pela preferência por JWT como tecnologia.

Validar JWT é mais do que conferir expiração

Mesmo quando exp está correto, um JWT não deve ser aceito só porque ainda não expirou. A RFC 8725 exige validação apropriada dos algoritmos e operações criptográficas e orienta validar emissor e audiência quando aplicáveis. Perfis específicos também podem exigir tipo de token, subject, not-before, identificadores e outros claims.

Outro ponto importante é confidencialidade. Um JWT protegido por assinatura ou MAC pode ter integridade sem que seu conteúdo esteja secreto. A criptografia é uma propriedade distinta. Portanto, a aplicação não deve assumir que qualquer informação colocada em um JWT assinado ficará oculta do cliente ou de quem obtiver o token.

Perguntas que ajudam a diagnosticar a arquitetura

"Se o JWT expirou, o usuário foi deslogado?" Não necessariamente. O access token expirou, mas uma sessão ou refresh token ainda pode permitir a emissão de outro.
"Se eu apagar o token do navegador, fiz logout?" Isso remove a cópia local, mas não garante que outras cópias já obtidas tenham sido invalidadas no servidor.
"Refresh token precisa ser JWT?" Não. A função do refresh token não exige JWT, e o OAuth permite que sua representação seja opaca para o cliente.
"JWT deixa tudo stateless?" Não por definição. Revogação, refresh token, detecção de replay, sessões administrativas e outras políticas podem exigir estado no servidor.
"Um access token curto resolve revogação?" Ele limita a janela de exposição, mas não oferece invalidação imediata por si só.

O modelo mental mais seguro

Pense em JWT como um envelope padronizado de claims que pode ser usado por uma arquitetura maior. exp controla a validade temporal daquele envelope; o access token controla acesso a recursos conforme seu escopo e perfil; o refresh token permite pedir novas credenciais; e a sessão define o ciclo lógico de autenticação que a aplicação deseja manter.

Quando logout e revogação importam, a arquitetura precisa de um ponto de controle capaz de dizer "esta sessão ou esta autorização não vale mais", mesmo que alguma credencial ainda não tenha chegado ao horário de expiração. Essa separação entre formato de token e ciclo de vida é o que evita tratar JWT como se fosse, sozinho, um sistema completo de sessão.

JWT não é sessão: expiração, refresh token e revogação na arquitetura

JWT, sessão, access token e refresh token não são a mesma coisa

O que a expiração de um JWT realmente faz

O fluxo arquitetural: login, access token, expiração, refresh e revogação

Onde entra o refresh token