OAuth 2.0 para aplicativos móveis e de área de trabalho

Este documento explica como os aplicativos instalados em dispositivos como telefones, tablets e computadores usam os pontos de extremidade OAuth 2.0 do Google para autorizar o acesso às APIs do Google.

OAuth 2.0 permite que os usuários compartilhem dados específicos com um aplicativo, mantendo seus nomes de usuário, senhas e outras informações privadas. Por exemplo, um aplicativo pode usar OAuth 2.0 para obter permissão dos usuários para armazenar arquivos em seus Google Drives.

Os aplicativos instalados são distribuídos para dispositivos individuais e presume-se que esses aplicativos não possam guardar segredos. Eles podem acessar as APIs do Google enquanto o usuário está no aplicativo ou quando o aplicativo está sendo executado em segundo plano.

Este fluxo de autorização é semelhante ao utilizado para aplicações de servidor web . A principal diferença é que os aplicativos instalados devem abrir o navegador do sistema e fornecer um URI de redirecionamento local para lidar com as respostas do servidor de autorização do Google.

Alternativas

Para aplicações móveis, você pode preferir usar o login do Google para Android ou iOS . As bibliotecas cliente de login do Google tratam da autenticação e da autorização do usuário e podem ser mais simples de implementar do que o protocolo de nível inferior descrito aqui.

Para aplicativos executados em dispositivos que não suportam um navegador do sistema ou que têm limitado as capacidades de entrada, como TVs, consolas de jogos, câmeras, ou impressoras, consulte OAuth 2.0 para TVs e dispositivos ou de login do Google para dispositivos .

Bibliotecas e amostras

Recomendamos as seguintes bibliotecas e exemplos para ajudá-lo a implementar o fluxo OAuth 2.0 descrito neste documento:

Pré-requisitos

Ative APIs para seu projeto

Qualquer aplicativo que chama APIs do Google precisa para permitir que essas APIs no API Console.

Para habilitar uma API para seu projeto:

  1. Open the API Library na Google API Console.
  2. If prompted, select a project, or create a new one.
  3. O API Library listas de todas as APIs disponíveis, agrupados por família de produtos e popularidade. Se a API que você deseja ativar não é visível na lista, o uso de busca para encontrá-lo, ou clique em Ver Todos na família de produtos a que pertence.
  4. Selecione a API que você deseja ativar, em seguida, clique no botão Ativar.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Crie credenciais de autorização

Qualquer aplicativo que usa OAuth 2.0 para acessar APIs do Google deve ter credenciais de autorização que identificam o aplicativo para o servidor OAuth 2.0 do Google. As etapas a seguir explicam como criar credenciais para seu projeto. Seus aplicativos podem então usar as credenciais para acessar APIs que você habilitou para aquele projeto.

  1. Go to the Credentials page.
  2. Clique em Criar credenciais> OAuth ID do cliente.
  3. As seções abaixo descrevem os tipos de cliente e os métodos de redirecionamento compatíveis com o servidor de autorização do Google. Escolha o tipo de cliente recomendado para seu aplicativo, nomeie seu cliente OAuth e defina os outros campos no formulário conforme apropriado.

Esquema de URI personalizado (Android, iOS, UWP)

Um esquema de URI personalizado é recomendado para aplicativos Android, aplicativos iOS e aplicativos da Plataforma Universal do Windows (UWP).

Android
  1. Selecione o tipo de aplicativo Android.
  2. Insira um nome para o cliente OAuth. Esse nome é exibido na do seu projeto Credentials page para identificar o cliente.
  3. Digite o nome do pacote do seu aplicativo Android. Este valor é definido nopackage atributo do <manifest> elemento no seu arquivo de manifesto do aplicativo.
  4. Insira a impressão digital do certificado de assinatura SHA-1 da distribuição do aplicativo.
    • Se os seus usos de aplicativos App assinar pelo Google Play , copie a impressão digital SHA-1 a partir da página de assinatura aplicativo do jogo Console.
    • Se você gerenciar suas próprias chaves de armazenamento de chaves e assinatura, use o utilitário keytool incluído com Java para imprimir informações do certificado em um formato legível. Copie o SHA1 valor no Certificate fingerprints seção da saída keytool. Veja autenticação de sua cliente nas APIs do Google para documentação Android para mais informações.
  5. Clique em Criar.
