OAuth 2.0 para aplicativos móveis e de desktop

Este documento explica como os aplicativos instalados em dispositivos como telefones, tablets e computadores usam os endpoints 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 o 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 supõe-se que esses aplicativos não podem manter segredos. Eles podem acessar as APIs do Google enquanto o usuário está presente no aplicativo ou quando o aplicativo está sendo executado em segundo plano.

Esse fluxo de autorização é semelhante ao usado para aplicativos 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 aplicativos móveis, você pode preferir usar o Login do Google para Android ou iOS . As bibliotecas de cliente do Login do Google lidam com autenticação e 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 oferecem suporte a 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 Login em TVs e dispositivos de entrada limitados .

Bibliotecas e amostras

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

Pré-requisitos

Habilite APIs para seu projeto

Qualquer aplicativo que chame as APIs do Google precisa ativar essas APIs no API Console.

Para habilitar uma API para seu projeto:

  1. Open the API Library no Google API Console.
  2. If prompted, select a project, or create a new one.
  3. O API Library lista todas as APIs disponíveis, agrupadas por família de produtos e popularidade. Se a API que você deseja ativar não estiver visível na lista, use a pesquisa para encontrá-la ou clique em Visualizar tudo na família de produtos à qual ela pertence.
  4. Selecione a API que deseja habilitar e clique no botão Habilitar .
  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 OAuth 2.0 para acessar as APIs do Google deve 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. Seus aplicativos podem usar as credenciais para acessar as APIs que você habilitou para esse 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 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 UWP (Plataforma Universal do Windows).

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

    Insira o ID da App Store do seu aplicativo se o aplicativo estiver 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 (símbolo 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 da URL.

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

  5. (Opcional)

    Digite o ID da sua equipe. Consulte Localize sua ID de equipe na documentação da conta de desenvolvedor da Apple para obter mais informações.

  6. Clique em Criar .
UWP
  1. Selecione o tipo de aplicativo da Plataforma Universal do Windows .
  2. Insira um nome para o cliente OAuth. Esse nome é exibido no Credentials page do seu projeto para identificar o cliente.
  3. Insira a ID da Microsoft Store de 12 caracteres do seu aplicativo. Você pode encontrar esse valor no Microsoft Partner Center na página Identidade do aplicativo na seção Gerenciamento de aplicativos.
  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 esta URL, seu aplicativo deve estar escutando no servidor web local. Isso é possível em muitas plataformas, mas não em todas. No entanto, se a sua plataforma suportar, 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 instrua o usuário a fechar o navegador e retornar ao seu aplicativo.

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

Copiar/colar manualmente

Identificar escopos de acesso

Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos de que precisa, ao mesmo tempo em que permitem 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 obter o consentimento do usuário.

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

O documento Escopos da API OAuth 2.0 contém uma lista completa de escopos que você pode usar para acessar as APIs do Google.

Como obter 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 exija autorização do usuário.

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

O Google oferece suporte ao protocolo Proof Key for Code Exchange (PKCE) para tornar o fluxo do aplicativo instalado mais seguro. Um verificador de código exclusivo é criado para cada solicitação de autorização e seu valor transformado, chamado "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 string aleatória criptográfica de alta entropia usando os caracteres não reservados [AZ] / [az] / [0-9] / "-" / "." / "_" / "~", com um comprimento mínimo de 43 caracteres e um comprimento máximo de 128 caracteres.

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

Criar o desafio de código

Há suporte para dois métodos de criação do desafio de código.

Métodos de geração de desafio 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)))
avião 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 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 manipula a pesquisa de sessão ativa, autentica o usuário e obtém o consentimento do usuário. O ponto de extremidade só é acessível por SSL e recusa conexões HTTP (não SSL).

O servidor de autorização suporta os seguintes parâmetros de string de consulta para aplicativos instalados:

Parâmetros
client_id Requerido

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

redirect_uri Requerido

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á configurado suas credenciais de autorização com um método de redirecionamento específico em mente.

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

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

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

ou

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.app é a notação DNS reversa 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 reversa do ID do cliente.
  • redirect_uri_path é um componente de caminho opcional, como /oauth2redirect . Observe que o caminho deve começar com uma única barra, diferente de URLs HTTP normais.
Endereço IP de retorno 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. Substitua a port pelo número da porta real em que seu aplicativo escuta.

response_type Requerido

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 Requerido

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 ao usuário.

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

code_challenge Recomendado

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

code_challenge_method Recomendado

Especifica qual 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 parâmetro code_challenge descrito acima. O valor do code_challenge_method é padronizado como plain se não estiver presente na solicitação que inclui um code_challenge . Os únicos valores suportados para este parâmetro são S256 ou plain .

state Recomendado

Especifica qualquer valor de cadeia 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ê envia como um par 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 seu aplicativo.

Você pode usar esse parâmetro para várias finalidades, como direcionar o usuário para o recurso correto em seu aplicativo, enviar nonces e mitigar a falsificação de solicitação entre sites. Como seu redirect_uri pode ser adivinhado, usar um valor de state pode aumentar 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 tenham origem no mesmo navegador, fornecendo proteção contra ataques como cross-site solicitar falsificação. Consulte a documentação do OpenID Connect para obter um exemplo de como criar e confirmar um token de state .

