OAuth 2.0 para apps para computador e dispositivos móveis

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.
Consulte 1 A visão geral resume os fluxos do OAuth 2.0 compatíveis com o Google, que podem ajudar a garantir que você selecione o fluxo correto para seu aplicativo.

Este documento explica como aplicativos instalados em dispositivos como smartphones, tablets e computadores usam endpoints do OAuth 2.0 do Google para autorizar o acesso a APIs do Google.

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

Os apps instalados são distribuídos em dispositivos individuais, e o pressuposto é que esses apps não podem manter secrets. Eles podem acessar as APIs do Google enquanto o usuário está no app ou quando ele está em execução em segundo plano.

Esse fluxo de autorização é semelhante ao usado em aplicativos do servidor da Web. A principal diferença é que os apps instalados precisam abrir o navegador do sistema e fornecer um URI de redirecionamento local para processar as respostas do servidor de autorização do Google.

Alternativas

Em apps para dispositivos móveis, talvez você prefira usar o Login do Google para Android ou iOS. As bibliotecas de cliente do Login do Google processam a autenticação e a autorização do usuário. Elas podem ser mais simples de implementar do que o protocolo de nível inferior descrito aqui.

Para apps executados em dispositivos que não são compatíveis com um navegador do sistema ou que têm recursos de entrada limitados, como TVs, consoles de jogos, câmeras ou impressoras, consulte OAuth 2.0 para TVs e dispositivos ou Fazer login em TVs e dispositivos de entrada limitada.

Bibliotecas e amostras

Recomendamos as seguintes bibliotecas e amostras para ajudar você a implementar o fluxo do OAuth 2.0 descrito neste documento:

Prerequisites

Ativar as APIs do projeto

Todo aplicativo que chama APIs do Google precisa ativar essas APIs no API Console.

Para ativar uma API para um projeto, faça o seguinte:

  1. Open the API Library no Google API Console.
  2. If prompted, select a project, or create a new one.
  3. A API Library lista todas as APIs disponíveis agrupadas por família de produtos e popularidade. Se a API que você quer ativar não estiver visível na lista, use a pesquisa para encontrá-la ou clique em Ver tudo na família de produtos à qual ela pertence.
  4. Selecione a API que você quer ativar e clique no botão Ativar.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Criar credenciais de autorização

Qualquer aplicativo que use o OAuth 2.0 para acessar as APIs do Google precisa ter credenciais de autorização que identifiquem o aplicativo para o servidor OAuth 2.0 do Google. As etapas a seguir explicam como criar credenciais para seu projeto. Os aplicativos poderão usar as credenciais para acessar as APIs ativadas para o projeto.

  1. Go to the Credentials page.
  2. Clique em Criar credenciais > ID do cliente OAuth.
  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 o aplicativo, nomeie o cliente OAuth e configure os outros campos do formulário conforme apropriado.

Esquema de URI personalizado (Android, iOS, UWP)

Um esquema de URI personalizado é recomendado para apps Android, iOS e da Universal Windows Platform (UWP).

Android
  1. Selecione o tipo de aplicativo Android.
  2. Digite um nome para o cliente OAuth. Esse nome é exibido no Credentials page do projeto para identificar o cliente.
  3. Digite o nome do pacote do seu app Android. Esse valor é definido no atributo package do elemento <manifest> no arquivo de manifesto do app.
  4. Digite a impressão digital do certificado de assinatura SHA-1 da distribuição do app.
    • Se o app usa a Assinatura de apps do Google Play, copie a impressão digital SHA-1 da página de assinatura do app do Play Console.
    • Se você gerencia seu próprio keystore e chaves de assinatura, use o utilitário keytool incluído no Java para imprimir informações de certificado em um formato legível. Copie o valor de SHA1 na seção Certificate fingerprints da saída de keytool. Consulte Como autenticar seu cliente na documentação das APIs do Google para Android se quiser mais informações.
  5. Clique em Criar.
