Este artigo explora o conceito de refresh tokens como definidos pelo OAuth 2.0. Vamos aprender como eles se comparam a outros tipos de token e como eles nos permitem equilibrar segurança, usabilidade e privacidade.
O que é um token
Tokens são pedaços de dados que carregam apenas as informações suficientes para facilitar o processo de determinar a identidade de um usuário ou autorizá-lo a executar uma ação. De modo geral, os tokens são artefatos que permitem que aplicações executem o processo de autorização e autenticação.
Esses conceitos de identidade são novos pra você? Leia Autenticação versus Autorização (em inglês) para começar.
Frameworks e protocolos de identidade comuns usam estratégias baseadas em token para proteger o acesso a aplicações e recursos. Por exemplo, podemos usar OAuth 2.0 para autorização e OIDC para autenticação.
O Auth 2.0 é um dos frameworks de autorização mais populares que existem. Ele foi projetado para permitir que uma aplicação acesse recursos hospedados por outros servidores em nome de um usuário. OAuth 2.0 usa tokens de acesso e refresh tokens.
O OpenID Connect (OIDC) é um protocolo de identidade que executa autenticação e consentimento do usuário, além de emissão de token. OIDC usa tokens de ID.
Vamos explorar os três tipos de token que usamos com OAuth 2.0 e OpenID Connect para realizar os processos de autenticação e autorização das nossas aplicações. Neste processo, veremos o papel crítico que os refresh tokens desempenham para ajudar pessoas desenvolvedoras a criar aplicações que oferecem conveniência sem comprometer a segurança.
Tipos de Tokens
O que é um token de ID
Como o nome pode sugerir, um token de ID é um artefato que as aplicações cliente podem usar para consumir a identidade de um usuário. Por exemplo, o token de ID pode conter informações sobre o nome, email e foto do perfil de um usuário. Dessa forma, as aplicações cliente podem usar o token de ID para criar um perfil de usuário para personalizar a experiência do usuário.
Um servidor de autenticação que esteja em conformidade com o protocolo OpenID Connect (OIDC) para implementar o processo de autenticação emite um token de ID para seus clientes sempre que um usuário faz login. Os consumidores de tokens de ID são principalmente aplicações cliente, como Single-Page Applications (SPAs) e aplicativos móveis, que são o público-alvo.
O que é um token de acesso
Quando um usuário faz login, o servidor de autorização emite um token de acesso, que é um artefato que as aplicações cliente podem usar para fazer chamadas seguras para um servidor de API. Quando uma aplicação cliente precisa acessar recursos protegidos em um servidor em nome de um usuário, o token de acesso permite que o cliente sinalize ao servidor que recebeu autorização do usuário para executar determinadas tarefas ou acessar determinados recursos.
OAuth 2.0 não define um formato para tokens de acesso. Na Auth0, por exemplo, os tokens de acesso emitidos para a API de gerenciamento e os tokens de acesso emitidos para qualquer API personalizada que você registrou com Auth0 seguem o padrão JSON Web Token (JWT). Sua estrutura básica está em conformidade com a estrutura típica do JWT e contêm claims (declarações) JWT padrão declaradas sobre o próprio token.
Interested in getting up-to-speed with JWTs as soon as possible?
Download the free ebook
Este é o conteúdo de um token de acesso decodificado que segue o formato JWT:
{ "iss": "https://YOUR_DOMAIN/", "sub": "auth0|123456", "aud": [ "my-api-identifier", "https://YOUR_DOMAIN/userinfo" ], "azp": "YOUR_CLIENT_ID", "exp": 1489179954, "iat": 1489143954, "scope": "openid profile email address phone read:appointments" }
É importante destacar que o token de acesso é um token de portador (bearer token). Aqueles que possuem o token podem usá-lo. O token de acesso atua então como um artefato de credencial para acessar recursos protegidos em vez de um artefato de identificação. Usuários mal-intencionados poderiam, teoricamente, comprometer um sistema e roubar tokens de acesso, que poderiam usar para acessar recursos protegidos apresentando esses tokens diretamente ao servidor.
Como tal, é fundamental ter estratégias de segurança que minimizem o risco de comprometer os tokens de acesso. Um método de mitigação é criar tokens de acesso com vida útil curta: eles são válidos apenas por um curto período definido em termos de horas ou dias.
Há diferentes maneiras de uma aplicação cliente obter um novo token de acesso para um usuário. Por exemplo, uma vez que um token de acesso expira, a aplicação cliente pode solicitar que o usuário faça login novamente para obter um novo token de acesso. Como alternativa, o servidor de autorização pode emitir um refresh token para a aplicação cliente que permita substituir um token de acesso expirado por um novo.
Você pode ver os tokens de ID e de acesso em ação em qualquer um de nossos "Guias Completos para Autenticação do Usuário" disponíveis para React (em português), Angular, Vue e Node.js (em inglês)!
O que é um refresh token?
Como mencionado, por motivos de segurança, os tokens de acesso podem ser válidos por um curto período de tempo. Depois que expiram, as aplicações cliente podem usar um refresh token para "atualizar" o token de acesso. Ou seja, um refresh token é um artefato de credencial que permite que uma aplicação cliente obtenha novos tokens de acesso sem precisar solicitar que o usuário faça login novamente.
No diagrama acima, SPA = Single-Page Application; SA = Servidor de Autorização; SR = Servidor de Recursos; TA = Token de Acesso; RT = Refresh Token.
A aplicação cliente pode obter um novo token de acesso desde que o refresh token seja válido e não tenha expirado. Consequentemente, um refresh token que tem uma vida útil muito longa poderia teoricamente dar poder infinito ao portador do token para obter um novo token de acesso para acessar recursos protegidos a qualquer momento. O portador do refresh token pode ser um usuário legítimo ou um usuário mal-intencionado. Dessa forma, empresas de segurança, como a Auth0, criam mecanismos para garantir que esse token poderoso seja mantido e usado principalmente de forma contínua pelas partes a que se destina.
Quando usar refresh tokens
É importante ter em mente que a especificação OAuth 2.0 define tokens de acesso e refresh tokens. Então, se fôssemos discutir estratégias de autorização em termos de outros protocolos ou frameworks de identidade, como SAML (protocolo baseado em XML), não teríamos os conceitos de tokens de acesso ou refresh tokens.
Para aquelas pessoas envolvidas com desenvolvimento web, token de acesso e refresh tokens são comuns porque a web usa amplamente autorização e autenticação baseada em token por meio do framework OAuth 2.0 e do protocolo OpenID Connect.
Quando combinados, o OAuth 2.0 e o OIDC dão vida a uma variedade de fluxos de autorização e autenticação. Cada fluxo tem seu próprio conjunto de benefícios e ressalvas que definem os melhores cenários e arquiteturas onde devemos usar tokens de acesso e refresh tokens.
- O cliente é uma aplicação web tradicional em execução no servidor? Use o Fluxo de Código de Autorização.
- O cliente é uma Single-Page Application (SPA)? Use o Fluxo de Autorização de Código com Prova de Chave para Troca de Código (Code Flow with Proof Key for Code Exchange
- PKCE).
- O cliente é uma Single-Page Application (SPA) que não precisa de um token de acesso? Use o Fluxo Implícito com Envio de Formulário.
- O cliente é o proprietário do recurso? Você pode usar o Fluxo de Credenciais de Cliente.
- O cliente é absolutamente confiável com as credenciais do usuário? Você pode usar o Fluxo de Senha do Proprietário do Recurso.
Se existe um app pra isso, também existe um fluxo para isso!
Lembre-se de que, de acordo com a especificação, ao usar o fluxo implícito, o servidor de autorização não deve emitir refresh tokens. O fluxo implícito é frequentemente implementado em Single-Page Applications (SPAs), que são executados na camada de front-end da arquitetura de um sistema. Não há uma maneira fácil de manter um refresh token seguro na camada de front-end por si só.
O uso do Fluxo de Autorização de Código com Prova de Chave para Troca de Código (PKCE) reduz muitos riscos inerentes ao fluxo implícito. Por exemplo, ao usar o tipo de concessão implícita, o token de acesso é transmitido no fragmento de URI, o que pode expor ele a partes não autorizadas. Você pode saber mais sobre essas vulnerabilidades lendo a seção "Uso indevido do token de acesso para imitar o proprietário do recurso no fluxo implícito" (em inglês) da especificação.
No entanto, a implementação do PKCE nas suas aplicações ainda não impactam no quão seguros os refresh tokens são.
No entanto, você pode não precisar de refresh tokens
Existem cenários em que você ainda pode obter um token de acesso sem interromper o usuário e sem depender de todo o poder do refresh token. Outros exemplos para manter uma sessão em andamento podem ser cookies ou autenticação silenciosa.
Entretanto, bilhões de pessoas usam SPAs todos os dias. É importante fornecer aos usuários uma experiência de uso que equilibre bem segurança e conveniência. Existe algo que possamos fazer para permitir que as SPAs ofereçam a conveniência de refresh tokens de uma maneira menos arriscada e mais segura?
Com certeza!
Uma plataforma de identidade que oferece rotação de refresh token torna aceitável o uso de refresh tokens com Single-Page Applications. A especificação destaca que, quando você não pode verificar se um refresh token pertence a um cliente, como uma SPA, não devemos usá-lo, a menos que tenhamos a rotação de refresh token acontecendo.
Vamos aprender mais sobre essa estratégia de segurança na próxima seção.
Mantendo refresh tokens seguros
Um token de acesso de vida útil curta ajuda a melhorar a segurança das nossas aplicações, mas tem um preço: quando expira, o usuário precisa fazer login novamente para obter um novo token. A reautenticação frequente pode prejudicar a experiência percebida pelo usuário da sua aplicação. Mesmo que você esteja fazendo isso para proteger seus dados, os usuários podem achar seu serviço frustrante ou difícil de usar.
Um refresh token pode te ajudar a equilibrar segurança com usabilidade. Como os refresh tokens geralmente têm vida útil mais longa, você pode usá-los para solicitar novos tokens de acesso depois que os tokens de acesso de vida útil mais curta expirarem.
No entanto, como os refresh tokens também são tokens de portador, precisamos ter uma estratégia que limite ou reduza seu uso se eles vazarem ou forem comprometidos. Todos aqueles que possuem os refresh tokens têm o poder de obter novos tokens de acesso sempre que quiserem. "Eles" podem ser usuários legítimos ou invasores.
Na Auth0, criamos um conjunto de recursos que atenuam os riscos associados ao uso de refresh tokens impondo defesas e controles em seu ciclo de vida. Nossa plataforma de identidade oferece rotação de refresh token, que também vem com detecção automática de reutilização.
Vamos nos aprofundar nessa técnica de segurança.
Rotação de refresh tokens
Até muito recentemente, uma estratégia robusta para ajudar os SPAs a manter a sessão do usuário era usar o fluxo com código de autorização com PKCE junto da autenticação silenciosa. A rotação de refresh token é uma técnica para obter novos tokens de acesso usando refresh tokens que vão além da autenticação silenciosa.
A rotação de refresh token garante que sempre que uma aplicação trocar um refresh token para obter um novo token de acesso, um novo refresh token também será retornado. Portanto, você não tem mais um refresh token de longa duração que poderia fornecer acesso ilegítimo a recursos se ele fosse comprometido. A ameaça de acesso ilegítimo é reduzida à medida que os refresh tokens são continuamente trocados e invalidados.
Por exemplo, com a rotação de refresh token habilitada no painel Auth0 Dashboard, sempre que sua aplicação troca um refresh token para obter um novo token de acesso, o servidor de autorização também retorna um novo par de refresh token e token de acesso. Essa defesa ajuda sua aplicação a mitigar ataques de repetição (replay attacks) provenientes de tokens comprometidos.
Detecção automática da reutilização de refresh token
Os refresh tokens são tokens de portador. É impossível para o servidor de autorização saber quem é legítimo ou mal-intencionado ao receber uma nova solicitação de token de acesso. Poderíamos então tratar todos os usuários como potencialmente maliciosos.
Como poderíamos lidar com uma situação em que há uma condição de corrida entre um usuário legítimo e um mal-intencionado? Por exemplo:
- 🐱 Usuário Legítimo tem 🔄 Refresh Token 1 e 🔑 Token de Acesso 1.
- 😈 Usuário Mal-intencionado consegue roubar 🔄 Refresh Token 1 de 🐱 Usuário Legítimo.
- 🐱 Usuário Legítimo usa 🔄 Refresh Token 1 para obter um novo par de refresh token e token de acesso.
- O 🚓 Servidor de Autorização da Auth0 retorna 🔄 Refresh Token 2 e 🔑 Token de Acesso 2 para o 🐱 Usuário Legítimo.
- 😈 Usuário Mal-intencionado então tenta usar 🔄 Refresh Token 1 para obter um novo token de acesso. Maldade pura!
O que você acha que deve acontecer agora? 😈 Usuário Mal-intencionado conseguiria obter um novo token de acesso?
Isso é o que acontece quando sua plataforma de identidade tem 🤖 Detecção Automática de Reutilização:
- O 🚓 Servidor de Autorização da Auth0 acompanha todos os refresh tokens descendentes do refresh token original. Ou seja, criou um "token família".
- O 🚓 Servidor de Autorização da Auth0 reconhece que alguém está reutilizando o 🔄 Refresh Token 1 e invalida imediatamente a família de refresh tokens, incluindo 🔄 Refresh Token 2.
- O 🚓 Servidor de Autorização da Auth0 retorna uma resposta de Acesso Negado para 😈 Usuário Mal-intencionado.
- 🔑 Token de Acesso 2 expira e 🐱 Usuário Legítimo tenta usar 🔄 Refresh Token 2 para solicitar um novo par de refresh token e token de acesso.
- O 🚓 Servidor de Autorização da Auth0 retorna uma resposta de Acesso Negado para 🐱 Usuário Legítimo.
- O 🚓 Servidor de Autorização da Auth0 exige uma nova autenticação para obter novos refresh tokens e tokens de acesso.
É fundamental que o refresh token mais recente seja invalidado imediatamente quando um refresh token usado anteriormente é enviado ao servidor de autorização. Isso impede que quaisquer refresh tokens na mesma família de tokens sejam usados para obter novos tokens de acesso.
Esse mecanismo de proteção funciona independentemente de o usuário legítimo ou mal-intencionado poder trocar o 🔄 Refresh Token 1por um novo par de refresh tokens e tokens de acesso antes do outro. Sem impor a sender constraint (restrição do remetente em tradução livre), o servidor de autorização não consegue saber qual ator é legítimo ou malicioso no caso de um replay attack (ataque de repetição).
A detecção automática de reutilização é um componente chave de uma estratégia de rotação de refresh token. O servidor já invalidou o refresh token que já foi usado. No entanto, como o servidor de autorização não tem como saber se o usuário legítimo está com o refresh token mais atual, ele invalida toda a “família” de tokens só para garantir.
Os refresh tokens nos ajudam a adotar as ferramentas de privacidade
A privacidade é um tema quente em nosso mundo digital. Não só precisamos equilibrar segurança com conveniência, mas também precisamos adicionar privacidade ao ato de equilíbrio.
Desenvolvimentos recentes na tecnologia de privacidade do navegador, como o Intelligent Tracking Prevention (ITP), impedem o acesso ao cookie de sessão, exigindo que os usuários se autentiquem novamente.
Não há nenhum mecanismo de armazenamento persistente em um navegador que possa garantir o acesso apenas pela aplicação pretendida. Dessa forma, refresh tokens de longa duração não são adequados para SPAs, pois há vulnerabilidades que usuários mal-intencionados podem explorar para obter esses artefatos de alto valor, dando a eles acesso a recursos protegidos.
Como a rotação do refresh token não depende do acesso ao cookie de sessão Auth0, ela não é afetada pelo ITP ou mecanismos semelhantes.
No entanto, um refresh token pode ter sua vida útil limitada pela vida útil de um token de acesso. Isso significa que podemos usar refresh tokens com segurança para acompanhar as ferramentas de privacidade do navegador e fornecer acesso contínuo aos usuários finais sem prejudicar a experiência do usuário.
Você pode armazenar o refresh token no armazenamento local
Sim, você leu certo. Quando temos a rotação de refresh tokens acontecendo, podemos guardar tokens no armazenamento local (local storage) ou na memória do navegador.
Você pode ter ouvido antes (talvez de nós) que não devemos armazenar tokens em armazenamento local.
Armazenar tokens no armazenamento local do navegador fornece persistência nas atualizações de página e abas do navegador; no entanto, se usuários mal-intencionados conseguirem executar JavaScript na SPA usando um ataque de script entre sites (XSS), eles poderiam recuperar os tokens armazenados no armazenamento local. Uma vulnerabilidade que leva a um ataque XSS bem-sucedido pode estar presente no código-fonte da SPA ou em qualquer código JavaScript de terceiros que a aplicação consuma, como Bootstrap ou Google Analytics.
No entanto, podemos reduzir o tempo absoluto de expiração de tokens para reduzir os riscos de segurança de armazenar tokens no armazenamento local. Isso reduz o impacto de um ataque XSS refletido (mas não de um persistente). Um refresh token pode ter uma longa vida útil por configuração. No entanto, a longa vida útil definida de um refresh token é interrompida com a rotação do refresh token. A atualização só é válida dentro da vida útil do token de acesso, que seria de curta duração.
Use refresh tokens em seus aplicativos Auth0
Se você tiver interesse em adicionar autenticação e autorização na sua aplicação em apenas algumas etapas, inscreva-se para uma conta gratuita da Auth0 agora mesmo.
Experimente a plataforma de autenticação mais poderosa gratuitamente.
Comece aqui →Nosso documento "Melhores práticas com token" descreve algumas considerações básicas a ter em mente ao usar tokens:
- Mantenha em segredo. Mantenha seguro.
- Não adicione dados confidenciais à carga útil.
- Dê uma expiração aos tokens.
- Abrace o HTTPS.
- Considere todos os seus casos de uso de autorização.
- Armazene e reutilize.
O painel Auth0 Dashboard facilita a configuração de seus serviços de autenticação e autorização para usar refresh tokens. Os SDKs e bibliotecas da Auth0 oferecem suporte a refresh tokens para aplicações Web, Single-Page Applications (SPAs) e aplicativos nativos/móveis.
Para recursos adicionais sobre como usar refresh tokens com Auth0, visite qualquer um destes documentos (em inglês):