login_hint Opcional

Se seu aplicativo souber qual usuário está tentando autenticar, ele poderá usar esse 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 de login múltiplo apropriada.

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

URLs de autorização de amostra

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

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

Esquema de 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 retorno

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

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

Nesta etapa, o usuário decide se concede ao seu aplicativo o acesso solicitado. Nesta fase, o Google exibe uma janela de consentimento que mostra o nome do seu aplicativo e os serviços de API do Google aos quais está solicitando permissão para acessar 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 pelo 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 endpoint de autorização OAuth 2.0 do Google podem exibir mensagens de erro voltadas para o usuário em vez dos fluxos esperados de autenticação e autorização. Os códigos de erro comuns e as resoluçõ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 aplicativos internos e de terceiros acessam os dados do Google Workspace para obter 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 de cliente OAuth.

disallowed_useragent

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

Android

Os desenvolvedores do Android podem encontrar essa mensagem de erro ao abrir solicitações de autorização emandroid.webkit.WebView . Os desenvolvedores devem usar bibliotecas do Android, como o Google Sign-In para Android ou o AppAuth da OpenID Foundation para Android .

Os desenvolvedores da Web podem encontrar esse erro quando um aplicativo Android abre um link geral da Web em um user agent 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 que links gerais sejam abertos no gerenciador de links padrão do sistema operacional, que inclui os gerenciadores de links de aplicativos Android ou o aplicativo de navegador padrão. A biblioteca de guias personalizadas do Android também é uma opção compatível.

iOS

Os desenvolvedores de iOS e macOS podem encontrar esse erro ao abrir solicitações de autorização noWKWebView . Os desenvolvedores devem usar bibliotecas do iOS, como o Login do Google para iOS ou o AppAuth da OpenID Foundation 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 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 que links gerais sejam abertos no manipulador de links padrão do sistema operacional, que inclui os manipuladores de links universais ou o aplicativo de navegador padrão. A bibliotecaSFSafariViewController também é uma opção com suporte.

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 específica do Google Cloud . Para obter mais informações sobre essa opção de configuração, consulte a seção Tipo de usuário no artigo de ajuda Configurando sua tela de consentimento OAuth.

redirect_uri_mismatch

O redirect_uri passado 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 passado pode ser inválido para o tipo de cliente.

Etapa 4: lidar com a resposta do servidor OAuth 2.0

A maneira pela qual seu aplicativo recebe a resposta de autorização depende do esquema de URI de redirecionamento que ele usa. 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 seu 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 para 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 obtido do API ConsoleCredentials page.
client_secret O segredo do cliente obtido do API ConsoleCredentials 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 OAuth 2.0 , o valor deste campo deve ser definido como authorization_code .
redirect_uri Um dos URIs de redirecionamento listados para seu projeto no API ConsoleCredentials page para o client_id fornecido.

O snippet a seguir mostra uma solicitação de amostra:

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%3A//127.0.0.1%3A9004&
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 O tempo 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 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 aplicativos instalados.
scope Os escopos de acesso concedidos pelo access_token expressos como uma lista de strings delimitadas por espaço e que diferenciam maiúsculas de minúsculas.
token_type O tipo de token retornado. Neste momento, o valor deste 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 obtiver um token de acesso, você poderá usar o token para fazer chamadas para 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 à API incluindo um parâmetro de consulta access_token ou um valor de Bearer do cabeçalho HTTP de Authorization . Quando possível, o cabeçalho HTTP é preferível, porque as strings 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 as APIs do Google (por exemplo, ao chamar a API Drive Files ).

Você pode experimentar todas as APIs do Google e visualizar seus escopos 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 ter a seguinte aparência. 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 parâmetro de string de consulta access_token :

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

exemplos curl

Você pode testar esses comandos com o aplicativo de linha de comando curl . 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 ao usuário (inclusive quando o usuário não estiver presente) se tiver solicitado acesso offline 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 O ID do cliente obtido do API Console.
client_secret O segredo do cliente obtido 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 OAuth 2.0 , o valor desse campo deve 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 uma solicitação de amostra:

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 tenha revogado o acesso concedido ao aplicativo, o servidor de token retornará 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 no 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 os 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 poderá atingir esses limites e, nesse caso, os tokens de atualização mais antigos deixarão de funcionar.

Revogar um token

Em alguns casos, um usuário pode querer revogar o acesso dado a um aplicativo. Um usuário pode revogar o acesso visitando Configurações da conta . Consulte a seção Remover acesso ao site ou aplicativo dos sites e aplicativos de terceiros com acesso ao documento de suporte da sua conta para obter 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 inscrição, remove um aplicativo ou os recursos de API exigidos por um aplicativo foram significativamente alterados. 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 programaticamente, seu aplicativo faz uma solicitação para https://oauth2.googleapis.com/revoke e inclui o token como 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, o código de status HTTP da resposta será 200 . Para condições de erro, um código de status HTTP 400 é retornado junto com um código de erro.

Leitura adicional

A Melhor prática atual da IETF OAuth 2.0 para aplicativos nativos estabelece muitas das melhores práticas documentadas aqui.