Esta página foi traduzida pela API Cloud Translation.
Switch to English

Usando OAuth 2.0 para aplicativos de servidor da Web

Este documento explica como os aplicativos de servidor da web usam as bibliotecas de cliente da API do Google ou pontos de extremidade OAuth 2.0 do Google para implementar a autorização do OAuth 2.0 para acessar as 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.

Este fluxo OAuth 2.0 é especificamente para autorização do usuário. Ele é projetado para aplicativos que podem armazenar informações confidenciais e manter o estado. Um aplicativo de servidor da web devidamente autorizado pode acessar uma API enquanto o usuário interage com o aplicativo ou depois que o usuário sai do aplicativo.

Os aplicativos de servidor da Web frequentemente também usam contas de serviço para autorizar solicitações de API, principalmente ao chamar APIs de nuvem para acessar dados baseados em projetos, em vez de dados específicos do usuário. Os aplicativos de servidor da Web podem usar contas de serviço em conjunto com a autorização do usuário.

Bibliotecas cliente

Os exemplos específicos de idioma nesta página usam bibliotecas de cliente da API do Google para implementar a autorização OAuth 2.0. Para executar os exemplos de código, você deve primeiro instalar a biblioteca cliente para o seu idioma.

Quando você usa uma biblioteca de cliente da API do Google para lidar com o fluxo OAuth 2.0 de seu aplicativo, a biblioteca de cliente executa muitas ações que, de outra forma, o aplicativo precisaria lidar por conta própria. Por exemplo, ele determina quando o aplicativo pode usar ou atualizar tokens de acesso armazenados, bem como quando o aplicativo deve readquirir consentimento. A biblioteca cliente também gera URLs de redirecionamento corretos e ajuda a implementar manipuladores de redirecionamento que trocam códigos de autorização por tokens de acesso.

Bibliotecas cliente estão disponíveis para os seguintes idiomas:

Pré-requisitos

Ative APIs para seu projeto

Qualquer aplicativo que chama APIs do Google precisa habilitar 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 localizá-la ou clique em Exibir tudo na família de produtos à qual pertence.
  4. Selecione a API que deseja ativar e 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> ID do cliente OAuth .
  3. Selecione o tipo de aplicativo da Web .
  4. Preencha o formulário e clique em Criar . Os aplicativos que usam linguagens e estruturas como PHP, Java, Python, Ruby e .NET devem especificar URIs de redirecionamento autorizados. Os URIs de redirecionamento são os pontos de extremidade para os quais o servidor OAuth 2.0 pode enviar respostas. Esses endpoints devem aderir às regras de validação do Google .

    Para teste, você pode especificar URIs que se referem à máquina local, como http://localhost:8080 . Com isso em mente, observe que todos os exemplos neste documento usam http://localhost:8080 como URI de redirecionamento.

    Recomendamos que você projete os pontos de extremidade de autenticação de seu aplicativo para que seu aplicativo não exponha códigos de autorização a outros recursos na página.

Depois de criar as suas credenciais, baixe o arquivo client_secret.json do API Console. Armazene o arquivo com segurança em um local que somente seu aplicativo possa acessar.

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.

Também recomendamos que seu aplicativo solicite acesso aos escopos de autorização por meio de um processo de autorização incremental , no qual seu aplicativo solicita acesso aos dados do usuário no contexto. Essa prática recomendada ajuda os usuários a entender mais facilmente por que seu aplicativo precisa do acesso que está solicitando.

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

Requisitos específicos do idioma

Para executar qualquer um dos exemplos de código neste documento, você precisará de uma conta do Google, acesso à Internet e um navegador da web. Se você estiver usando uma das bibliotecas cliente da API, consulte também os requisitos específicos do idioma abaixo.

PHP

Para executar os exemplos de código PHP neste documento, você precisará:

  • PHP 5.4 ou superior com a interface de linha de comando (CLI) e extensão JSON instaladas.
  • A ferramenta de gerenciamento de dependências do Composer .
  • A biblioteca cliente de APIs do Google para PHP:

    php composer.phar require google/apiclient:^2.0

Pitão

Para executar os exemplos de código Python neste documento, você precisará:

  • Python 2.6 ou superior
  • A ferramenta de gerenciamento de pacotes pip .
  • A biblioteca cliente de APIs do Google para Python:
    pip install --upgrade google-api-python-client
  • O google-auth , google-auth-oauthlib e google-auth-httplib2 para autorização do usuário.
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • A estrutura de aplicativo da web Flask Python.
    pip install --upgrade flask
  • A biblioteca HTTP de requests .
    pip install --upgrade requests

Rubi

Para executar as amostras de código Ruby neste documento, você precisará:

  • Ruby 2.2.2 ou superior
  • A biblioteca cliente de APIs do Google para Ruby:

    gem install google-api-client
  • A estrutura da aplicação web Sinatra Ruby.

    gem install sinatra

HTTP / REST

Você não precisa instalar nenhuma biblioteca para poder chamar diretamente os pontos de extremidade OAuth 2.0.

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.

A lista abaixo resume rapidamente essas etapas:

  1. Seu aplicativo identifica as permissões de que precisa.
  2. Seu aplicativo redireciona o usuário ao Google junto com a lista de permissões solicitadas.
  3. O usuário decide se concederá as permissões ao seu aplicativo.
  4. Seu aplicativo descobre o que o usuário decidiu.
  5. Se o usuário concedeu as permissões solicitadas, seu aplicativo recupera os tokens necessários para fazer solicitações de API em nome do usuário.

