O token de atualização atende a pelo menos dois propósitos. Primeiro, o token de atualização é um tipo de 'prova' de que um cliente OAuth2 já recebeu permissão do usuário para acessar seus dados e, portanto, pode solicitar um novo token de acesso novamente sem exigir que o usuário passe por todo o fluxo OAuth2. E, em segundo lugar, ajuda a aumentar todo o fluxo de segurança em comparação com um token de acesso de longa duração. Vou abordar esses dois pontos com mais detalhes.
Atualizar tokens como um meio de não incomodar o usuário
Vamos falar sobre o primeiro propósito com um exemplo. Suponha que você, um usuário, esteja usando um aplicativo da web cliente de terceiros que deseja interagir com os dados de sua conta do YouTube. Depois de conceder permissão ao aplicativo Cliente para usar seus dados do YouTube, você gostaria que o aplicativo Cliente solicitasse sua permissão novamentequando seu token do YouTube expirou? O que acontece se o tempo de expiração do token do YouTube for muito baixo, como 5 minutos. Seria um pouco chato ter o aplicativo do cliente solicitando sua permissão pelo menos a cada 5 minutos! A solução que o OAuth2 propõe para esse 'problema' é atualizar os tokens. Ao usar tokens de atualização, o token de acesso pode permanecer de curta duração (o que é desejável no caso de o token de acesso vazar ou ser roubado de alguma forma), e o token de atualização pode permanecer por muito tempo (er), permitindo que o cliente obtenha um novo acesso token quando um expira sem exigir a permissão do usuário (novamente).
Mas por que um token de atualização? Se o objetivo é não incomodar o usuário com solicitações de permissão, por que o cliente não pode simplesmente dizer "Ei, servidor de autorização, quero outro token de acesso. Agora!"? Ou, "Ei servidor de autorização, aqui está meu token expirado, dê-me um novo!". Bem, o token de atualização serve como uma espécie de "prova" de que o cliente em algum momento original teve acesso concedido por um usuário. Essa "prova" está na forma de token de atualização sendo digitalmente assinado pelo Servidor de Autorização. Ao apresentar um token de atualização pelo Cliente, o Servidor de Autorização pode verificar se o Cliente recebeu, em algum ponto no passado, permissão do Usuário, e o Cliente não precisa solicitar ao Usuário novamente.
Atualizar o token como um meio de aumentar a segurança
No entanto, isso levanta a questão: "Bem, o que acontece se o token de atualização vazar, for roubado ou simplesmente for mantido por um aplicativo cliente malicioso que não se livra dele a pedido do usuário? O invasor não pode simplesmente continuar a usar o token de atualização para obter um token de acesso válido indefinidamente (ou até que expire)? Esta pergunta leva a discutir o segundo propósito que mencionei, de tokens de atualização contribuindo para um fluxo mais seguro.
O problema que surge com os tokens de acesso é que, uma vez adquiridos, eles só são apresentados ao Servidor de Recursos (YouTube, por exemplo). Portanto, se um token de acesso for roubado ou comprometido, como você diz ao Servidor de Recursos para não confiar nesse token? Bem, você não pode realmente. A única maneira de fazer isso seria alterar a chave de assinatura privada no Authorization Server (a chave que assinou o token em primeiro lugar). Imagino que seja inconveniente de fazer e, em alguns casos (como Auth0), não é compatível.
Por outro lado, os tokens de atualização precisam ser apresentados ao servidor de autorização com frequência e, portanto, se algum estiver comprometido, é comum revogar ou negar o token de atualização como um todo e não ter que alterar nenhuma chave de assinatura.