Atualização de tokens OAuth 2
Atualização de tokens OAuth 2
Este guia pressupõe que você já criou um aplicativo OAuth2
Se ainda não fez isso, consulte este guia e retorne aqui depois de capturar o access_token e o refresh_token de uma concessão bem-sucedida de credenciais OAuth 2.
Noções básicas de atualização de token
Supondo que você incluiu o escopo offline na solicitação de credenciais OAuth2.0, a autenticação bem-sucedida via aplicativo de contas do Frame.io retornará um conteúdo semelhante ao seguinte:
O access_token é um bearer token que pode ser usado para agir em nome do usuário autenticado; expirará após 3.600 segundos (uma hora) e, depois disso, o refresh_token poderá ser usado para buscar um novo access_token.O refresh token expirará após 30 dias, momento em que será necessário que o usuário faça login do zero, produzindo um novo par de tokens de acesso/atualização e assim por diante.Se você não solicitar o escopo offline explicitamente, não receberá um refresh_token e, portanto, após uma hora, terá que reautenticar completamente o usuário.
Captura do refresh token na autenticação bem-sucedida
É desnecessário dizer que você não pode usar um refresh_token que não tem, então certifique-se de que seu aplicativo:
- Solicite o escopo offline
- Capture o
refresh_tokenretornado em um callback bem-sucedido.
Para conveniência, o callback dos nossos Guias do aplicativo OAuth 2 é reproduzido aqui, com uma chamada os para armazenar o Refresh token.Observe que dois exemplos são fornecidos: um com PKCE configurado (não inclui cabeçalho de autenticação básica) e um sem (inclui cabeçalho de autenticação básica).
Sem PKCE
Com PKCE
Executar uma atualização
A atualização em si é uma única chamada para o URL de token do Frame.io:
- Método: POST
- URL: https://applications.frame.io/oauth2/token
Content-Type: application/x-www-form-urlencoded
Uma atualização sempre incluirá pelo menos os três atributos a seguir nos dados do formulário:
grant_type: refresh_tokenscope: <scopes>refresh_token: <refresh_token>
Se você estiver usando PKCE, precisará incluir o client_id do aplicativo nos dados deste formulário; caso contrário, precisará incluir um cabeçalho de autenticação básica com o client_id e o client_secret do aplicativo como nome de usuário e senha, respectivamente.
Sem PKCE
Semelhante a fazer o callback de autenticação inicial sem PKCE, esta atualização padrão exigirá o fornecimento do client_id e do client_secret como nome de usuário e senha em um cabeçalho de autenticação básica.
Com PKCE
Novamente, estamos seguindo as regras do ciclo /callback inicial:
- Não incluímos um cabeçalho
Authorization - Devemos incluir o
client_idno conteúdo
Parabéns!Agora você pode gerenciar todo o ciclo de vida do token de um aplicativo cliente OAuth2.0.