Etapa 1: definir os parâmetros de autorização

Sua primeira etapa é criar a solicitação de autorização. Essa solicitação define parâmetros que identificam seu aplicativo e definem as permissões que o usuário deverá conceder ao seu aplicativo.

  • Se você usar uma biblioteca cliente do Google para autenticação e autorização OAuth 2.0, crie e configure um objeto que define esses parâmetros.
  • Se você chamar o ponto de extremidade Google OAuth 2.0 diretamente, você gerará um URL e definirá os parâmetros nesse URL.

As guias abaixo definem os parâmetros de autorização suportados para aplicativos de servidor da web. Os exemplos específicos de linguagem também mostram como usar uma biblioteca cliente ou biblioteca de autorização para configurar um objeto que define esses parâmetros.

PHP

O snippet de código abaixo cria um objeto Google_Client() , que define os parâmetros na solicitação de autorização.

Esse objeto usa informações de seu arquivo client_secret.json para identificar seu aplicativo. (Consulte como criar credenciais de autorização para obter mais informações sobre esse arquivo.) O objeto também identifica os escopos que seu aplicativo está solicitando permissão de acesso e o URL para o endpoint de autenticação do seu aplicativo, que tratará da resposta do servidor OAuth 2.0 do Google. Finalmente, o código define os parâmetros opcionais access_type e include_granted_scopes .

Por exemplo, este código solicita acesso somente leitura off-line ao Google Drive de um usuário:

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
// offline access will give you both an access and refresh token so that
// your app can refresh the access token without user interaction.
$client->setAccessType('offline');
// Using "consent" ensures that your application always receives a refresh token.
// If you are not using offline access, you can omit this.
$client->setApprovalPrompt("consent");
$client->setIncludeGrantedScopes(true);   // incremental auth

A solicitação especifica as seguintes informações:

Parâmetros
client_id Requerido

O ID do cliente para seu aplicativo. Você pode encontrar esse valor em API Console Credentials page.

Em PHP, chame a função setAuthConfig para carregar credenciais de autorização de um arquivo client_secret.json .

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
redirect_uri Requerido

Determina para onde o servidor de API redireciona o usuário depois que ele conclui o fluxo de autorização. O valor deve corresponder exatamente a um dos URIs de redirecionamento autorizados para o cliente OAuth 2.0, que você configurou no API Console Credentials page de seu cliente. Se este valor não corresponder a um URI de redirecionamento autorizado para o client_id fornecido, você receberá um erro redirect_uri_mismatch .

Observe que o esquema http ou https , maiúsculas e minúsculas e barra final (' / ') devem corresponder.

Para definir esse valor em PHP, chame a função setRedirectUri . Observe que você deve especificar um URI de redirecionamento válido para o client_id fornecido.

$client->setRedirectUri('https://oauth2.example.com/code');
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 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.

Para definir esse valor em PHP, chame a função addScope :

$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

Recomendamos que seu aplicativo solicite acesso aos escopos de autorização no contexto sempre que possível. Ao solicitar acesso aos dados do usuário no contexto, por meio de autorização incremental , você ajuda os usuários a entender mais facilmente por que seu aplicativo precisa do acesso que está solicitando.

access_type Recomendado

Indica se seu aplicativo pode atualizar tokens de acesso quando o usuário não está presente no navegador. Os valores de parâmetro válidos são online , que é o valor padrão, e offline .

Defina o valor como offline se seu aplicativo precisar atualizar tokens de acesso quando o usuário não estiver presente no navegador. Este é o método de atualização de tokens de acesso descrito posteriormente neste documento. Este valor instrui o servidor de autorização do Google a retornar um token de atualização e um token de acesso na primeira vez que seu aplicativo troca um código de autorização por tokens.

Para definir esse valor em PHP, chame a função setAccessType :

$client->setAccessType('offline');
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ê envia como um par name=value no componente de consulta de URL ( ? ) Do redirect_uri após o usuário consentir ou negar a solicitação 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. Como seu redirect_uri pode ser adivinhado, o uso de 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 foram originadas no mesmo navegador, fornecendo proteção contra ataques como cross-site pedido de falsificação. Consulte a documentação do OpenID Connect para obter um exemplo de como criar e confirmar um token de state .

Para definir esse valor em PHP, chame a função setState :

$client->setState($sample_passthrough_value);
include_granted_scopes Opcional

Permite que os aplicativos usem autorização incremental para solicitar acesso a escopos adicionais no contexto. Se você definir o valor desse parâmetro como true e a solicitação de autorização for concedida, o novo token de acesso também cobrirá todos os escopos aos quais o usuário concedeu acesso ao aplicativo anteriormente. Consulte a seção de autorização incremental para exemplos.

Para definir esse valor em PHP, chame a função setIncludeGrantedScopes :

$client->setIncludeGrantedScopes(true);
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 como um endereço de e-mail ou sub , que é equivalente ao ID do Google do usuário.

Para definir esse valor em PHP, chame a função setLoginHint :

$client->setLoginHint('None');
prompt Opcional

Uma lista delimitada por espaço e com distinção entre maiúsculas e minúsculas de prompts para apresentar ao usuário. Se você não especificar este parâmetro, o usuário será solicitado apenas na primeira vez que seu projeto solicitar acesso. Consulte Solicitando novo consentimento para obter mais informações.

Para definir esse valor em PHP, chame a função setApprovalPrompt :

$client->setApprovalPrompt('consent');

Os valores possíveis são:

none Não exiba nenhuma tela de autenticação ou consentimento. Não deve ser especificado com outros valores.
consent Solicite consentimento do usuário.
select_account Peça ao usuário para selecionar uma conta.

