Qual é a finalidade de um “Token de atualização”?

Eu tenho um programa que se integra com a API de transmissão ao vivo do YouTube. Ele roda em temporizadores, então foi relativamente fácil para mim programar para buscar um novo token de acesso a cada 50 minutos com um token de atualização. Minha pergunta é, por quê?

Quando me autentiquei no YouTube, recebi um token de atualização. Em seguida, uso este token de atualização para obter um novo token de acesso cerca de uma vez por hora. Se eu tiver o token de atualização, posso SEMPRE usá-lo para obter um novo token de acesso, pois ele nunca expira. Portanto, não vejo como isso é mais seguro do que apenas me dar um token de acesso desde o início e não me preocupar com todo o sistema de token de atualização.

Basicamente, os tokens de atualização são usados ​​para obter um novo token de acesso.

Para diferenciar claramente esses dois tokens e evitar confusão, aqui estão suas funções fornecidas na Estrutura de Autorização OAuth 2.0 :

• Os tokens de acesso são emitidos para clientes de terceiros por um servidor de autorização com a aprovação do proprietário do recurso. O cliente usa o token de acesso para acessar os recursos protegidos hospedados pelo servidor de recursos.
• Os tokens de atualização são credenciais usadas para obter tokens de acesso. Os tokens de atualização são emitidos para o cliente pelo servidor de autorização e são usados ​​para obter um novo token de acesso quando o token de acesso atual se torna inválido ou expira, ou para obter tokens de acesso adicionais com escopo idêntico ou mais restrito.

Agora, para responder à sua pergunta sobre por que ainda estava recebendo um token de atualização em vez de apenas proteger um token de acesso, o principal motivo fornecido pela Força-Tarefa de Engenharia da Internet em tokens de atualização é:

Há um motivo de segurança: o refresh_tokené sempre trocado com o servidor de autorização, enquanto o access_tokené trocado com servidores de recursos. Isso atenua o risco de um access_token de longa duração vazar no "um token de acesso válido por uma hora, com um token de atualização válido por um ano ou válido até a revogação" vs "um token de acesso válido até revogado sem atualização símbolo."

Para obter informações mais detalhadas e completas sobre o fluxo do OAuth 2.0, tente consultar as seguintes referências:

• Fluxo do OAuth 2.0: aplicativos da web do lado do servidor
• A estrutura de autorização OAuth 2.0 emitida pela Internet Engineering Task Force (IETF)
• Pós-SO - Por que o OAuth v2 tem tokens de acesso e atualização?

@Teyam menciona a postagem do SO Por que o OAuth v2 tem tokens de acesso e atualização? mas eu prefiro a outra resposta lá: https://stackoverflow.com/a/12885823/254109

TL; DR refresh_token não traz maior segurança. Tem como objetivo melhorar a escalabilidade e o desempenho. Então, access_tokenpode ser armazenado apenas em algum armazenamento temporário rápido (como a memória). Também permite a separação de servidores de autorização e recursos.

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.

"Então, não vejo como isso é mais seguro do que apenas me dar um token de acesso desde o início e não me preocupar com todo o sistema de token de atualização." Eu lutei com a mesma pergunta. A resposta curta é que o token de atualização é necessário para garantir que as credenciais não tenham expirado.

Um exemplo pode ajudar: tenho um banco de dados que armazena seus registros médicos. Você consente em compartilhar seus registros médicos com seu cônjuge. Seu cônjuge usa o token de acesso para ler seus registros de meu banco de dados. Daqui a duas semanas, seu cônjuge verifica novamente seus registros médicos e o token de atualização é usado para garantir que eles ainda tenham permissão (do servidor de autenticação) para visualizar seus registros. O token de atualização evita a necessidade de seu cônjuge inserir novamente suas credenciais (nome de usuário e senha) no servidor de autenticação, mas garante que eles ainda tenham legitimidade para acessar o recurso. Um token de acesso que nunca expira não saberia se você revogou os direitos de seu cônjuge de acessar seus registros médicos.