iOS
  1. Selecione o tipo de aplicativo iOS.
  2. Insira um nome para o cliente OAuth. Esse nome é exibido na do seu projeto Credentials page para identificar o cliente.
  3. Insira o identificador do pacote para seu aplicativo. O ID pacote é o valor da CFBundleIdentifier chave no arquivo de lista de recursos do seu aplicativo propriedade da informação (info.plist). O valor é mais comumente exibido no painel General ou no painel Signing & Capabilities do editor de projeto Xcode. O ID pacote também é exibido na seção Informações Geral da página de Informações do aplicativo para o aplicativo no site da loja App Ligação da Apple .
  4. (Opcional)

    Insira o ID da App Store do seu aplicativo se o aplicativo for publicado na App Store da Apple. O ID da loja é uma string numérica incluída em cada URL da Apple App Store.

    1. Abra o aplicativo Apple App Store no seu dispositivo iOS ou iPadOS.
    2. Procure seu aplicativo.
    3. Selecione o botão Compartilhar (quadrado e símbolo de seta para cima).
    4. Selecione Copiar Link.
    5. Cole o link em um editor de texto. O ID da App Store é a parte final do URL.

      Exemplo: https://apps.apple.com/app/google/id 284815942

  5. (Opcional)

    Digite seu ID de equipe. Veja Localize o ID do time na documentação Conta Apple Developer para mais informações.

  6. Clique em Criar.
UWP
  1. Selecione o tipo de aplicação Universal plataforma Windows.
  2. Insira um nome para o cliente OAuth. Esse nome é exibido na do seu projeto Credentials page para identificar o cliente.
  3. Insira a ID da Microsoft Store de 12 caracteres do seu aplicativo. Você pode encontrar este valor no Microsoft Partner Center sobre a identidade App página na seção de gerenciamento App.
  4. Clique em Criar.

Para aplicativos UWP, o esquema de URI personalizado não pode ter mais de 39 caracteres.

Endereço IP de loopback (macOS, Linux, área de trabalho do Windows)

Para receber o código de autorização usando este URL, seu aplicativo deve estar escutando no servidor da web local. Isso é possível em muitas plataformas, mas não em todas. No entanto, se sua plataforma for compatível, este é o mecanismo recomendado para obter o código de autorização.

Quando seu aplicativo recebe a resposta de autorização, para melhor usabilidade, ele deve responder exibindo uma página HTML que instrui o usuário a fechar o navegador e retornar ao seu aplicativo.

Uso recomendado Aplicativos de desktop macOS, Linux e Windows (mas não Plataforma Universal do Windows)
Valores do formulário Defina o tipo de aplicação a aplicação Ambiente de Trabalho.

Copiar / colar manual

Identificar escopos de acesso

Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos de que precisa, ao mesmo tempo que permite que os usuários controlem a quantidade de acesso que concedem ao seu aplicativo. Assim, pode haver uma relação inversa entre o número de escopos solicitados e a probabilidade de obtenção do consentimento do usuário.

Antes de começar a implementar a autorização OAuth 2.0, recomendamos que você identifique os escopos que seu aplicativo precisará de permissão para acessar.

O 2.0 API Scopes OAuth documento contém uma lista completa de escopos que você pode usar para acessar o Google APIs.

Obtenção de tokens de acesso OAuth 2.0

As etapas a seguir mostram como seu aplicativo interage com o servidor OAuth 2.0 do Google para obter o consentimento de um usuário para realizar uma solicitação de API em nome do usuário. Seu aplicativo deve ter esse consentimento antes de executar uma solicitação de API do Google que requer autorização do usuário.

Etapa 1: gerar um verificador de código e desafio

Google suporta a chave de prova para o Código de câmbio (PKCE) protocolo para tornar o fluxo de aplicativo instalado mais seguro. Um verificador de código exclusivo é criado para cada solicitação de autorização e seu valor transformado, denominado "code_challenge", é enviado ao servidor de autorização para obter o código de autorização.

