Usei o token de atualização várias vezes em apenas um curto período para fins de teste, mas me pergunto se os tokens de atualização do Google expiram? Posso usar o mesmo token de atualização para obter outro token de acesso repetidamente por um longo período (uma semana ou até meses)?
Respostas:
Os tokens de atualização emitidos pelo servidor Google Auth nunca expiram - esse é o ponto principal dos tokens de atualização. O token de atualização irá expirar (ou devo dizer que se tornará não autorizado) quando o usuário revogar o acesso ao seu aplicativo.
Consulte este documento, ele afirma claramente a função dos tokens de atualização.
Em vez de emitir um token de longa duração (normalmente válido por um ano ou vida útil ilimitada), o servidor pode emitir um token de acesso de curta duração e um token de atualização de longa duração. Resumindo, você pode usar tokens de atualização repetidas vezes até que o usuário que autorizou o acesso revogue o acesso ao seu aplicativo.
Este é um tópico muito confuso. A primeira resposta parece estar certa, mas na verdade não cita nada oficial do google.
A resposta mais definitiva que encontrei está, na verdade, no playground do desenvolvedor, onde você obtém o token. A etapa 2 tem uma nota na parte inferior que diz:
"Observação: o OAuth Playground não armazena tokens de atualização, mas como os tokens de atualização nunca expiram, o usuário deve ir para a página de acesso autorizado da conta do Google se quiser revogá-los manualmente."
Não acho que seja totalmente verdade:
Observe que há limites para o número de tokens de atualização que serão emitidos; um limite por combinação de cliente / usuário e outro por usuário em todos os clientes. Você deve salvar tokens de atualização no armazenamento de longo prazo e continuar a usá-los enquanto permanecerem válidos. Se o seu aplicativo solicitar muitos tokens de atualização, ele pode atingir esses limites e, nesse caso, os tokens de atualização mais antigos deixarão de funcionar.
desta página: https://developers.google.com/youtube/v3/guides/authentication#installed-apps
Isso vem dos documentos do YouTube (que considero muito melhores do que outros documentos da API), mas acho que é o mesmo em todos os aplicativos do Google.
Veja isso:
Os tokens de atualização são válidos até que o usuário revogue o acesso. Este campo estará presente apenas se access_type = offline estiver incluído na solicitação do código de autorização.
em https://developers.google.com/accounts/docs/OAuth2WebServer
As regras mudaram em algum momento de 2017, então a melhor resposta eu acho que depende do produto. Por exemplo, na API do Gmail, o token de atualização Oauth 2.0 expira com a alteração da senha. Veja este https://support.google.com/a/answer/6328616?hl=en
Costumávamos configurar o acesso à API com antecedência e gerar tokens de atualização quando configurávamos NOVOS usuários do gmail, e então poderíamos arquivar seus e-mails (somos obrigados a fazer isso por lei), mas agora, assim que eles mudarem sua senha, o token de atualização é revogado.
Talvez para youtube e mapas, o token de atualização ainda tenha vida longa, mas para gmail api, conte com um token curto.
O conceito principal do token de atualização é que ele é duradouro e nunca expira.
O token de acesso tem um tempo de expiração e ele expira, assim que expirar podemos ir para o token de atualização, que será usado repetidamente até que o usuário cancele sua conta.
Leia em: https://developers.google.com/identity/protocols/oauth2#expiration Você deve escrever seu código para antecipar a possibilidade de que um token de atualização concedido não funcione mais. Um token de atualização pode parar de funcionar por um destes motivos:
O usuário revogou o acesso ao seu aplicativo. O token de atualização não é usado há seis meses. O usuário alterou as senhas e o token de atualização contém escopos do Gmail. A conta do usuário excedeu o número máximo de tokens de atualização concedidos (ativos). Atualmente, há um limite de 50 tokens de atualização por conta de usuário por cliente. Se o limite for atingido, a criação de um novo token de atualização invalidará automaticamente o token de atualização mais antigo sem aviso. Esse limite não se aplica a contas de serviço.
Também há um limite maior no número total de tokens de atualização que uma conta de usuário ou conta de serviço pode ter em todos os clientes. A maioria dos usuários normais não excederá esse limite, mas a conta de teste de um desenvolvedor pode.
Eu fiz algumas pesquisas adicionais e parece que o token de acesso do Google é usado para recuperar um token de atualização, durante a primeira solicitação 'offline'. Deste ponto em diante, o token de atualização é usado para emitir um novo token de acesso. A ideia é que um token de acesso é um token de curto prazo, mas pode ser renovado por um token de atualização de longo prazo. Isso elimina a necessidade de solicitar a variável de 'código' do URL, que requer uma abordagem de dois pontos finais e deve ser iniciada, usando uma solicitação baseada em referenciador:
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
Alguns serviços de API REST como o Dropbox emitem tokens de acesso que duram para sempre, mas o Google emite tokens de acesso de curto prazo. O PayPal usa um meio-termo, por meio do qual permite que tokens de acesso sejam recuperados sem a aplicação do referenciador de URI. Isso significa que os tokens de acesso podem ser recuperados sem a necessidade de clicar em um link para iniciar o processo. A metodologia do Google significa que as rotinas de API devem ser chamadas apenas quando houver necessidade de uso. Essencialmente, as chamadas são iniciadas por meio de procedimentos baseados em referenciador. Isso é controlado pela emissão de tokens de acesso de curta duração ou tokens de acesso que devem ser atualizados em uma cadeia. Isso requer que os desenvolvedores pensem com mais cuidado sobre como um sistema deve fluir.