Pitão

O fragmento de código a seguir usa o módulo google-auth-oauthlib.flow para construir a solicitação de autorização.

O código constrói um objeto Flow , que identifica seu aplicativo usando informações do arquivo client_secret.json que você baixou após criar credenciais de autorização . Esse objeto também identifica os escopos para os quais seu aplicativo está solicitando permissão de acesso e o URL para o endpoint de autenticação de seu aplicativo, que tratará da resposta do servidor OAuth 2.0 do Google. Finalmente, o código define os parâmetros opcionais access_type e include_granted_scopes .

Por exemplo, este código solicita acesso somente leitura off-line ao Google Drive de um usuário:

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Use the client_secret.json file to identify the application requesting
# authorization. The client ID (from that file) and access scopes are required.
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

# Indicate where the API server will redirect the user after the user completes
# the authorization flow. The redirect URI is required. The value must exactly
# match one of the authorized redirect URIs for the OAuth 2.0 client, which you
# configured in the API Console. If this value doesn't match an authorized URI,
# you will get a 'redirect_uri_mismatch' error.
flow.redirect_uri = 'https://www.example.com/oauth2callback'

# Generate URL for request to Google's OAuth 2.0 server.
# Use kwargs to set optional request parameters.
authorization_url, state = flow.authorization_url(
    # Enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true')

A solicitação especifica as seguintes informações:

Parâmetros
client_id Requerido

O ID do cliente para seu aplicativo. Você pode encontrar esse valor em API Console Credentials page.

Em Python, chame o método from_client_secrets_file para recuperar o ID do cliente de um arquivo client_secret.json . (Você também pode usar o método from_client_config , que passa a configuração do cliente como apareceu originalmente em um arquivo de segredos do cliente, mas não acessa o próprio arquivo.)

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])
redirect_uri Requerido

Determina para onde o servidor de API redireciona o usuário depois que ele conclui o fluxo de autorização. O valor deve corresponder exatamente a um dos URIs de redirecionamento autorizados para o cliente OAuth 2.0, que você configurou no API Console Credentials page do seu cliente. Se este valor não corresponder a um URI de redirecionamento autorizado para o client_id fornecido, você receberá um erro redirect_uri_mismatch .

Observe que o esquema http ou https , maiúsculas e minúsculas e barra final (' / ') devem corresponder.

Para definir esse valor em Python, defina a propriedade redirect_uri do objeto de flow :

flow.redirect_uri = 'https://oauth2.example.com/code'
scope Requerido

Uma lista de escopos 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.

Em Python, use o mesmo método usado para definir o client_id para especificar a lista de escopos.

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

Recomendamos que seu aplicativo solicite acesso aos escopos de autorização no contexto sempre que possível. Ao solicitar acesso aos dados do usuário no contexto, por meio de autorização incremental , você ajuda os usuários a entender mais facilmente por que seu aplicativo precisa do acesso que está solicitando.

access_type Recomendado

Indica se seu aplicativo pode atualizar tokens de acesso quando o usuário não está presente no navegador. Os valores de parâmetro válidos são online , que é o valor padrão, e offline .

Defina o valor como offline se seu aplicativo precisar atualizar tokens de acesso quando o usuário não estiver presente no navegador. Este é o método de atualização de tokens de acesso descrito posteriormente neste documento. Este valor instrui o servidor de autorização do Google a retornar um token de atualização e um token de acesso na primeira vez que seu aplicativo troca um código de autorização por tokens.

Em Python, defina o parâmetro access_type especificando access_type como um argumento de palavra-chave ao chamar o método flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
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ê envia como um par name=value no componente de consulta 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á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. Como seu redirect_uri pode ser adivinhado, o uso de 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 foram originadas no mesmo navegador, fornecendo proteção contra ataques como cross-site pedido de falsificação. Consulte a documentação do OpenID Connect para obter um exemplo de como criar e confirmar um token de state .

Em Python, definir o state parâmetro especificando state como um argumento de palavra-chave ao chamar o flow.authorization_url método:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    state=sample_passthrough_value,
    include_granted_scopes='true')
include_granted_scopes Opcional

Permite que os aplicativos usem autorização incremental para solicitar acesso a escopos adicionais no contexto. Se você definir o valor desse parâmetro como true e a solicitação de autorização for concedida, o novo token de acesso também cobrirá todos os escopos aos quais o usuário concedeu acesso ao aplicativo anteriormente. Consulte a seção de autorização incremental para exemplos.

Em Python, defina o parâmetro include_granted_scopes especificando include_granted_scopes como um argumento de palavra-chave ao chamar o método flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
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 como um endereço de e-mail ou sub , que é equivalente ao ID do Google do usuário.

Em Python, defina o parâmetro login_hint especificando login_hint como um argumento de palavra-chave ao chamar o método flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    login_hint='None',
    include_granted_scopes='true')
prompt Opcional

Uma lista delimitada por espaço e com distinção entre maiúsculas e minúsculas de prompts para apresentar ao usuário. Se você não especificar este parâmetro, o usuário será solicitado apenas na primeira vez que seu projeto solicitar acesso. Consulte Solicitando novo consentimento para obter mais informações.

Em Python, defina o parâmetro prompt especificando prompt como um argumento de palavra-chave ao chamar o método flow.authorization_url :

authorization_url, state = flow.authorization_url(
      access_type='offline',
      prompt='consent',
      include_granted_scopes='true')

Os valores possíveis são:

