Será que ainda vale a pena usar JWT? 🚀

Essa é uma pergunta que frequentemente paira sobre meus pensamentos. Nos últimos dias, tenho refletido mais intensamente sobre isso, principalmente devido ao amplo uso do JWT que observei em sites de e-commerce, instituições financeiras e APIs de integração.

Tenho o costume de acessar o painel de desenvolvedor dos navegadores para investigar o tráfego de mensagens entre os sites e seus servidores. Gosto de observar quais informações estão sendo enviadas, armazenadas localmente, qual método de autenticação está sendo empregado e se o site adota alguns cuidados mínimos com a segurança. Acredito que esse hábito já me protegeu de alguns golpes.

Agora, retomando à questão principal, fico me perguntando quais motivos levaram à adoção de tokens JWT por sites e aplicativos que implementam sistemas de login, e geralmente exigindo um gerenciamento de permissões e controle de acesso mais elaborado. Do meu ponto de vista, essa não é a escolha mais acertada.

Antes de detalhar a razão dessa opinião, vamos relembrar alguns detalhes sobre os Tokens JWT.

O que é JWT?

O JSON Web Token (JWT) é um padrão aberto (RFC 7519) que define uma maneira compacta e autossuficiente para representar informações entre duas partes de uma forma que pode ser verificada e validada facilmente. Essa representação é baseada em objetos JSON e é frequentemente utilizada para transmitir informações de identidade e autenticação entre um servidor e um cliente.

Componentes básicos

Header

O cabeçalho de um JWT contém informações sobre como o token deve ser processado e geralmente consiste em dois partes: o tipo do token, que é JWT, e o algoritmo de assinatura utilizado, como por exemplo, HMAC SHA256 ou RSA.

{
    "alg": "HS256",
    "type": "JWT"
}        

Payload

O corpo carrega as reivindicações. As reivindicações são declarações sobre uma entidade (geralmente o usuário) e metadados adicionais. Existem três tipos de reivindicações: registradas, públicas e privadas. Reivindicações registradas são um conjunto fixo de informações, como "iss" (emissor), "exp" (data de expiração) e "sub" (sujeito).

{
    "client_id": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
    "response_type": "code",
    "scope": "introscpect_tokens, revoke_tokens",
    "iss": "bjhIRjM1cXpaa21zdWtISnp6ejlMbk44bTlNZjk3dXE=",
    "sub": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
    "aud": "https://localhost:8443/{tid}/{aid}/oauth2/authorize",
    "jti": "1516239022",
    "exp": "2021-05-17T07:09:48.000+0545"
}        

Signature

A assinatura é utilizada para verificar se o remetente do JWT é quem ele diz ser e para garantir que a mensagem não foi alterada ao longo do caminho. Ela é criada combinando o cabeçalho codificado, o corpo codificado e uma chave secreta (ou chave pública, no caso de assinaturas assimétricas).

Combinando os três componentes, um JWT completo se parece com algo assim:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbGllbnRfaWQiOiJZekV6TUdkb01ISm5PSEJpT0cxaWJEaHlOVEE9IiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJzY29wZSI6ImludHJvc2NwZWN0X3Rva2VucywgcmV2b2tlX3Rva2VucyIsImlzcyI6ImJqaElSak0xY1hwYWEyMXpkV3RJU25wNmVqbE1iazQ0YlRsTlpqazNkWEU9Iiwic3ViIjoiWXpFek1HZG9NSEpuT0hCaU9HMWliRGh5TlRBPSIsImF1ZCI6Imh0dHBzOi8vbG9jYWxob3N0Ojg0NDMve3RpZH0ve2FpZH0vb2F1dGgyL2F1dGhvcml6ZSIsImp0aSI6IjE1MTYyMzkwMjIiLCJleHAiOiIyMDIzLTEyLTE0VDA4OjA1OjUwLjAwMCswNTQ1In0.g1EMNjnEV7DWELJOhN2xXZtymBnQJxQXMK3OYDhAvt4        

Vantagens do uso do JWT ✨

A adoção de JSON Web Tokens (JWT) traz consigo muitas possiblidades. Porém gostaria de focar na principal vantagem desse método de autenticação que é a característica stateless, na qual elimina a necessidade de armazenamento de estado no servidor.

Essa abordagem simplifica a arquitetura e favorecendo a escalabilidade, uma vez que não é necessário recuperar informações de uma base de dados, cache ou outro meio para validar o token de autenticação. Em vez de realizar operações de I/O custosas, a validação da assinatura digital é executada de forma eficiente.

Apesar das aparentes vantagens, quero promover uma reflexão no contexto de um site de e-comerce, homebanking, APIs de integração ou qualquer outra solução que faça uso de "login".

Por que não usar o JWT? 🤔

Quando um site ou aplicativo demanda autenticação do usuário para acessar seus serviços, a gestão de RENOVAÇÃO e REVOGAÇÃO de acesso torna-se inevitável. Por exemplo, ao realizar o "logout" em um site de e-commerce, é essencial revogar o token de acesso. Da mesma forma, ao trocar a senha, todos os tokens válidos associados ao usuário precisam ser revogados e substituídos por um novo token.

A característica stateless do JWT se perde justamente durante a revogação de um token, uma vez que o tempo de expiração é estático e presente no payload do próprio token. E para suportar a revogação de tokens JWT, é necessário persistir temporariamente essa chave em um serviço de cache, que deve ser consultado a cada validação.

Então, além de ter que fazer essa consulta adicional, continua-se tendo que validar a assinatura do token, que, por se tratar de uma operação criptográfica, consome processamento.

Outro ponto desvantajoso no uso de tokens JWT é a necessidade de lidar com a chave privada usada para assinar o header e o corpo do token. Geralmente armazenada em serviços especializados como Key Vault ou Secrets Manager. O que força o processo de validação do token JWT a ter que solicitar essa chave privada. E mesmo que a solicitação seja feita ocasionalmente, ainda assim agrega complexidade.

Uma alternativa 🔄

Essa consideração me leva a questionar a escolha dos arquitetos ao optar por esse método de autenticação. Se a utilização de um serviço de cache (REDIS, Memcache, ...) para validar o token de autenticação já estava prevista, por que não explorar de maneira mais eficaz essa abordagem? Armazenar todas as informações de login do usuário na cache, vinculando esses dados a uma chave menor e aleatória, como um token Bearer, parece uma alternativa mais eficiente.

Nesse cenário, a validação do token se resumiria essencialmente à busca desse token no serviço de cache. Caso a chave exista e não tenha expirado, a consulta na cache automaticamente resgata o contexto daquele login/usuário.

Já para a revogação de um token de acesso, seria necessária apenas a remoção do token do serviço de cache.

Além disso, há o benefício indireto de menor tráfego de rede por usar uma chave menor e maior segurança e privacidade, uma vez que as informações antes trafegadas no payload do toke JWT agora passaria a ficar privada e de acesso exclusive ao backend.

Por fim

Diante das complexidades discutidas, surge uma reflexão pessoal sobre o JWT e sua aplicabilidade. A despeito dos desafios associados à revogação de tokens e à necessidade de gerenciar chaves privadas, acredito que o uso do JWT faria sentido se pudéssemos manter a tão valiosa característica stateless.

Seu Feedback é Valioso 📬

Não deixe de comentar se você concorda ou não.