Sumário
Introdução
E ae dev, tudo bem com você?
Hoje vamos falar especificamente de uma das camadas mais utilizadas num fluxo "moderno" de autenticação. Você já ouviu falar de Refresh Tokens? Em resumo, "tokens de atualização" são credenciais utilizadas para obter credenciais/tokens de acesso. Complicado?
Calma fica comigo, pega um café e garanta sua leitura!
Bora pro post?
Problema
Vamos criar uma cenário hipotético mas muito comum para quem está lidando com autenticação de aplicações. Imagine que um usuário queira acessar uma aplicação. Essa aplicação por sua vez possui uma tela de login onde o usuário precisará se autenticar para então acessar toda a parte interna da aplicação: dashboards, meu perfil, e etc.
Por questões de segurança, no momento em que o usuário se autenticou, foi definido que o tempo de sessão mínimo seja de apenas 5 minutos. O usuário então (sempre que expira a sua sessão) perde o acesso ao sistema, e deve inserir suas credenciais novamente para continuar navegando.
É evidente que o nosso usuário acaba tendo uma péssima experiência ao utilizar o nosso sistema...
Tendo isso em vista, conversamos com o time de segurança sobre aumentarmos o tempo de duração da sessão, mas isso implicaria em deixarmos a nossa aplicação menos segura para o nosso usuário...
Sendo assim, como evitar que os usuários tenham que realizar o login sempre que a sessão expire? Como equilibrar a segurança e a usabilidade na nossa aplicação?
Solução: refresh tokens!
Primeiro, vamos entender um pouco do fluxo de autenticação que temos até então.
O Client envia um usuário e senha para o servidor de autorização, as credenciais estando válidas o servidor devolve um access_token para o Client. O Client pode (e deve) utilizar o access_token nas requisições protegidas para as APIs. As APIs protegidas validam o access_token e devolvem o recurso solicitado pelo Client.
Com o fluxo atual, é inevitável que o usuário tenha a experiência que falamos antes. Isto porque as APIs protegidas verificam sempre se o access_token é válido, para então devolver o recurso pro usuário.
Precisamos melhorar esse fluxo, incluindo o mecanismo de refresh_token!
Vamos primeiro entender qual é a diferença entre um access_token e de um refresh_token.
O que é um access token?
O access token é um JWT (JSON Web Tokens) que é utilizado pelo usuário para acessar as aplicações e os recursos protegidos. Esse token é codificado (não encriptado) e carrega algumas informações presentes no Header, Payload e Signature (seções que compõe a estrutura base de um token JWT).
Geralmente ele possui um tempo de vida útil curto.
💡 jwt.io: JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
O que é um refresh token?
O refresh token é um token utilizado para "renovar a sessão" de um usuário. Através dele podemos solicitar ao servidor de autorização para que seja gerado um novo access token sem ter que pedir ao usuário que ele se logue novamente (desde que o token de atualização seja válido e não tenha expirado).
É importante entender que:
- Ele possui um tempo de vida útil maior do que o
access_token; - É um token apenas para gerar um novo token de acesso. Não pode ser utilizado para acessar a aplicação. Porém, se expirado, o usuário deve realizar o login novamente;
- Alguns IdPs (Identity Providers) utilizam o refresh token pra revogar as sessões ativas do usuário.
Estando claras as diferenças, vamos adaptar o nosso fluxo de autenticação!
Autenticação com refresh token
No novo fluxo o Client, toda vez que tiver uma solicitação rejeitada pela API protegida, deve solicitar ao servidor de autorização um novo token de acesso (utilizando o refresh token na solicitação). O servidor de autorização valida a solicitação (verificando se o refresh token está válido e não expirado) e concede ao Client o token de acesso.
Verificando as alterações no novo fluxo de autenticação:
- Além de retornar o
access_token, também retornamos orefresh_tokendurante o login do usuário (noPOST /auth/login); - Adicionamos um nova rota no Authorization Server para possibilitar que o Client possa renovar a sua sessão (o
POST /auth/refresh);
Finalizando...
Bem, é isso, por hoje, é só!
Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.
Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.
Até!
Top comments (6)
Boooa Will, saiba que acompanho seus posts, e vou te falar, após ler esse aqui bateu uma vontade de escrever também kkkk. Podemos afirmar então que você está me influenciando HAHAHAH.
Mais uma vez, parabéns Will, ótimo conteúdo!
Ohoooo Lucão! Que bacana ler isso meu caro!
Valeu pelo carinho e apoio mano! Só vamos, to ansioso pra ver! Começar já é uma baita passo! Boooora!
Uma coisa que ainda é um pouco nebuloso, é a questão de segurança.
Caso uma pessoa mal-intencionada, roube o acess_token e refresh token do usuário ele vai conseguir manter uma sessão por um longo tempo (pois, vai conseguir fazer o refresh token) a não ser que o usuário revogue a sessão de alguma forma.
Parabéns pelo conteúdo, Sensacional !!
Muito bom Edson! É isso mesmo... É "recomendável" que outras camadas sejam adicionadas para tornar todo o fluxo ainda mais seguro (desde tráfego com TLS, uso de cookies HTTP-only, etc, ou até mesmo adotar estratégias para revogar o refresh token).
Muito obrigado meu caro!
Belo post, man!
Ohooo, muito obrigado meu caro! Espero ter ajudado!