Crie o verificador de código

Um code_verifier é uma sequência aleatória de criptografia de alta entropia utilizando os caracteres não reservados [AZ] / [z] / [0-9] / "-" / "" / "_" / "~", com comprimento mínimo de 43 caracteres e máximo de 128 caracteres.

O verificador de código deve ter entropia suficiente para tornar impraticável adivinhar o valor.

Crie o desafio de código

Dois métodos de criação do desafio de código são suportados.

Métodos de geração de desafio de código
S256 (recomendado) O desafio do código é o hash SHA256 codificado em Base64URL (sem preenchimento) do verificador de código.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plano O desafio do código tem o mesmo valor que o verificador de código gerado acima.
code_challenge = code_verifier

Etapa 2: enviar uma solicitação ao servidor OAuth 2.0 do Google

Para obter a autorização do usuário, enviar um pedido para o servidor de autorização do Google em https://accounts.google.com/o/oauth2/v2/auth . Este ponto de extremidade lida com a pesquisa de sessão ativa, autentica o usuário e obtém o consentimento do usuário. O ponto de extremidade só pode ser acessado por SSL e recusa conexões HTTP (não SSL).

O servidor de autorização oferece suporte aos seguintes parâmetros de string de consulta para aplicativos instalados:

Parâmetros
client_id Obrigatório

O ID do cliente para seu aplicativo. Você pode encontrar este valor no API ConsoleCredentials page.

redirect_uri Obrigatório

Determina como o servidor de autorização do Google envia uma resposta ao seu aplicativo. Existem várias opções de redirecionamento disponíveis para aplicativos instalados, e você terá configurar suas credenciais de autorização com um método de redirecionamento específico em mente.

O valor deve corresponder exatamente um dos URIs de redirecionamento redirecionamento autorizados para o cliente OAuth 2.0, que você configurou na do seu cliente API ConsoleCredentials page. Se este valor não corresponder a um URI autorizado, você vai ter um redirect_uri_mismatch erro.

A tabela abaixo mostra o apropriado redirect_uri valor do parâmetro para cada método:

redirect_uri valores
Esquema URI personalizado com.example.app : redirect_uri_path

ou

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.app é a notação de DNS inversa de um domínio sob seu controle. O esquema personalizado deve conter um período para ser válido.
  • com.googleusercontent.apps.123 é a notação DNS reverso da ID do cliente.
  • redirect_uri_path é um componente do caminho opcional, tal como /oauth2redirect . Observe que o caminho deve começar com uma única barra, que é diferente de URLs HTTP regulares.
Endereço IP de loopback http://127.0.0.1: port ou http://[::1]: port

Consulte sua plataforma para obter o endereço IP de loopback relevante e inicie um ouvinte HTTP em uma porta disponível aleatória. Substituto port com o número da porta real do seu aplicativo escuta.

Copiar / colar manual urn:ietf:wg:oauth:2.0:oob
Extração programática urn:ietf:wg:oauth:2.0:oob:auto
response_type Obrigatório

Determina se o endpoint do Google OAuth 2.0 retorna um código de autorização.

Defina o valor do parâmetro para code para aplicativos instalados.

scope Obrigatório

Uma lista de escopos delimitada por espaço que identifica os recursos que seu aplicativo pode acessar em nome do usuário. Esses valores informam a tela de consentimento que o Google exibe para o usuário.

Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos de que precisa, ao mesmo tempo que permite que os usuários controlem a quantidade de acesso que concedem ao seu aplicativo. Assim, existe uma relação inversa entre o número de escopos solicitados e a probabilidade de obtenção do consentimento do usuário.

code_challenge Recomendado

Especifica um codificado code_verifier que será usado como um desafio do lado do servidor durante a troca de código de autorização. Este parâmetro deve ser usado com o code_challenge parâmetro descrito acima. Veja criar desafio do código de seção acima para mais informações.

code_challenge_method Recomendado

