Você já parou para pensar que o usuário do seu sistema pode estar correndo um sério risco por causa de uma implementação incorreta de tokens de autenticação? Hoje vou abordar um tema que, muitas vezes, é negligenciado: a segurança em APIs REST usando JWT (JSON Web Tokens). Vou explicar por que o refresh token é tão importante para não expor seus usuários a ameaças. Se você quiser entender mais a fundo os fundamentos do JWT, recomendo conferir o vídeo que já produzi sobre o assunto . Lá, explico em detalhes como o token funciona por baixo dos panos. Neste post, vamos focar em um ponto prático muito relevante: como o seu usuário pode estar em risco e como resolver isso por meio do uso adequado de access tokens e refresh tokens.
Caso prefira, assista ao vídeo:
O problema de expiração do token e a experiência do usuário
Imagine o seguinte cenário: você acessa um site ou um aplicativo — pode ser de comércio eletrônico ou até o seu banco. Para visualizar suas informações pessoais, é necessário se autenticar, ou seja, inserir login e senha. Depois que o backend confirma esses dados, o sistema retorna um JWT (JSON Web Token) para seu navegador ou app cliente. De agora em diante, sempre que você precisar acessar algum recurso daquela aplicação (ver compras, ver pagamentos etc.), seu cliente (navegador ou app) envia esse token no cabeçalho de cada requisição. É assim que o servidor reconhece que você é você. Entretanto, esse token costuma ter um prazo de validade, por exemplo 15 minutos, 30 minutos ou até 1 hora. Após esse período, o token expira e, ao fazer uma nova requisição, o servidor detecta que o token não é mais válido. O que acontece? O usuário é forçado a se autenticar novamente, voltando para a tela de login e fornecendo mais uma vez seus dados. Claro, quanto menor o tempo de expiração, mais chato fica para o usuário: a cada 15 ou 30 minutos, ele teria que relogar. A primeira ideia que pode surgir para resolver esse incômodo é: “Vou aumentar o tempo de expiração do token para várias horas ou até dias.” Assim, o usuário não precisa ficar autenticando o tempo todo. Mas qual o risco dessa abordagem? Se alguém mal-intencionado interceptar esse token, vai poder usá-lo durante todo o período de validade para se passar pelo usuário legítimo. Em outras palavras, se o token for válido por um dia inteiro, essa pessoa terá 24 horas para fazer solicitações em nome do usuário real, o que representa um risco enorme à segurança.
A solução: usar Access Token + Refresh Token
Para melhorar a experiência do usuário sem sacrificar tanto a segurança, hoje em dia não se recomenda retornar apenas o token de acesso (JWT), mas sim dois tokens:
- Access Token: costuma ter validade curta, como 15 minutos.
- Refresh Token: fica armazenado de forma mais segura e tem outra finalidade.
A dinâmica funciona assim: – Access Token: é o token enviado em todas as requisições para a API sempre que o usuário precisar acessar um recurso protegido. Ele expira em pouco tempo (por exemplo, 15 minutos), reduzindo a “janela de exploração” caso seja interceptado. – Refresh Token: é usado somente para pedir um novo access token quando este expira. Como ele só é enviado pontualmente, em poucas requisições, o risco de ser capturado é bem menor. Então, em vez de expor um único token de longa duração e arriscar que ele seja interceptado, a prática mais segura é trabalhar com tokens de curta duração + refresh token. Assim, quando o access token expirar, você não redireciona o usuário para a tela de login novamente, não pede credenciais outra vez. Basta enviar o refresh token ao servidor para conseguir um novo access token válido e continuar usando a aplicação sem interrupções.
Como fica a revogação de acesso?
Outra discussão importante é a possibilidade de revogar tokens. Por natureza, o JWT é chamado de stateless. Isso quer dizer que, após o servidor gerar o token e o cliente armazená-lo, a cada requisição o token é validado por si só, sem precisar consultar banco de dados ou outro servidor externo. Ele contém uma assinatura que garante sua integridade. O sistema receptor confere a assinatura e as informações nele contidas (como prazo de validade, entre outras). Se tudo estiver correto, o acesso é concedido. Essa característica traz vantagens de escalabilidade, pois em cada requisição não é preciso bater em um banco de dados para validar o token. O problema: Se você define que o token vai durar 1 hora e descobre que alguém obteve acesso a esse token de forma indevida, você não consegue revogá-lo imediatamente. Afinal, como o servidor não depende de checagem externa, vai continuar aceitando o token até ele expirar. A única forma de anular essa validade seria “quebrar” a ideia de stateless e conferir em algum lugar se o token foi revogado. Isso, claro, impacta a escalabilidade. Por isso, ter um access token de curta duração e um refresh token mais protegido ajuda bastante. Se houver a suspeita de vazamento do token de acesso, a “janela” é reduzida. Além disso, ao centralizar a revogação no refresh token, é possível, em muitos casos, bloquear a emissão de novos access tokens, o que limita ainda mais o estrago.
Conclusão
Para manter a experiência do usuário fluida, mas com menos risco de ataques, utilize essa estratégia de dois tokens. Defina um tempo curto para o access token (15 minutos, por exemplo) e utilize o refresh token para renovar o acesso quando o tempo expirar. Foi justamente para discutir esse tipo de detalhe que resolvi trazer o tema hoje. Se você gostou deste conteúdo e deseja acompanhar mais artigos e discussões sobre desenvolvimento de software, APIs REST, segurança e muito mais, deixe seu like (ou comentário) aqui no blog. Se você está acompanhando pelo YouTube (caso o conteúdo seja adaptado de lá), se inscreva no canal, compartilhe este post/vídeo com seus amigos desenvolvedores e deixe sua opinião nos comentários. Estou sempre aberto a ouvir pontos de vista diferentes e a aprender com vocês.
Tem algo a acrescentar ou tem um exemplo de experiência na prática com JWT e refresh tokens? Escreva aqui embaixo: será um prazer conversar e trocar ideia. Obrigado pela leitura (ou visualização, se for o caso) e até a próxima! Um abraço!