none Não exiba nenhuma tela de autenticação ou consentimento. Não deve ser especificado com outros valores.
consent Solicite consentimento do usuário.
select_account Peça ao usuário para selecionar uma conta.

Rubi

Use o arquivo client_secrets.json que você criou para configurar um objeto cliente em seu aplicativo. Ao configurar um objeto cliente, você especifica os escopos que seu aplicativo precisa acessar, junto com a URL para o endpoint de autenticação de seu aplicativo, que tratará da resposta do servidor OAuth 2.0.

Por exemplo, este código solicita acesso somente leitura off-line ao Google Drive de um usuário:

require 'google/apis/drive_v2'
require 'google/api_client/client_secrets'

client_secrets = Google::APIClient::ClientSecrets.load
auth_client = client_secrets.to_authorization
auth_client.update!(
  :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
  :redirect_uri => 'http://www.example.com/oauth2callback',
  :additional_parameters => {
    "access_type" => "offline",         # offline access
    "include_granted_scopes" => "true"  # incremental auth
  }
)

Seu aplicativo usa o objeto cliente para realizar operações OAuth 2.0, como gerar URLs de solicitação de autorização e aplicar tokens de acesso a solicitações HTTP.

HTTP / REST

O ponto de extremidade OAuth 2.0 do Google está em https://accounts.google.com/o/oauth2/v2/auth . Este endpoint é acessível apenas por HTTPS. Conexões HTTP simples são recusadas.

O servidor de autorização do Google oferece suporte aos seguintes parâmetros de string de consulta para aplicativos de servidor da web:

Parâmetros
client_id Requerido

O ID do cliente para seu aplicativo. Você pode encontrar esse valor em API Console Credentials page.

redirect_uri Requerido

Determina para onde o servidor de API redireciona o usuário depois que ele conclui o fluxo de autorização. O valor deve corresponder exatamente a um dos URIs de redirecionamento autorizados para o cliente OAuth 2.0, que você configurou no API Console Credentials page do seu cliente. Se este valor não corresponder a um URI de redirecionamento autorizado para o client_id fornecido, você receberá um erro redirect_uri_mismatch .

Observe que o esquema http ou https , maiúsculas e minúsculas e barra final (' / ') devem corresponder.

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 de servidor da web.

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

Recomendamos que seu aplicativo solicite acesso aos escopos de autorização no contexto sempre que possível. Ao solicitar acesso aos dados do usuário no contexto, por meio de autorização incremental , você ajuda os usuários a entender mais facilmente por que seu aplicativo precisa do acesso que está solicitando.

access_type Recomendado

Indica se seu aplicativo pode atualizar tokens de acesso quando o usuário não está presente no navegador. Os valores de parâmetro válidos são online , que é o valor padrão, e offline .

Defina o valor como offline se seu aplicativo precisar atualizar tokens de acesso quando o usuário não estiver presente no navegador. Este é o método de atualização de tokens de acesso descrito posteriormente neste documento. Este valor instrui o servidor de autorização do Google a retornar um token de atualização e um token de acesso na primeira vez que seu aplicativo troca um código de autorização por tokens.

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ê envia como um par name=value no componente de consulta 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á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. Como seu redirect_uri pode ser adivinhado, o uso de 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 foram originadas no mesmo navegador, fornecendo proteção contra ataques como cross-site pedido de falsificação. Consulte a documentação do OpenID Connect para obter um exemplo de como criar e confirmar um token de state .

include_granted_scopes Opcional

Permite que os aplicativos usem autorização incremental para solicitar acesso a escopos adicionais no contexto. Se você definir o valor desse parâmetro como true e a solicitação de autorização for concedida, o novo token de acesso também cobrirá todos os escopos aos quais o usuário concedeu acesso ao aplicativo anteriormente. Consulte a seção de autorização incremental para exemplos.

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 como um endereço de e-mail ou sub , que é equivalente ao ID do Google do usuário.

prompt Opcional

Uma lista delimitada por espaço e com distinção entre maiúsculas e minúsculas de prompts para apresentar ao usuário. Se você não especificar este parâmetro, o usuário será solicitado apenas na primeira vez que seu projeto solicitar acesso. Consulte Solicitando novo consentimento para obter mais informações.

Os valores possíveis são:

none Não exiba nenhuma tela de autenticação ou consentimento. Não deve ser especificado com outros valores.
consent Solicite consentimento do usuário.
select_account Peça ao usuário para selecionar uma conta.

Etapa 2: Redirecionar para o servidor OAuth 2.0 do Google

Redirecione o usuário para o servidor OAuth 2.0 do Google para iniciar o processo de autenticação e autorização. Normalmente, isso ocorre quando seu aplicativo precisa primeiro acessar os dados do usuário. No caso de autorização incremental , esta etapa também ocorre quando seu aplicativo primeiro precisa acessar recursos adicionais que ainda não tem permissão para acessar.

PHP

  1. Gere um URL para solicitar acesso do servidor OAuth 2.0 do Google:
    $auth_url = $client->createAuthUrl();
  2. Redirecione o usuário para $auth_url :
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

Pitão

Este exemplo mostra como redirecionar o usuário para o URL de autorização usando a estrutura de aplicativo da web Flask:

return flask.redirect(authorization_url)

Rubi

  1. Gere um URL para solicitar acesso do servidor OAuth 2.0 do Google:
    auth_uri = auth_client.authorization_uri.to_s
  2. Redirecione o usuário para auth_uri .

HTTP / REST

Amostra de redirecionamento para o servidor de autorização do Google