iOS
  1. Selecione o tipo de aplicativo iOS.
  2. Digite um nome para o cliente OAuth. Esse nome é exibido no Credentials page do projeto para identificar o cliente.
  3. Insira o identificador do pacote do seu aplicativo. O ID do pacote é o valor da chave CFBundleIdentifier no arquivo de recurso da lista de propriedades de informações do seu app (info.plist). O valor é normalmente exibido no painel "General" ou no painel "Signing & Capabilities" do editor de projeto do Xcode. O ID do pacote também é exibido na seção "Informações gerais" da página "Informações do app" no site App Store Connect da Apple.
  4. (Opcional)

    Insira o ID da App Store se ele estiver publicado na App Store da Apple. O ID da loja é uma string numérica incluída em todos os URLs da Apple App Store.

    1. Abra o app Apple App Store no seu dispositivo iOS ou iPadOS.
    2. Procure seu app.
    3. Selecione o botão "Compartilhar" (ícone quadrado e 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/id284815942

  5. (Opcional)

    Digite seu ID de equipe. Para mais informações, consulte Localizar o ID da equipe na documentação da conta de desenvolvedor da Apple.

  6. Clique em Criar.
UWP,
  1. Selecione o tipo de aplicativo da Plataforma Universal do Windows.
  2. Digite um nome para o cliente OAuth. Esse nome é exibido no Credentials page do projeto para identificar o cliente.
  3. Insira o ID da Microsoft Store de 12 caracteres do app. Esse valor pode ser encontrado na Central de parceiros da Microsoft na página Identidade do app na seção "Gerenciamento de aplicativos".
  4. Clique em Criar.

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

Endereço IP de loopback (macOS, Linux, Windows Desktop)

Para receber o código de autorização usando esse URL, o aplicativo precisa estar ouvindo no servidor da Web local. Isso é possível em muitas plataformas, mas não em todas. No entanto, se ela for compatível com esse formato, este é o mecanismo recomendado para conseguir o código de autorização.

Quando seu app 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 app.

Uso recomendado Aplicativos para macOS, Linux e Windows (mas não para a Plataforma Universal Windows)
Valores de formulário Defina o tipo de aplicativo como App para computador.

Copiar/colar manualmente

Identificar escopos de acesso

Os escopos permitem que o aplicativo solicite acesso apenas aos recursos necessários, além de permitir que os usuários controlem o acesso concedido ao aplicativo. Portanto, pode haver uma relação inversa entre o número de escopos solicitados e a probabilidade de aprovação do usuário.

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

O documento Escopos da API OAuth 2.0 contém uma lista completa de escopos que podem ser usados para acessar as APIs do Google.

Como acessar tokens de acesso do OAuth 2.0

As etapas a seguir mostram como seu aplicativo interage com o servidor OAuth 2.0 do Google para solicitar o consentimento de um usuário e realizar uma solicitação de API em nome dele. O aplicativo precisa ter o consentimento antes de executar uma solicitação de API do Google que exija autorização do usuário.

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

O Google é compatível com o protocolo Proof Key for Code Exchange (PKCE, na sigla em inglês) para tornar o fluxo do app instalado mais seguro. Um verificador de código exclusivo é criado para cada solicitação de autorização, e o valor transformado, chamado "code_challenge", é enviado ao servidor de autorização para receber o código de autorização.

Criar o verificador de código

Uma code_verifier é uma string aleatória criptográfica de alta entropia que usa os caracteres não reservados [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" com tamanho mínimo de 43 caracteres e 8 caracteres.

O verificador do código precisa ter entropia suficiente para que seja impraticável adivinhar o valor.

Criar o desafio de código

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

Métodos de geração de desafios de código
S256 (recomendado) O desafio de código é o hash SHA256 codificado em Base64URL (sem preenchimento) do verificador de código.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
simples O desafio de código é 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, envie uma solicitação ao servidor de autorização do Google em https://accounts.google.com/o/oauth2/v2/auth. Esse endpoint processa a pesquisa da sessão ativa, autentica o usuário e recebe o consentimento dele. O endpoint só pode ser acessado via SSL e recusa conexões HTTP (não SSL).

O servidor de autorização é compatível com os seguintes parâmetros de string de consulta para aplicativos instalados:

Parâmetros
client_id Obrigatório

O ID do cliente do seu aplicativo. Esse valor está no API Console Credentials page.

redirect_uri Obrigatório

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

O valor precisa corresponder exatamente a um dos URIs de redirecionamento autorizados para o cliente OAuth 2.0, configurados no cliente API ConsoleCredentials page. Se esse valor não corresponder a um URI autorizado, você receberá um erro redirect_uri_mismatch.

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

Valores redirect_uri
Esquema de URI personalizado com.example.app:redirect_uri_path

,

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app é a notação de DNS reversa de um domínio controlado por você. O esquema personalizado precisa conter um ponto para ser válido.
  • com.googleusercontent.apps.123 é a notação de DNS reversa do ID do cliente.
  • redirect_uri_path é um componente de caminho opcional, como /oauth2redirect. O caminho precisa começar com uma única barra, que é diferente dos URLs HTTP normais.
Endereço IP de loopback http://127.0.0.1:port ou http://[::1]:port

Consulte na sua plataforma o endereço IP de loopback relevante e inicie um listener HTTP em uma porta aleatória disponível. Substitua port pelo número da porta que seu app detecta.

A compatibilidade com a opção de redirecionamento de endereço IP de loopback em apps para dispositivos móveis é SUSPENSA.

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 como code para apps instalados.

scope Obrigatório

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

Os escopos permitem que o aplicativo solicite acesso apenas aos recursos necessários, além de permitir que os usuários controlem o acesso concedido ao aplicativo. Assim, há uma relação inversa entre o número de escopos solicitados e a probabilidade de recebimento do consentimento do usuário.

code_challenge Recomendado

Especifica um code_verifier codificado que será usado como um desafio no lado do servidor durante a troca do código de autorização. Consulte a seção Criar desafio de código acima para ver mais informações.

code_challenge_method Recomendado

Especifica qual método foi usado para codificar um code_verifier que será usado durante a troca do código de autorização. Esse parâmetro precisa ser usado com o parâmetro code_challenge descrito acima. O valor de code_challenge_method será definido como plain se não estiver presente na solicitação que inclui um code_challenge. Os únicos valores compatíveis com esse parâmetro são S256 ou plain.

state Recomendado

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

É possível usar esse parâmetro para várias finalidades, como direcionar o usuário ao recurso correto no aplicativo, enviar valores de uso único e atenuar a falsificação de solicitações entre sites. Como o redirect_uri pode ser deduzido, usar um valor state pode aumentar a 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, será possível validar a resposta para garantir que a solicitação e a resposta sejam provenientes do mesmo navegador, fornecendo proteção contra ataques, como falsificação de solicitação entre sites. Consulte a documentação do OpenID Connect para ver um exemplo de como criar e confirmar um token state.

login_hint Opcional

Se seu aplicativo souber qual usuário está tentando autenticar, ele poderá usar esse parâmetro para dar uma dica para o servidor de autenticação do Google. O servidor usa a dica para simplificar o fluxo de login preenchendo o campo de e-mail no formulário de login ou selecionando a sessão de login múltiplo adequada.

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

Exemplos de URLs de autorização

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

Os URLs são idênticos, exceto pelo valor do parâmetro redirect_uri. Os URLs também contêm os parâmetros response_type e client_id obrigatórios, bem como o parâmetro opcional state. Cada URL contém quebras de linha e espaços para legibilidade.

Esquema de URI personalizado

https://accounts.google.com/o/oauth2/v2/auth?
 scope=&
 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=&
 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

Etapa 3: o Google solicita o consentimento do usuário

Nesta etapa, o usuário decide se quer conceder ao seu app o acesso solicitado. Nessa etapa, o Google exibe uma janela de consentimento que mostra o nome do aplicativo e os serviços da API do Google que estão solicitando permissão de acesso com as credenciais de autorização do usuário, além de um resumo dos escopos de acesso a serem concedidos. O usuário pode consentir para conceder acesso a um ou mais escopos solicitados pelo aplicativo ou recusar a solicitação.

Seu aplicativo não precisa fazer nada neste momento porque 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 endpoint de autorização do 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. Os códigos de erro comuns e as 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. Consulte o artigo de ajuda do administrador do Google Workspace Controlar quais apps internos de terceiros acessam os dados do Google Workspace para mais informações sobre como um administrador pode restringir o acesso a todos os escopos ou escopos confidenciais e restritos até que o acesso seja concedido explicitamente ao seu ID do cliente OAuth.

disallowed_useragent

O endpoint de autorização é exibido em um user agent incorporado não permitido pelas políticas do OAuth 2.0 do Google.

Android

Os desenvolvedores Android podem encontrar essa mensagem de erro ao abrir solicitações de autorização em android.webkit.WebView. Em vez disso, os desenvolvedores precisam usar bibliotecas do Android, como o Login do Google para Android ou o AppAuth para Android da OpenID Foundation.

Os desenvolvedores da Web podem encontrar esse erro quando um app Android abre um link da Web geral em um user agent incorporado e um usuário navega para o endpoint de autorização do OAuth 2.0 do Google no seu site. Os desenvolvedores precisam permitir que links gerais sejam abertos no gerenciador de links padrão do sistema operacional, que inclui gerenciadores de Links do app Android ou o app de navegação padrão. A biblioteca Guias personalizadas do Android também é uma opção compatível.

iOS

Os desenvolvedores iOS e macOS podem encontrar esse erro ao abrir solicitações de autorização no WKWebView. Em vez disso, os desenvolvedores precisam usar bibliotecas do iOS, como o Login do Google para iOS ou o AppAuth para iOS da OpenID Foundation.

Os desenvolvedores da Web podem encontrar esse erro quando um app iOS ou macOS abre um link da Web geral em um user agent incorporado e um usuário navega para o endpoint de autorização do OAuth 2.0 do seu site. Os desenvolvedores precisam permitir que links gerais sejam abertos no gerenciador de links padrão do sistema operacional, que inclui gerenciadores do Universal Links ou o app de navegação padrão. A biblioteca SFSafariViewController também é uma opção compatível.

org_internal

O ID do cliente OAuth na solicitação faz parte de um projeto que limita o acesso a Contas do Google em uma organização do Google Cloud específica. Para mais informações sobre essa opção de configuração, consulte a seção Tipo de usuário no artigo de configuração da tela de consentimento OAuth.

redirect_uri_mismatch

O redirect_uri transmitido na solicitação de autorização não corresponde a um URI de redirecionamento autorizado para o ID do cliente OAuth. Revise os URIs de redirecionamento autorizados no Google API Console Credentials page.

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

Etapa 4: processar a resposta do servidor OAuth 2.0

A maneira como o aplicativo recebe a resposta de autorização depende do esquema de URI de redirecionamento usado. Independentemente do esquema, a resposta conterá um código de autorização (code) ou um erro (error). Por exemplo, error=access_denied indica que o usuário recusou a solicitação.

Se o usuário conceder acesso ao aplicativo, você poderá 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: trocar o código de autorização dos tokens de atualização e acesso

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

Campos
client_id O ID do cliente recebido do API Console Credentials page.
client_secret A chave secreta do cliente recebida do API Console Credentials page.
code O código de autorização retornado da solicitação inicial.
code_verifier O verificador de código que você criou na Etapa 1.
grant_type Conforme definido na especificação do OAuth 2.0, defina o valor deste campo como authorization_code.
redirect_uri Um dos URIs de redirecionamento listados para seu projeto no API Console Credentials page de cada 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=http://127.0.0.1:9004&
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 da API do Google.
expires_in O ciclo de vida restante do token de acesso em segundos.
id_token Observação: essa propriedade só será retornada se sua solicitação incluir um escopo de identidade, 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 pode ser usado para receber 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 são sempre retornados para aplicativos instalados.
scope Os escopos de acesso concedidos pelo access_token expressos como uma lista de strings delimitadas por espaços e diferenciando maiúsculas de minúsculas.
token_type O tipo de token retornado. No 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"
}

Como chamar APIs do Google

Depois que seu aplicativo receber um token de acesso, você poderá usá-lo para fazer chamadas a uma API do Google em nome de uma determinada conta de usuário se os escopos de acesso exigidos pela API tiverem sido concedidos. Para fazer isso, inclua o token de acesso em uma solicitação para a API incluindo um parâmetro de consulta access_token ou um valor Bearer de cabeçalho HTTP Authorization. Quando possível, prefira usar o cabeçalho HTTP, já que as strings de consulta costumam ficar visíveis nos registros do servidor. Na maioria dos casos, você pode usar uma biblioteca de cliente para configurar as chamadas para as APIs do Google (por exemplo, ao chamar a API Drive Files).

Você pode testar todas as APIs do Google e ver os escopos delas no OAuth 2.0 Playground.

Exemplos de HTTP GET

Uma chamada para o endpoint drive.files (a API Drive Files) usando o cabeçalho HTTP Authorization: Bearer pode ser semelhante a esta: 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

Esta é uma chamada para a mesma API para o usuário autenticado que usa o parâmetro de string de consulta access_token:

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

Exemplos de curl

É possível testar esses comandos com o aplicativo de linha de comando curl. Veja 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, como alternativa, a opção de parâmetro da string de consulta:

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

Atualização do token de acesso

Os tokens de acesso expiram periodicamente e se tornam credenciais inválidas para uma solicitação de API relacionada. É possível atualizar um token de acesso sem solicitar a permissão do usuário (inclusive quando ele não está presente) caso tenha solicitado acesso off-line aos escopos associados ao token.

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

Campos
client_id ID do cliente recebido do API Console.
client_secret Chave secreta do cliente recebida do API Console. O client_secret não se aplica a solicitações de clientes registrados como aplicativos Android, iOS ou Chrome.
grant_type Conforme definido na especificação do OAuth 2.0, o valor deste campo precisa ser definido como refresh_token.
refresh_token O token de atualização retornado da troca de 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"
}

Há limites para o número de tokens de atualização que serão emitidos: um limite por combinação cliente/usuário e outro por usuário em todos os clientes. Salve tokens de atualização no armazenamento de longo prazo e continue a usá-los, desde que eles permaneçam válidos. Se o aplicativo solicitar muitos tokens de atualização, ele poderá atingir esses limites. Nesse caso, os tokens de atualização mais antigos deixarão de funcionar.

Revogação de token

Em alguns casos, um usuário pode querer revogar o acesso concedido a um aplicativo. Um usuário pode revogar o acesso acessando as Configurações da conta. Para mais informações, consulte a seção Remover o acesso ao site ou app dos sites de terceiros &apps com acesso à sua conta.

Também é possível que um app revogue programaticamente o acesso concedido a ele. A revogação programática é importante nos casos em que um usuário cancela a inscrição, remove um aplicativo ou os recursos da API exigidos por um aplicativo mudam 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 um token de maneira programática, 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 de acesso ou de atualização. Se 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, o código de status HTTP da resposta será 200. Para condições de erro, um código de status HTTP 400 é retornado com um código de erro.

Leitura complementar

A prática recomendada atual do OAuth 2.0 para o OAuth 2.0 para apps nativos estabelece muitas das práticas recomendadas documentadas aqui.