Especifica o que método foi usado para codificar um code_verifier que será usado durante a troca de código de autorização. Este parâmetro deve ser usado com o code_challenge parâmetro. O valor dos code_challenge_method o padrão é plain se não estiver presente na solicitação que inclui um code_challenge . Os valores com suporte apenas para este parâmetro são S256 ou plain .

state Recomendado

Especifica qualquer valor de string que seu aplicativo usa para manter o estado entre sua solicitação de autorização e a resposta do servidor de autorização. O servidor retorna o valor exato que você enviar como um name=value par no identificador de fragmento de URL ( # ) do redirect_uri após o usuário consentir ou nega pedido de acesso do seu aplicativo.

Você pode usar esse parâmetro para vários fins, como direcionar o usuário ao recurso correto em seu aplicativo, enviar nonces e atenuar a falsificação de solicitação entre sites. Desde a sua redirect_uri pode ser adivinhada, usando um state valor pode aumentar a sua garantia de que uma conexão de entrada é o resultado de uma solicitação de autenticação. Se você gerar uma string aleatória ou codificar o hash de um cookie ou outro valor que capture o estado do cliente, poderá validar a resposta para garantir adicionalmente que a solicitação e a resposta foram originadas no mesmo navegador, fornecendo proteção contra ataques como cross-site pedido de falsificação. Veja o OpenID Ligação documentação para um exemplo de como criar e confirmar um state token.

login_hint Opcional

Se seu aplicativo souber qual usuário está tentando autenticar, ele pode usar este parâmetro para fornecer uma dica ao servidor de autenticação do Google. O servidor usa a dica para simplificar o fluxo de login, preenchendo previamente o campo de e-mail no formulário de login ou selecionando a sessão multi-login apropriada.

Defina o valor do parâmetro para um endereço de e-mail ou sub identificador, que é equivalente ao do usuário do Google ID.

URLs de autorização de amostra

As guias abaixo mostram exemplos de URLs de autorização para as diferentes opções de URI de redirecionamento.

As URLs são idênticos, exceto para o valor da redirect_uri parâmetro. As URLs também conter o exigido response_type e client_id parâmetros, bem como o opcional state parâmetro. Cada URL contém quebras de linha e espaços para facilitar a leitura.

Esquema URI personalizado

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

Endereço IP de loopback

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Copiar colar

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

Extração programática

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

Etapa 3: o Google solicita consentimento do usuário

Nesta etapa, o usuário decide se concederá ao aplicativo o acesso solicitado. Nesse estágio, o Google exibe uma janela de consentimento que mostra o nome de seu aplicativo e os serviços de API do Google aos quais está solicitando permissão de acesso com as credenciais de autorização do usuário e um resumo dos escopos de acesso a serem concedidos. O usuário pode, então, consentir em conceder acesso a um ou mais escopos solicitados por seu aplicativo ou recusar a solicitação.

Seu aplicativo não precisa fazer nada neste estágio, pois aguarda a resposta do servidor OAuth 2.0 do Google indicando se algum acesso foi concedido. Essa resposta é explicada na etapa a seguir.

Erros

As solicitações para o ponto de extremidade de autorização OAuth 2.0 do Google podem exibir mensagens de erro voltadas para o usuário em vez dos fluxos de autenticação e autorização esperados. Códigos de erro comuns e soluções sugeridas estão listados abaixo.

admin_policy_enforced

A Conta do Google não pode autorizar um ou mais escopos solicitados devido às políticas do administrador do Google Workspace. Veja o artigo de ajuda do Google Workspace admin Controle quais de terceiros e aplicativos internos acessar os dados do Google Workspace para mais informações sobre como um administrador pode restringir o acesso a todos os escopos ou escopos sensíveis e restritos até que o acesso é explicitamente concedido ao seu ID do cliente OAuth.

disallowed_useragent

O ponto final de autorização é apresentada dentro de um agente de utilizador incorporado anulado por do Google Regulamentos OAuth 2.0 .

Android

Desenvolvedores Android pode encontrar essa mensagem de erro ao abrir pedidos de autorização emandroid.webkit.WebView . Desenvolvedores deve usar bibliotecas Android, como o login do Google para Android ou do OpenID Foundation AppAuth para Android .

Os desenvolvedores da web podem encontrar esse erro quando um aplicativo Android abre um link geral da web em um agente de usuário incorporado e um usuário navega para o endpoint de autorização OAuth 2.0 do Google a partir do seu site. Os desenvolvedores devem permitir ligações gerais para abrir no manipulador link padrão do sistema operacional, que inclui tanto Android App Ligações manipuladores ou o aplicativo navegador padrão. O Android personalizado Tabs biblioteca também é uma opção suportada.

iOS

iOS e MacOS desenvolvedores podem encontrar esse erro ao abrir pedidos de autorização emWKWebView . Desenvolvedores deve usar bibliotecas iOS, como o login do Google para iOS ou do OpenID Foundation AppAuth para iOS .

Os desenvolvedores da web podem encontrar esse erro quando um aplicativo iOS ou macOS abre um link geral da web em um user-agent integrado e um usuário navega para o endpoint de autorização OAuth 2.0 do Google a partir do seu site. Os desenvolvedores devem permitir ligações gerais para abrir no manipulador link padrão do sistema operacional, que inclui tanto Universal Ligações manipuladores ou o aplicativo navegador padrão. OSFSafariViewController biblioteca também é uma opção suportada.

org_internal

O ID do cliente OAuth no pedido é parte de um projeto limitando o acesso a contas do Google em um determinado Organização Google Cloud . Para mais informações sobre esta opção de configuração ver o tipo de usuário seção no Configurando o consentimento OAuth tela de ajuda artigo.

redirect_uri_mismatch

O redirect_uri passados na solicitação de autorização não coincide com um redirecionamento autorizado URI para o ID do cliente OAuth. Revisão autorizada URIs de redirecionamento na Google API Console Credentials page.

O passado redirect_uri pode ser inválido para o tipo de cliente.

Etapa 4: lidar com a resposta do servidor OAuth 2.0

A maneira pela qual o seu aplicativo recebe a resposta de autorização depende do esquema de URI de redirecionamento que ele usa. Independentemente do mecanismo, a resposta será ou conter um código de autorização ( code ) ou um erro ( error ). Por exemplo, error=access_denied indica que o usuário recusou o pedido.

Se o usuário conceder acesso ao seu aplicativo, você pode trocar o código de autorização por um token de acesso e um token de atualização conforme descrito na próxima etapa.

Etapa 5: troque o código de autorização por tokens de atualização e acesso

Para trocar um código de autorização para um token de acesso, ligue para o https://oauth2.googleapis.com/token endpoint e definir os seguintes parâmetros:

Campos
client_id O ID do cliente obtido a partir da API ConsoleCredentials page.
client_secret O segredo do cliente obtido a partir da API ConsoleCredentials page.
code O código de autorização retornado da solicitação inicial.
code_verifier O código verificador você criou na etapa 1 .
grant_type Tal como definido na especificação OAuth 2.0 , o valor deste campo deve ser configurado para authorization_code .
redirect_uri Um dos URIs de redirecionamento listados para seu projeto no API ConsoleCredentials page para o dado client_id .

O snippet a seguir mostra um exemplo de solicitação:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

O Google responde a essa solicitação retornando um objeto JSON que contém um token de acesso de curta duração e um token de atualização.

A resposta contém os seguintes campos:

Campos
access_token O token que seu aplicativo envia para autorizar uma solicitação de API do Google.
expires_in A vida útil restante do token de acesso em segundos.
id_token Nota: Esta propriedade só é devolvido se o seu pedido incluído um escopo de identidade, tais como openid , profile , ou email . O valor é um JSON Web Token (JWT) que contém informações de identidade assinadas digitalmente sobre o usuário.
refresh_token Um token que você pode usar para obter um novo token de acesso. Os tokens de atualização são válidos até que o usuário revogue o acesso. Observe que os tokens de atualização sempre são retornados para os aplicativos instalados.
scope Os escopos de acesso concedida pelo access_token expressa como uma lista de delimitado por espaço, cordas maiúsculas de minúsculas.
token_type O tipo de token retornado. Neste momento, o valor desse campo é sempre definido como Bearer .

O snippet a seguir mostra um exemplo de resposta:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Chamando APIs do Google

Depois que seu aplicativo obtém um token de acesso, você pode usar o token para fazer chamadas para uma API do Google em nome de uma determinada conta de usuário, se o (s) escopo (s) de acesso exigido pela API tiver sido concedido. Para fazer isso, inclua o token de acesso em uma solicitação para a API, incluindo tanto uma access_token parâmetro de consulta ou um Authorization HTTP cabeçalho Bearer de valor. Quando possível, o cabeçalho HTTP é preferível, porque as sequências de consulta tendem a ser visíveis nos logs do servidor. Na maioria dos casos, você pode usar uma biblioteca cliente para configurar suas chamadas para APIs do Google (por exemplo, quando chamar a API arquivos da unidade ).

Você pode experimentar todo o Google APIs e exibir seus escopos no OAuth 2.0 Playground .

Exemplos HTTP GET

Uma chamada para a drive.files endpoint (a API Arquivos Drive) utilizando o Authorization: Bearer cabeçalho HTTP pode parecer o seguinte. Observe que você precisa especificar seu próprio token de acesso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Aqui está uma chamada para a mesma API para o usuário autenticado usando o access_token parâmetro string de consulta:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl exemplos

Você pode testar esses comandos com a curl aplicativo de linha de comando. Aqui está um exemplo que usa a opção de cabeçalho HTTP (preferencial):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Ou, alternativamente, a opção de parâmetro de string de consulta:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Atualizando um token de acesso

Os tokens de acesso expiram periodicamente e se tornam credenciais inválidas para uma solicitação de API relacionada. Você pode atualizar um token de acesso sem solicitar permissão do usuário (incluindo quando o usuário não está presente) se você solicitou acesso offline aos escopos associados ao token.

Para atualizar um token de acesso, o aplicativo envia um HTTPS POST pedido ao servidor de autorização do Google ( https://oauth2.googleapis.com/token ), que inclui os seguintes parâmetros:

Campos
client_id O ID do cliente obtido a partir da API Console.
client_secret O segredo do cliente obtido a partir da API Console. (O client_secret não é aplicável aos pedidos dos clientes cadastrados como Android, iOS ou aplicações do Chrome.)
grant_type Como definido na especificação OAuth 2.0 , o valor deste campo deve ser configurado para refresh_token .
refresh_token O token de atualização retornado da troca do código de autorização.

O snippet a seguir mostra um exemplo de solicitação:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Desde que o usuário não revogue o acesso concedido ao aplicativo, o servidor de token retorna um objeto JSON que contém um novo token de acesso. O snippet a seguir mostra um exemplo de resposta:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

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 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.

Revogando um token

Em alguns casos, um usuário pode desejar revogar o acesso concedido a um aplicativo. Um usuário pode revogar o acesso, visitando Configurações de Conta . Veja a seção de acesso Remover site ou aplicativo de sites e aplicativos de terceiros com acesso à sua conta documento de suporte para mais informações.

Também é possível que um aplicativo revogue programaticamente o acesso concedido a ele. A revogação programática é importante nos casos em que um usuário cancela a assinatura, remove um aplicativo ou os recursos de API exigidos por um aplicativo mudaram significativamente. Em outras palavras, parte do processo de remoção pode incluir uma solicitação de API para garantir que as permissões concedidas anteriormente ao aplicativo sejam removidas.

Para revogar programaticamente um token, o aplicativo faz uma solicitação para https://oauth2.googleapis.com/revoke e inclui o token como um parâmetro:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

O token pode ser um token de acesso ou um token de atualização. Se o token for um token de acesso e tiver um token de atualização correspondente, o token de atualização também será revogado.

Se a revogação for processada com êxito, em seguida, o código de status HTTP da resposta é 200 . Para as condições de erro, um código de status HTTP 400 é devolvido junto com um código de erro.

Leitura Adicional

O IETF melhores práticas correntes OAuth 2.0 para Native Apps estabelece muitas das melhores práticas documentadas aqui.