Um exemplo de URL é mostrado abaixo, com quebras de linha e espaços para facilitar a leitura.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Depois de criar o URL de solicitação, redirecione o usuário para ele.

O servidor OAuth 2.0 do Google autentica o usuário e obtém o consentimento do usuário para que seu aplicativo acesse os escopos solicitados. A resposta é enviada de volta ao seu aplicativo usando o URL de redirecionamento que você especificou.

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

Etapa 4: lidar com a resposta do servidor OAuth 2.0

O servidor OAuth 2.0 responde à solicitação de acesso do seu aplicativo usando o URL especificado na solicitação.

Se o usuário aprovar a solicitação de acesso, a resposta conterá um código de autorização. Se o usuário não aprovar a solicitação, a resposta conterá uma mensagem de erro. O código de autorização ou mensagem de erro que é retornado ao servidor da web aparece na string de consulta, conforme mostrado abaixo:

Uma resposta de erro:

https://oauth2.example.com/auth?error=access_denied

Uma resposta de código de autorização:

https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

Amostra de resposta do servidor OAuth 2.0

Você pode testar esse fluxo clicando no seguinte URL de amostra, que solicita acesso somente leitura para visualizar metadados de arquivos em seu Google Drive:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Depois de concluir o fluxo do OAuth 2.0, você deve ser redirecionado para http://localhost/oauth2callback , o que provavelmente produzirá um erro 404 NOT FOUND a menos que sua máquina local http://localhost/oauth2callback um arquivo nesse endereço. A próxima etapa fornece mais detalhes sobre as informações retornadas no URI quando o usuário é redirecionado de volta ao seu aplicativo.

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

Depois que o servidor da web recebe o código de autorização, ele pode trocar o código de autorização por um token de acesso.

PHP

Para trocar um código de autorização por um token de acesso, use o método de authenticate :

$client->authenticate($_GET['code']);

Você pode recuperar o token de acesso com o método getAccessToken :

$access_token = $client->getAccessToken();

Pitão

Em sua página de retorno de chamada, use a biblioteca google-auth para verificar a resposta do servidor de autorização. Em seguida, use o método flow.fetch_token para trocar o código de autorização nessa resposta por um token de acesso:

state = flask.session['state']
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'],
    state=state)
flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

authorization_response = flask.request.url
flow.fetch_token(authorization_response=authorization_response)

# Store the credentials in the session.
# ACTION ITEM for developers:
#     Store user's access and refresh tokens in your data store if
#     incorporating this code into your real app.
credentials = flow.credentials
flask.session['credentials'] = {
    'token': credentials.token,
    'refresh_token': credentials.refresh_token,
    'token_uri': credentials.token_uri,
    'client_id': credentials.client_id,
    'client_secret': credentials.client_secret,
    'scopes': credentials.scopes}

Rubi

Para trocar um código de autorização por um token de acesso, use o fetch_access_token! método:

auth_client.code = auth_code
auth_client.fetch_access_token!

HTTP / REST

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

Campos
client_id O ID do cliente obtido em API Console Credentials page.
client_secret O segredo do cliente obtido em API Console Credentials page.
code O código de autorização retornado da solicitação inicial.
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 em API Console Credentials page para o client_id fornecido.

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=https%3A//oauth2.example.com/code&
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. Observe que o token de atualização só é retornado se seu aplicativo definir o parâmetro access_type como offline na solicitação inicial para o servidor de autorização do Google .

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.
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. Novamente, este campo só estará presente nesta resposta se você definir o parâmetro access_type como offline na solicitação inicial para o servidor de autorização do Google.
scope Os escopos de acesso concedido pelo access_token expressos como uma lista de strings delimitadas por espaço e com distinção entre maiúsculas e minúsculas.
token_type O tipo de token retornado. Neste momento, o valor deste campo é sempre definido como Bearer .

The following snippet shows a sample response:

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

Calling Google APIs

PHP

Use the access token to call Google APIs by completing the following steps:

  1. If you need to apply an access token to a new Google_Client object—for example, if you stored the access token in a user session—use the setAccessToken method:
    $client->setAccessToken($access_token);
  2. Build a service object for the API that you want to call. You build a service object by providing an authorized Google_Client object to the constructor for the API you want to call. For example, to call the Drive API:
    $drive = new Google_Service_Drive($client);
  3. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    $files = $drive->files->listFiles(array())->getItems();

Python

After obtaining an access token, your application can use that token to authorize API requests on behalf of a given user account or service account. Use the user-specific authorization credentials to build a service object for the API that you want to call, and then use that object to make authorized API requests.

  1. Build a service object for the API that you want to call. You build a service object by calling the googleapiclient.discovery library's build method with the name and version of the API and the user credentials: For example, to call version 2 of the Drive API:
    from googleapiclient.discovery import build
    
    drive = build('drive', 'v2', credentials=credentials)
  2. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    files = drive.files().list().execute()

Ruby

Use the auth_client object to call Google APIs by completing the following steps:

  1. Build a service object for the API that you want to call. For example, to call version 2 of the Drive API:
    drive = Google::Apis::DriveV2::DriveService.new
  2. Set the credentials on the service:
    drive.authorization = auth_client
  3. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    files = drive.list_files

Alternately, authorization can be provided on a per-method basis by supplying the options parameter to a method:

files = drive.list_files(options: { authorization: auth_client })

HTTP/REST

After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account if the scope(s) of access required by the API have been granted. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization HTTP header Bearer value. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive Files API ).

You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground .

HTTP GET examples

A call to the drive.files endpoint (the Drive Files API) using the Authorization: Bearer HTTP header might look like the following. Note that you need to specify your own access token:

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

Here is a call to the same API for the authenticated user using the access_token query string parameter:

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

curl examples

You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred):

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

Or, alternatively, the query string parameter option:

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

Complete example

The following example prints a JSON-formatted list of files in a user's Google Drive after the user authenticates and gives consent for the application to access the user's Drive metadata.

PHP

To run this example:

  1. In the API Console, add the URL of the local machine to the list of redirect URLs. For example, add http://localhost:8080 .
  2. Create a new directory and change to it. For example:
    mkdir ~/php-oauth2-example
    cd ~/php-oauth2-example
  3. Install the Google API Client Library for PHP using Composer :
    composer require google/apiclient:^2.0
  4. Create the files index.php and oauth2callback.php with the content below.
  5. Run the example with a web server configured to serve PHP. If you use PHP 5.4 or newer, you can use PHP's built-in test web server:
    php -S localhost:8080 ~/php-oauth2-example

index.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google_Client();
$client->setAuthConfig('client_secrets.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

if (isset($_SESSION['access_token']) && $_SESSION['access_token']) {
  $client->setAccessToken($_SESSION['access_token']);
  $drive = new Google_Service_Drive($client);
  $files = $drive->files->listFiles(array())->getItems();
  echo json_encode($files);
} else {
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

oauth2callback.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google_Client();
$client->setAuthConfigFile('client_secrets.json');
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

if (! isset($_GET['code'])) {
  $auth_url = $client->createAuthUrl();
  header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
} else {
  $client->authenticate($_GET['code']);
  $_SESSION['access_token'] = $client->getAccessToken();
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

Python

This example uses the Flask framework. It runs a web application at http://localhost:8080 that lets you test the OAuth 2.0 flow. If you go to that URL, you should see four links:

  • Test an API request: This link points to a page that tries to execute a sample API request. If necessary, it starts the authorization flow. If successful, the page displays the API response.
  • Test the auth flow directly: This link points to a page that tries to send the user through the authorization flow . The app requests permission to submit authorized API requests on the user's behalf.
  • Revoke current credentials: This link points to a page that revokes permissions that the user has already granted to the application.
  • Clear Flask session credentials: This link clears authorization credentials that are stored in the Flask session. This lets you see what would happen if a user who had already granted permission to your app tried to execute an API request in a new session. It also lets you see the API response your app would get if a user had revoked permissions granted to your app, and your app still tried to authorize a request with a revoked access token.
# -*- coding: utf-8 -*-

import os
import flask
import requests

import google.oauth2.credentials
import google_auth_oauthlib.flow
import googleapiclient.discovery

# This variable specifies the name of a file that contains the OAuth 2.0
# information for this application, including its client_id and client_secret.
CLIENT_SECRETS_FILE = "client_secret.json"

# This OAuth 2.0 access scope allows for full read/write access to the
# authenticated user's account and requires requests to use an SSL connection.
SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly']
API_SERVICE_NAME = 'drive'
API_VERSION = 'v2'

app = flask.Flask(__name__)
# Note: A secret key is included in the sample so that it works.
# If you use this code in your application, replace this with a truly secret
# key. See https://flask.palletsprojects.com/quickstart/#sessions.
app.secret_key = 'REPLACE ME - this value is here as a placeholder.'


@app.route('/')
def index():
  return print_index_table()


@app.route('/test')
def test_api_request():
  if 'credentials' not in flask.session:
    return flask.redirect('authorize')

  # Load credentials from the session.
  credentials = google.oauth2.credentials.Credentials(
      **flask.session['credentials'])

  drive = googleapiclient.discovery.build(
      API_SERVICE_NAME, API_VERSION, credentials=credentials)

  files = drive.files().list().execute()

  # Save credentials back to session in case access token was refreshed.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.jsonify(**files)


@app.route('/authorize')
def authorize():
  # Create flow instance to manage the OAuth 2.0 Authorization Grant Flow steps.
  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES)

  # The URI created here must exactly match one of the authorized redirect URIs
  # for the OAuth 2.0 client, which you configured in the API Console. If this
  # value doesn't match an authorized URI, you will get a 'redirect_uri_mismatch'
  # error.
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  authorization_url, state = flow.authorization_url(
      # Enable offline access so that you can refresh an access token without
      # re-prompting the user for permission. Recommended for web server apps.
      access_type='offline',
      # Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes='true')

  # Store the state so the callback can verify the auth server response.
  flask.session['state'] = state

  return flask.redirect(authorization_url)


@app.route('/oauth2callback')
def oauth2callback():
  # Specify the state when creating the flow in the callback so that it can
  # verified in the authorization server response.
  state = flask.session['state']

  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES, state=state)
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  # Use the authorization server's response to fetch the OAuth 2.0 tokens.
  authorization_response = flask.request.url
  flow.fetch_token(authorization_response=authorization_response)

  # Store credentials in the session.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  credentials = flow.credentials
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.redirect(flask.url_for('test_api_request'))


@app.route('/revoke')
def revoke():
  if 'credentials' not in flask.session:
    return ('You need to <a href="/authorize">authorize</a> before ' +
            'testing the code to revoke credentials.')

  credentials = google.oauth2.credentials.Credentials(
    **flask.session['credentials'])

  revoke = requests.post('https://oauth2.googleapis.com/revoke',
      params={'token': credentials.token},
      headers = {'content-type': 'application/x-www-form-urlencoded'})

  status_code = getattr(revoke, 'status_code')
  if status_code == 200:
    return('Credentials successfully revoked.' + print_index_table())
  else:
    return('An error occurred.' + print_index_table())


@app.route('/clear')
def clear_credentials():
  if 'credentials' in flask.session:
    del flask.session['credentials']
  return ('Credentials have been cleared.<br><br>' +
          print_index_table())


def credentials_to_dict(credentials):
  return {'token': credentials.token,
          'refresh_token': credentials.refresh_token,
          'token_uri': credentials.token_uri,
          'client_id': credentials.client_id,
          'client_secret': credentials.client_secret,
          'scopes': credentials.scopes}

def print_index_table():
  return ('<table>' +
          '<tr><td><a href="/test">Test an API request</a></td>' +
          '<td>Submit an API request and see a formatted JSON response. ' +
          '    Go through the authorization flow if there are no stored ' +
          '    credentials for the user.</td></tr>' +
          '<tr><td><a href="/authorize">Test the auth flow directly</a></td>' +
          '<td>Go directly to the authorization flow. If there are stored ' +
          '    credentials, you still might not be prompted to reauthorize ' +
          '    the application.</td></tr>' +
          '<tr><td><a href="/revoke">Revoke current credentials</a></td>' +
          '<td>Revoke the access token associated with the current user ' +
          '    session. After revoking credentials, if you go to the test ' +
          '    page, you should see an <code>invalid_grant</code> error.' +
          '</td></tr>' +
          '<tr><td><a href="/clear">Clear Flask session credentials</a></td>' +
          '<td>Clear the access token currently stored in the user session. ' +
          '    After clearing the token, if you <a href="/test">test the ' +
          '    API request</a> again, you should go back to the auth flow.' +
          '</td></tr></table>')


if __name__ == '__main__':
  # When running locally, disable OAuthlib's HTTPs verification.
  # ACTION ITEM for developers:
  #     When running in production *do not* leave this option enabled.
  os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1'

  # Specify a hostname and port that are set as a valid redirect URI
  # for your API project in the Google API Console.
  app.run('localhost', 8080, debug=True)

Ruby

This example uses the Sinatra framework.

require 'google/apis/drive_v2'
require 'google/api_client/client_secrets'
require 'json'
require 'sinatra'

enable :sessions
set :session_secret, 'setme'

get '/' do
  unless session.has_key?(:credentials)
    redirect to('/oauth2callback')
  end
  client_opts = JSON.parse(session[:credentials])
  auth_client = Signet::OAuth2::Client.new(client_opts)
  drive = Google::Apis::DriveV2::DriveService.new
  files = drive.list_files(options: { authorization: auth_client })
  "<pre>#{JSON.pretty_generate(files.to_h)}</pre>"
end

get '/oauth2callback' do
  client_secrets = Google::APIClient::ClientSecrets.load
  auth_client = client_secrets.to_authorization
  auth_client.update!(
    :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
    :redirect_uri => url('/oauth2callback'))
  if request['code'] == nil
    auth_uri = auth_client.authorization_uri.to_s
    redirect to(auth_uri)
  else
    auth_client.code = request['code']
    auth_client.fetch_access_token!
    auth_client.client_secret = nil
    session[:credentials] = auth_client.to_json
    redirect to('/')
  end
end

HTTP/REST

This Python example uses the Flask framework and the Requests library to demonstrate the OAuth 2.0 web flow. We recommend using the Google API Client Library for Python for this flow. (The example in the Python tab does use the client library.)

import json

import flask
import requests


app = flask.Flask(__name__)

CLIENT_ID = '123456789.apps.googleusercontent.com'
CLIENT_SECRET = 'abc123'  # Read from a file or environmental variable in a real app
SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly'
REDIRECT_URI = 'http://example.com/oauth2callback'


@app.route('/')
def index():
  if 'credentials' not in flask.session:
    return flask.redirect(flask.url_for('oauth2callback'))
  credentials = json.loads(flask.session['credentials'])
  if credentials['expires_in'] <= 0:
    return flask.redirect(flask.url_for('oauth2callback'))
  else:
    headers = {'Authorization': 'Bearer {}'.format(credentials['access_token'])}
    req_uri = 'https://www.googleapis.com/drive/v2/files'
    r = requests.get(req_uri, headers=headers)
    return r.text


@app.route('/oauth2callback')
def oauth2callback():
  if 'code' not in flask.request.args:
    auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code'
                '&client_id={}&redirect_uri={}&scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE)
    return flask.redirect(auth_uri)
  else:
    auth_code = flask.request.args.get('code')
    data = {'code': auth_code,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET,
            'redirect_uri': REDIRECT_URI,
            'grant_type': 'authorization_code'}
    r = requests.post('https://oauth2.googleapis.com/token', data=data)
    flask.session['credentials'] = r.text
    return flask.redirect(flask.url_for('index'))


if __name__ == '__main__':
  import uuid
  app.secret_key = str(uuid.uuid4())
  app.debug = False
  app.run()

Redirect URI validation rules

Google applies the following validation rules to redirect URIs in order to help developers keep their applications secure. Your redirect URIs must adhere to these rules. See RFC 3986 section 3 for the definition of domain, host, path, query, scheme and userinfo, mentioned below.

Validation rules
Scheme

URIs must use the HTTPS scheme, not plain HTTP.

Host

Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule.

Domain
  • Host TLDs ( Top Level Domains ) must belong to the public suffix list .
  • Host domains cannot be “googleusercontent.com” .
  • URIs cannot contain URL shortener domains (eg goo.gl ) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback” .
  • Userinfo

    Redirect URIs cannot contain the userinfo subcomponent.

    Path

    Redirect URIs cannot contain a path traversal (also called directory backtracking), which is represented by an “/..” or “\..” or their URL encoding.

    Query

    Redirect URIs cannot contain open redirects .

    Characters URIs cannot contain certain characters including:
    • Wildcard characters ( '*' )
    • Non-printable ASCII characters
    • Invalid percent encodings (any percent encoding that does not follow URL-encoding form of a percent sign followed by two hexadecimal digits)
    • Null characters (an encoded NULL character, eg, %00 , %C0%80 )

    Incremental authorization

    In the OAuth 2.0 protocol, your app requests authorization to access resources, which are identified by scopes. It is considered a best user-experience practice to request authorization for resources at the time you need them. To enable that practice, Google's authorization server supports incremental authorization. This feature lets you request scopes as they are needed and, if the user grants permission for the new scope, returns an authorization code that may be exchanged for a token containing all scopes the user has granted the project.

    For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it.

    In this case, at sign-in time the app might request the openid and profile scopes to perform basic sign-in, and then later request the https://www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix.

    To implement incremental authorization, you complete the normal flow for requesting an access token but make sure that the authorization request includes previously granted scopes. This approach allows your app to avoid having to manage multiple access tokens.

    The following rules apply to an access token obtained from an incremental authorization:

    • The token can be used to access resources corresponding to any of the scopes rolled into the new, combined authorization.
    • When you use the refresh token for the combined authorization to obtain an access token, the access token represents the combined authorization and can be used for any of the scope values included in the response.
    • The combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one scope using an application's desktop client and then granted another scope to the same application via a mobile client, the combined authorization would include both scopes.
    • If you revoke a token that represents a combined authorization, access to all of that authorization's scopes on behalf of the associated user are revoked simultaneously.

    The language-specific code samples in Step 1: Set authorization parameters and the sample HTTP/REST redirect URL in Step 2: Redirect to Google's OAuth 2.0 server all use incremental authorization. The code samples below also show the code that you need to add to use incremental authorization.

    PHP

    $client->setIncludeGrantedScopes(true);

    Python

    In Python, set the include_granted_scopes keyword argument to true to ensure that an authorization request includes previously granted scopes. It is very possible that include_granted_scopes will not be the only keyword argument that you set, as shown in the example below.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    Ruby

    auth_client.update!(
      :additional_parameters => {"include_granted_scopes" => "true"}
    )

    HTTP/REST

    GET https://accounts.google.com/o/oauth2/v2/auth?
      client_id=your_client_id&
      response_type=code&
      state=state_parameter_passthrough_value&
      scope=https%3A//www.googleapis.com/auth/drive.file&
      redirect_uri=https%3A//oauth2.example.com/code&
      prompt=consent&
      include_granted_scopes=true

    Refreshing an access token (offline access)

    Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.

    • If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
    • If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the user to Google's OAuth 2.0 server . In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.

    Requesting offline access is a requirement for any application that needs to access a Google API when the user is not present. For example, an app that performs backup services or executes actions at predetermined times needs to be able to refresh its access token when the user is not present. The default style of access is called online .

    Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.

    PHP

    If your application needs offline access to a Google API, set the API client's access type to offline :

    $client->setAccessType("offline");

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    Python

    In Python, set the access_type keyword argument to offline to ensure that you will be able to refresh the access token without having to re-prompt the user for permission. It is very possible that access_type will not be the only keyword argument that you set, as shown in the example below.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    Ruby

    If your application needs offline access to a Google API, set the API client's access type to offline :

    auth_client.update!(
      :additional_parameters => {"access_type" => "offline"}
    )

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    HTTP/REST

    To refresh an access token, your application sends an HTTPS POST request to Google's authorization server ( https://oauth2.googleapis.com/token ) that includes the following parameters:

    Fields
    client_id The client ID obtained from the API Console.
    client_secret The client secret obtained from the API Console.
    grant_type As defined in the OAuth 2.0 specification , this field's value must be set to refresh_token .
    refresh_token The refresh token returned from the authorization code exchange.

    The following snippet shows a sample request:

    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

    As long as the user has not revoked the access granted to the application, the token server returns a JSON object that contains a new access token. The following snippet shows a sample response:

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

    Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

    Revoking a token

    In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings . See the Remove site or app access section of the Third-party sites & apps with access to your account support document for more information.

    It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes, removes an application, or the API resources required by an app have significantly changed. In other words, part of the removal process can include an API request to ensure the permissions previously granted to the application are removed.

    PHP

    To programmatically revoke a token, call revokeToken() :

    $client->revokeToken();

    Python

    To programmatically revoke a token, make a request to https://oauth2.googleapis.com/revoke that includes the token as a parameter and sets the Content-Type header:

    requests.post('https://oauth2.googleapis.com/revoke',
        params={'token': credentials.token},
        headers = {'content-type': 'application/x-www-form-urlencoded'})

    Ruby

    To programmatically revoke a token, make an HTTP request to the oauth2.revoke endpoint:

    uri = URI('https://oauth2.googleapis.com/revoke')
    response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
    

    The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

    If the revocation is successfully processed, then the status code of the response is 200 . For error conditions, a status code 400 is returned along with an error code.

    HTTP/REST

    To programmatically revoke a token, your application makes a request to https://oauth2.googleapis.com/revoke and includes the token as a parameter:

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

    The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

    If the revocation is successfully processed, then the HTTP status code of the response is 200 . For error conditions, an HTTP status code 400 is returned along with an error code.