Utilizzo di OAuth 2.0 per applicazioni server Web

Questo documento spiega come le applicazioni del server web utilizzano le librerie client API di Google o gli endpoint OAuth 2.0 di Google per implementare l'autorizzazione OAuth 2.0 per accedere alle API di Google.

OAuth 2.0 consente agli utenti di condividere dati specifici con un'applicazione mantenendo privati ​​nomi utente, password e altre informazioni. Ad esempio, un'applicazione può utilizzare OAuth 2.0 per ottenere l'autorizzazione dagli utenti per archiviare file nei propri Google Drive.

Questo flusso OAuth 2.0 è specifico per l'autorizzazione dell'utente. È progettato per applicazioni in grado di memorizzare informazioni riservate e mantenere lo stato. Un'applicazione server Web adeguatamente autorizzata può accedere a un'API mentre l'utente interagisce con l'applicazione o dopo che l'utente ha lasciato l'applicazione.

Applicazioni server Web spesso usano anche gli account di servizio di autorizzare le richieste API, soprattutto quando si chiama cloud API per accedere ai dati basate su progetti, piuttosto che dati utente-specifici. Le applicazioni del server Web possono utilizzare account di servizio insieme all'autorizzazione dell'utente.

Librerie clienti

Gli esempi di linguaggio specifici in questa pagina l'uso di Google API di librerie client per implementare OAuth autorizzazione 2.0. Per eseguire gli esempi di codice, devi prima installare la libreria client per la tua lingua.

Quando utilizzi una libreria client API di Google per gestire il flusso OAuth 2.0 della tua applicazione, la libreria client esegue molte azioni che altrimenti l'applicazione dovrebbe gestire da sola. Ad esempio, determina quando l'applicazione può utilizzare o aggiornare i token di accesso archiviati e quando l'applicazione deve riacquisire il consenso. La libreria client genera anche URL di reindirizzamento corretti e aiuta a implementare gestori di reindirizzamento che scambiano codici di autorizzazione per token di accesso.

Le librerie client sono disponibili per le seguenti lingue:

Prerequisiti

Abilita le API per il tuo progetto

Qualsiasi applicazione che chiama Google API deve consentire a tali API nel API Console.

Per abilitare un'API per il tuo progetto:

  1. Open the API Library nel Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Il API Library elenca tutti API disponibili, raggruppate per famiglia di prodotti e la popolarità. Se l'API si desidera attivare non è visibile nella lista, l'uso di ricerca per trovarlo, oppure fare clic su Visualizza tutto nella famiglia di prodotti cui appartiene.
  4. Selezionare l'API che si desidera attivare, quindi fare clic sul pulsante Attiva.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Crea credenziali di autorizzazione

Qualsiasi applicazione che utilizza OAuth 2.0 per accedere alle API di Google deve disporre di credenziali di autorizzazione che identifichino l'applicazione al server OAuth 2.0 di Google. I passaggi seguenti spiegano come creare le credenziali per il progetto. Le tue applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai abilitato per quel progetto.

  1. Go to the Credentials page.
  2. Fare clic su Crea credenziali> OAuth ID cliente.
  3. Selezionare il tipo di applicazione applicazione Web.
  4. Compila il modulo e fare clic su Crea. Le applicazioni che utilizzano linguaggi e framework come PHP, Java, Python, Ruby, e .NET necessario specificare gli URI reindirizzamento autorizzati. Gli URI di reindirizzamento sono gli endpoint a cui il server OAuth 2.0 può inviare risposte. Questi punti finali devono rispettare le regole di convalida di Google .

    Per il test, è possibile specificare URI che si riferiscono alla macchina locale, come ad esempio http://localhost:8080 . Con questo in mente, si ricorda che tutti gli esempi illustrati in questo documento, http://localhost:8080 come il reindirizzamento URI.

    Si consiglia di progettare gli endpoint auth del vostro app in modo che l'applicazione non espone i codici di autorizzazione ad altre risorse sulla pagina.

Dopo aver creato le credenziali, scaricare il file client_secret.json dal API Console. Archivia in modo sicuro il file in una posizione a cui solo la tua applicazione può accedere.

Identificare gli ambiti di accesso

Gli ambiti consentono alla tua applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, consentendo anche agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Pertanto, potrebbe esistere una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

Prima di iniziare a implementare l'autorizzazione OAuth 2.0, ti consigliamo di identificare gli ambiti a cui la tua app avrà bisogno dell'autorizzazione per accedere.

Si consiglia inoltre l'applicazione richiesta di accesso ad autorizzazione ambiti attraverso un 'autorizzazione incrementale processo, in cui l'applicazione richiede l'accesso ai dati degli utenti nel contesto. Questa procedura consigliata consente agli utenti di comprendere più facilmente perché l'applicazione necessita dell'accesso che richiede.

Il 2.0 API OAuth Scopes documento contiene una lista completa di ambiti che si potrebbe utilizzare per accedere a Google API.

Requisiti specifici della lingua

Per eseguire uno degli esempi di codice in questo documento, avrai bisogno di un account Google, accesso a Internet e un browser web. Se stai utilizzando una delle librerie client API, consulta anche i requisiti specifici della lingua di seguito.

PHP

Per eseguire gli esempi di codice PHP in questo documento, avrai bisogno di:

  • PHP 5.4 o versione successiva con l'interfaccia della riga di comando (CLI) e l'estensione JSON installate.
  • Il compositore strumento di gestione delle dipendenze.
  • La libreria client delle API di Google per PHP:

    php composer.phar require google/apiclient:^2.0

Pitone

Per eseguire gli esempi di codice Python in questo documento, avrai bisogno di:

  • Python 2.6 o successivo
  • Il pip strumento di gestione dei pacchetti.
  • La libreria client di Google API per Python:
    pip install --upgrade google-api-python-client
  • La google-auth , google-auth-oauthlib , e google-auth-httplib2 per l'autorizzazione dell'utente.
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • Il framework dell'applicazione Web Flask Python.
    pip install --upgrade flask
  • La requests libreria HTTP.
    pip install --upgrade requests

Rubino

Per eseguire gli esempi di codice Ruby in questo documento, avrai bisogno di:

  • Rubino 2.2.2 o superiore
  • La libreria client delle API di Google per Ruby:

    gem install google-api-client
  • Il framework dell'applicazione web Sinatra Ruby.

    gem install sinatra

HTTP/REST

Non è necessario installare alcuna libreria per poter chiamare direttamente gli endpoint OAuth 2.0.

Ottenere i token di accesso OAuth 2.0

I passaggi seguenti mostrano come la tua applicazione interagisce con il server OAuth 2.0 di Google per ottenere il consenso di un utente per eseguire una richiesta API per conto dell'utente. La tua applicazione deve disporre di tale consenso prima di poter eseguire una richiesta API di Google che richiede l'autorizzazione dell'utente.

L'elenco seguente riassume rapidamente questi passaggi:

  1. La tua applicazione identifica le autorizzazioni di cui ha bisogno.
  2. La tua applicazione reindirizza l'utente a Google insieme all'elenco delle autorizzazioni richieste.
  3. L'utente decide se concedere le autorizzazioni alla tua applicazione.
  4. La tua applicazione scopre cosa ha deciso l'utente.
  5. Se l'utente ha concesso le autorizzazioni richieste, l'applicazione recupera i token necessari per effettuare richieste API per conto dell'utente.

Passaggio 1: impostare i parametri di autorizzazione

Il primo passo è creare la richiesta di autorizzazione. Tale richiesta imposta i parametri che identificano la tua applicazione e definiscono le autorizzazioni che all'utente verrà chiesto di concedere alla tua applicazione.

  • Se utilizzi una libreria client di Google per l'autenticazione e l'autorizzazione OAuth 2.0, crei e configuri un oggetto che definisce questi parametri.
  • Se chiami direttamente l'endpoint Google OAuth 2.0, genererai un URL e imposterai i parametri su tale URL.

Le schede seguenti definiscono i parametri di autorizzazione supportati per le applicazioni del server Web. Gli esempi specifici della lingua mostrano anche come utilizzare una libreria client o una libreria di autorizzazione per configurare un oggetto che imposta tali parametri.

PHP

Il frammento di codice crea una Google_Client() oggetto, che definisce i parametri nella richiesta di autorizzazione.

Che utilizza le informazioni degli oggetti dal file client_secret.json per identificare l'applicazione. (Vedere la creazione di credenziali di autorizzazione per di più su quel file.) L'oggetto identifica anche gli ambiti che l'applicazione richiede il permesso di accesso e l'URL di endpoint di autenticazione dell'applicazione, che si occuperà della risposta dal server OAuth 2.0 di Google. Infine, il codice imposta le opzionali access_type e include_granted_scopes parametri.

Ad esempio, questo codice richiede l'accesso offline di sola lettura al Google Drive di un utente:

$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

La richiesta specifica le seguenti informazioni:

Parametri
client_id Necessario

L'ID client per la tua applicazione. È possibile trovare questo valore nella API ConsoleCredentials page.

In PHP, chiamare la setAuthConfig funzione per caricare credenziali di autorizzazione da un file client_secret.json.

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

Determina dove il server API reindirizza l'utente dopo che l'utente ha completato il flusso di autorizzazione. Il valore deve corrispondere esattamente uno degli URI reindirizzamento autorizzati per il cliente OAuth 2.0, che si è configurato nel del cliente API ConsoleCredentials page. Se questo valore non corrisponde a un reindirizzamento URI autorizzato per la condizione client_id si otterrà un redirect_uri_mismatch errore.

Si noti che l' http o https schema, caso, e lo slash ( ' / ') deve tutti i match.

Per impostare questo valore in PHP, chiamare la setRedirectUri funzioni. Si noti che è necessario specificare un URI reindirizzamento valido per il previsto client_id .

$client->setRedirectUri('https://oauth2.example.com/code');
scope Necessario

Un elenco di ambiti delimitato da spazi che identificano le risorse a cui l'applicazione potrebbe accedere per conto dell'utente. Questi valori informano la schermata di consenso che Google mostra all'utente.

Gli ambiti consentono alla tua applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, consentendo anche agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

Per impostare questo valore in PHP, chiamare addScope funzione di:

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

È consigliabile che l'applicazione richieda l'accesso agli ambiti di autorizzazione nel contesto quando possibile. Richiedendo l'accesso ai dati degli utenti nel contesto, tramite l'autorizzazione incrementale , è aiutare gli utenti a comprendere più facilmente perché l'applicazione ha bisogno l'accesso che sta chiedendo.

access_type Consigliato

Indica se l'applicazione può aggiornare i token di accesso quando l'utente non è presente nel browser. I valori dei parametri validi sono online , che è il valore di default, e offline .

Impostare il valore offline se le vostre esigenze applicative per rinfrescare token di accesso quando l'utente non è presente al browser. Questo è il metodo per aggiornare i token di accesso descritto più avanti in questo documento. Questo valore indica al server di autorizzazione di Google per restituire un token di aggiornamento e di un token di accesso la prima volta che i vostri scambi di applicazione di un codice di autorizzazione per i token.

Per impostare questo valore in PHP, chiamare la setAccessType funzione di:

$client->setAccessType('offline');
state Consigliato

Specifica qualsiasi valore stringa utilizzato dall'applicazione per mantenere lo stato tra la richiesta di autorizzazione e la risposta del server di autorizzazione. Il server restituisce il valore esatto che si invia come un name=value coppia nella componente di query URL ( ? ) Del redirect_uri dopo l'utente acconsente o nega richiesta di accesso dell'applicazione.

È possibile utilizzare questo parametro per diversi scopi, ad esempio indirizzare l'utente alla risorsa corretta nell'applicazione, inviare nonce e mitigare la falsificazione delle richieste tra siti. Dal momento che il redirect_uri può essere indovinato, utilizzando uno state valore può aumentare la garanzia che una connessione in ingresso è il risultato di una richiesta di autenticazione. Se si genera una stringa casuale o si codifica l'hash di un cookie o un altro valore che acquisisce lo stato del client, è possibile convalidare la risposta per garantire inoltre che la richiesta e la risposta abbiano avuto origine nello stesso browser, fornendo protezione contro attacchi come cross-site richiesta di falsificazione. Vedere l' OpenID Connect documentazione per un esempio di come creare e confermare una state token.

Per impostare questo valore in PHP, chiamare la setState funzione di:

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

Consente alle applicazioni di utilizzare l'autorizzazione incrementale per richiedere l'accesso a ambiti aggiuntivi nel contesto. Se si imposta il valore di questo parametro al true e la richiesta di autorizzazione viene concessa, quindi il nuovo token di accesso riguarderà anche tutti gli ambiti a cui l'utente in precedenza concesso l'accesso alle applicazioni. Vedere l' autorizzazione incrementale sezione per gli esempi.

Per impostare questo valore in PHP, chiamare la setIncludeGrantedScopes funzione di:

$client->setIncludeGrantedScopes(true);
login_hint Opzionale

Se la tua applicazione sa quale utente sta tentando di autenticarsi, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione di Google. Il server utilizza il suggerimento per semplificare il flusso di accesso precompilando il campo e-mail nel modulo di accesso o selezionando la sessione di accesso multiplo appropriata.

Impostare il valore del parametro a un indirizzo e-mail o sub identificativo, che è equivalente a dell'utente di Google ID.

Per impostare questo valore in PHP, chiamare la setLoginHint funzione di:

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

Un elenco di prompt delimitato da spazi e con distinzione tra maiuscole e minuscole da presentare all'utente. Se non specifichi questo parametro, all'utente verrà richiesto solo la prima volta che il tuo progetto richiede l'accesso. Vedere La richiesta di conferma nuovamente il consenso per ulteriori informazioni.

Per impostare questo valore in PHP, chiamare la setApprovalPrompt funzione di:

$client->setApprovalPrompt('consent');

I valori possibili sono:

none Non visualizzare alcuna schermata di autenticazione o consenso. Non deve essere specificato con altri valori.
consent Richiedere il consenso all'utente.
select_account Chiedi all'utente di selezionare un account.

Pitone

Il seguente frammento di codice utilizza il google-auth-oauthlib.flow modulo per costruire la richiesta di autorizzazione.

Il codice crea un Flow oggetto, che identifica le informazioni applicazione utilizzando dal file client_secret.json scaricato dopo la creazione di credenziali di autorizzazione . Quell'oggetto identifica anche gli ambiti a cui la tua applicazione richiede l'autorizzazione per accedere e l'URL all'endpoint di autenticazione della tua applicazione, che gestirà la risposta dal server OAuth 2.0 di Google. Infine, il codice imposta le opzionali access_type e include_granted_scopes parametri.

Ad esempio, questo codice richiede l'accesso offline di sola lettura al Google Drive di un utente:

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')

La richiesta specifica le seguenti informazioni:

Parametri
client_id Necessario

L'ID client per la tua applicazione. È possibile trovare questo valore nella API ConsoleCredentials page.

In Python, chiamare il from_client_secrets_file metodo per recuperare l'ID del cliente da un file client_secret.json. (È inoltre possibile utilizzare il from_client_config metodo, che passa la configurazione del client come è originariamente apparso in un file segreti client, ma non accede al file stesso.)

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

Determina dove il server API reindirizza l'utente dopo che l'utente ha completato il flusso di autorizzazione. Il valore deve corrispondere esattamente uno degli URI reindirizzamento autorizzati per il cliente OAuth 2.0, che si è configurato nel del cliente API ConsoleCredentials page. Se questo valore non corrisponde a un reindirizzamento URI autorizzato per la condizione client_id si otterrà un redirect_uri_mismatch errore.

Si noti che l' http o https schema, caso, e lo slash ( ' / ') deve tutti i match.

Per impostare questo valore in Python, impostare il flow dell'oggetto redirect_uri proprietà:

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

Un elenco di ambiti che identificano le risorse a cui l'applicazione potrebbe accedere per conto dell'utente. Questi valori informano la schermata di consenso che Google mostra all'utente.

Gli ambiti consentono alla tua applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, consentendo anche agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

In Python, utilizzare lo stesso metodo utilizzato per impostare il client_id per specificare l'elenco di ambiti.

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

È consigliabile che l'applicazione richieda l'accesso agli ambiti di autorizzazione nel contesto quando possibile. Richiedendo l'accesso ai dati degli utenti nel contesto, tramite l'autorizzazione incrementale , è aiutare gli utenti a comprendere più facilmente perché l'applicazione ha bisogno l'accesso che sta chiedendo.

access_type Consigliato

Indica se l'applicazione può aggiornare i token di accesso quando l'utente non è presente nel browser. I valori dei parametri validi sono online , che è il valore di default, e offline .

Impostare il valore offline se le vostre esigenze applicative per rinfrescare token di accesso quando l'utente non è presente al browser. Questo è il metodo per aggiornare i token di accesso descritto più avanti in questo documento. Questo valore indica al server di autorizzazione di Google per restituire un token di aggiornamento e di un token di accesso la prima volta che i vostri scambi di applicazione di un codice di autorizzazione per i token.

In Python, impostare il access_type parametro specificando access_type come un argomento parola chiave quando si chiama il flow.authorization_url metodo:

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

Specifica qualsiasi valore stringa utilizzato dall'applicazione per mantenere lo stato tra la richiesta di autorizzazione e la risposta del server di autorizzazione. Il server restituisce il valore esatto che si invia come un name=value coppia nella componente di query URL ( ? ) Del redirect_uri dopo l'utente acconsente o nega richiesta di accesso dell'applicazione.

È possibile utilizzare questo parametro per diversi scopi, ad esempio indirizzare l'utente alla risorsa corretta nell'applicazione, inviare nonce e mitigare la falsificazione delle richieste tra siti. Dal momento che il redirect_uri può essere indovinato, utilizzando uno state valore può aumentare la garanzia che una connessione in ingresso è il risultato di una richiesta di autenticazione. Se si genera una stringa casuale o si codifica l'hash di un cookie o un altro valore che acquisisce lo stato del client, è possibile convalidare la risposta per garantire inoltre che la richiesta e la risposta abbiano avuto origine nello stesso browser, fornendo protezione contro attacchi come cross-site richiesta di falsificazione. Vedere l' OpenID Connect documentazione per un esempio di come creare e confermare una state token.

In Python, impostare lo state parametro specificando state come un argomento parola chiave quando si chiama il flow.authorization_url metodo:

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

Consente alle applicazioni di utilizzare l'autorizzazione incrementale per richiedere l'accesso a ambiti aggiuntivi nel contesto. Se si imposta il valore di questo parametro al true e la richiesta di autorizzazione viene concessa, quindi il nuovo token di accesso riguarderà anche tutti gli ambiti a cui l'utente in precedenza concesso l'accesso alle applicazioni. Vedere l' autorizzazione incrementale sezione per gli esempi.

In Python, impostare le include_granted_scopes parametro specificando include_granted_scopes come argomento di parola chiave quando si chiama il flow.authorization_url metodo:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
login_hint Opzionale

Se la tua applicazione sa quale utente sta tentando di autenticarsi, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione di Google. Il server utilizza il suggerimento per semplificare il flusso di accesso precompilando il campo e-mail nel modulo di accesso o selezionando la sessione di accesso multiplo appropriata.

Impostare il valore del parametro a un indirizzo e-mail o sub identificativo, che è equivalente a dell'utente di Google ID.

In Python, impostare il login_hint parametro specificando login_hint come un argomento parola chiave quando si chiama il flow.authorization_url metodo:

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

Un elenco di prompt delimitato da spazi e con distinzione tra maiuscole e minuscole da presentare all'utente. Se non specifichi questo parametro, all'utente verrà richiesto solo la prima volta che il tuo progetto richiede l'accesso. Vedere La richiesta di conferma nuovamente il consenso per ulteriori informazioni.

In Python, impostare il prompt parametri specificando prompt come un argomento parola chiave quando si chiama il flow.authorization_url metodo:

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

I valori possibili sono:

none Non visualizzare alcuna schermata di autenticazione o consenso. Non deve essere specificato con altri valori.
consent Richiedere il consenso all'utente.
select_account Chiedi all'utente di selezionare un account.

Rubino

Usa il file client_secrets.json che hai creato per configurare un oggetto client nella tua applicazione. Quando si configura un oggetto client, si specificano gli ambiti a cui l'applicazione deve accedere, insieme all'URL dell'endpoint di autenticazione dell'applicazione, che gestirà la risposta dal server OAuth 2.0.

Ad esempio, questo codice richiede l'accesso offline di sola lettura al Google Drive di un utente:

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
  }
)

L'applicazione utilizza l'oggetto client per eseguire operazioni OAuth 2.0, come la generazione di URL di richiesta di autorizzazione e l'applicazione di token di accesso alle richieste HTTP.

HTTP/REST

Endpoint di Google OAuth 2.0 è a https://accounts.google.com/o/oauth2/v2/auth . Questo endpoint è accessibile solo tramite HTTPS. Le connessioni HTTP semplici vengono rifiutate.

Il server di autorizzazione di Google supporta i seguenti parametri della stringa di query per le applicazioni del server web:

Parametri
client_id Necessario

L'ID client per la tua applicazione. È possibile trovare questo valore nella API ConsoleCredentials page.

redirect_uri Necessario

Determina dove il server API reindirizza l'utente dopo che l'utente ha completato il flusso di autorizzazione. Il valore deve corrispondere esattamente uno degli URI reindirizzamento autorizzati per il cliente OAuth 2.0, che si è configurato nel del cliente API ConsoleCredentials page. Se questo valore non corrisponde a un reindirizzamento URI autorizzato per la condizione client_id si otterrà un redirect_uri_mismatch errore.

Si noti che l' http o https schema, caso, e lo slash ( ' / ') deve tutti i match.

response_type Necessario

Determina se l'endpoint Google OAuth 2.0 restituisce un codice di autorizzazione.

Impostare il valore del parametro per code per le applicazioni server web.

scope Necessario

Un elenco di ambiti delimitato da spazi che identificano le risorse a cui l'applicazione potrebbe accedere per conto dell'utente. Questi valori informano la schermata di consenso che Google mostra all'utente.

Gli ambiti consentono alla tua applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, consentendo anche agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

È consigliabile che l'applicazione richieda l'accesso agli ambiti di autorizzazione nel contesto quando possibile. Richiedendo l'accesso ai dati degli utenti nel contesto, tramite l'autorizzazione incrementale , è aiutare gli utenti a comprendere più facilmente perché l'applicazione ha bisogno l'accesso che sta chiedendo.

access_type Consigliato

Indica se l'applicazione può aggiornare i token di accesso quando l'utente non è presente nel browser. I valori dei parametri validi sono online , che è il valore di default, e offline .

Impostare il valore offline se le vostre esigenze applicative per rinfrescare token di accesso quando l'utente non è presente al browser. Questo è il metodo per aggiornare i token di accesso descritto più avanti in questo documento. Questo valore indica al server di autorizzazione di Google per restituire un token di aggiornamento e di un token di accesso la prima volta che i vostri scambi di applicazione di un codice di autorizzazione per i token.

state Consigliato

Specifica qualsiasi valore stringa utilizzato dall'applicazione per mantenere lo stato tra la richiesta di autorizzazione e la risposta del server di autorizzazione. Il server restituisce il valore esatto che si invia come un name=value coppia nella componente di query URL ( ? ) Del redirect_uri dopo l'utente acconsente o nega richiesta di accesso dell'applicazione.

È possibile utilizzare questo parametro per diversi scopi, ad esempio indirizzare l'utente alla risorsa corretta nell'applicazione, inviare nonce e mitigare la falsificazione delle richieste tra siti. Dal momento che il redirect_uri può essere indovinato, utilizzando uno state valore può aumentare la garanzia che una connessione in ingresso è il risultato di una richiesta di autenticazione. Se si genera una stringa casuale o si codifica l'hash di un cookie o un altro valore che acquisisce lo stato del client, è possibile convalidare la risposta per garantire inoltre che la richiesta e la risposta abbiano avuto origine nello stesso browser, fornendo protezione contro attacchi come cross-site richiesta di falsificazione. Vedere l' OpenID Connect documentazione per un esempio di come creare e confermare una state token.

include_granted_scopes Opzionale

Consente alle applicazioni di utilizzare l'autorizzazione incrementale per richiedere l'accesso a ambiti aggiuntivi nel contesto. Se si imposta il valore di questo parametro al true e la richiesta di autorizzazione viene concessa, quindi il nuovo token di accesso riguarderà anche tutti gli ambiti a cui l'utente in precedenza concesso l'accesso alle applicazioni. Vedere l' autorizzazione incrementale sezione per gli esempi.

login_hint Opzionale

Se la tua applicazione sa quale utente sta tentando di autenticarsi, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione di Google. Il server utilizza il suggerimento per semplificare il flusso di accesso precompilando il campo e-mail nel modulo di accesso o selezionando la sessione di accesso multiplo appropriata.

Impostare il valore del parametro a un indirizzo e-mail o sub identificativo, che è equivalente a dell'utente di Google ID.

prompt Opzionale

Un elenco di prompt delimitato da spazi e con distinzione tra maiuscole e minuscole da presentare all'utente. Se non specifichi questo parametro, all'utente verrà richiesto solo la prima volta che il tuo progetto richiede l'accesso. Vedere La richiesta di conferma nuovamente il consenso per ulteriori informazioni.

I valori possibili sono:

none Non visualizzare alcuna schermata di autenticazione o consenso. Non deve essere specificato con altri valori.
consent Richiedere il consenso all'utente.
select_account Chiedi all'utente di selezionare un account.

Passaggio 2: reindirizza al server OAuth 2.0 di Google

Reindirizza l'utente al server OAuth 2.0 di Google per avviare il processo di autenticazione e autorizzazione. In genere, ciò si verifica quando l'applicazione deve prima accedere ai dati dell'utente. In caso di autorizzazione incrementale , questo passaggio si verifica anche quando l'applicazione deve prima per accedere alle risorse aggiuntive che non ha ancora il permesso di accesso.

PHP

  1. Genera un URL per accedere richiesta da parte di Google OAuth 2.0 Server:
    $auth_url = $client->createAuthUrl();
  2. Reindirizzare l'utente a $auth_url :
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

Pitone

Questo esempio mostra come reindirizzare l'utente all'URL di autorizzazione utilizzando il framework dell'applicazione Web Flask:

return flask.redirect(authorization_url)

Rubino

  1. Genera un URL per accedere richiesta da parte di Google OAuth 2.0 Server:
    auth_uri = auth_client.authorization_uri.to_s
  2. Reindirizzare l'utente a auth_uri .

HTTP/REST

Esempio di reindirizzamento al server di autorizzazione di Google

Di seguito è mostrato un URL di esempio, con interruzioni di riga e spazi per la leggibilità.

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

Dopo aver creato l'URL della richiesta, reindirizzare l'utente ad esso.

Il server OAuth 2.0 di Google autentica l'utente e ottiene il consenso dall'utente affinché la tua applicazione acceda agli ambiti richiesti. La risposta viene inviata alla tua applicazione utilizzando l'URL di reindirizzamento specificato.

Passaggio 3: Google richiede all'utente il consenso

In questo passaggio, l'utente decide se concedere alla propria applicazione l'accesso richiesto. In questa fase Google visualizza una finestra di consenso che mostra il nome della tua applicazione e i servizi API di Google a cui sta richiedendo l'autorizzazione per accedere con le credenziali di autorizzazione dell'utente e un riepilogo degli ambiti di accesso da concedere. L'utente può quindi acconsentire a concedere l'accesso a uno o più ambiti richiesti dalla propria applicazione oppure rifiutare la richiesta.

La tua applicazione non deve eseguire alcuna operazione in questa fase poiché attende la risposta dal server OAuth 2.0 di Google che indica se è stato concesso l'accesso. Tale risposta è spiegata nel passaggio successivo.

Errori

Le richieste all'endpoint di autorizzazione OAuth 2.0 di Google possono visualizzare messaggi di errore rivolti all'utente invece dei flussi di autenticazione e autorizzazione previsti. Di seguito sono elencati i codici di errore comuni e le soluzioni suggerite.

admin_policy_enforced

L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa delle norme dell'amministratore di Google Workspace. Vedere l'articolo della guida di Google area di lavoro di amministrazione di controllo che di terze parti e applicazioni interne accedere ai dati di Google area di lavoro per ulteriori informazioni su come un amministratore può limitare l'accesso a tutti gli ambiti o ambiti sensibili e riservate fino a quando l'accesso viene esplicitamente concesso al proprio ID cliente OAuth.

disallowed_useragent

L'endpoint autorizzazione viene visualizzato all'interno di un'user-agent integrato annullato da Google Politiche OAuth 2.0 .

Android

Gli sviluppatori di Android possono incontrare questo messaggio di errore quando si apre le richieste di autorizzazione a android.webkit.WebView . Gli sviluppatori dovrebbero invece utilizzare le librerie Android come Google Sign-In per Android o di OpenID Foundation AppAuth per Android .

Gli sviluppatori Web possono riscontrare questo errore quando un'app Android apre un collegamento Web generale in un agente utente incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google dal tuo sito. Gli sviluppatori dovrebbero consentire collegamenti generali di aprire nel gestore di collegamento di default del sistema operativo, che comprende sia Android App Links gestori o l'applicazione browser predefinito. L' Android personalizzato Tabs biblioteca è anche un'opzione supportata.

iOS

iOS e MacOS sviluppatori possono incontrare questo errore quando si aprono le richieste di autorizzazione a WKWebView . Gli sviluppatori dovrebbero invece utilizzare le librerie di iOS come ad esempio Google Sign-In per iOS o di OpenID Foundation AppAuth per iOS .

Gli sviluppatori Web possono riscontrare questo errore quando un'app iOS o macOS apre un collegamento Web generale in un agente utente incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google dal tuo sito. Gli sviluppatori dovrebbero consentire collegamenti generali di aprire nel gestore di collegamento di default del sistema operativo, che comprende sia universale Links gestori o l'applicazione browser predefinito. Lo SFSafariViewController biblioteca è anche un'opzione supportata.

org_internal

L'ID client OAuth nella richiesta fa parte di un progetto di limitare l'accesso a Google Account in una specifica Google Cloud Organizzazione . Per ulteriori informazioni su questa opzione di configurazione vedere il tipo di utente sezione nel Installazione del OAuth consenso schermata di aiuto articolo.

redirect_uri_mismatch

Il redirect_uri passato nella richiesta di autorizzazione non corrisponde un reindirizzamento autorizzato URI per l'ID client OAuth. Recensione autorizzato URI reindirizzamento della Google API Console Credentials page.

Passaggio 4: gestire la risposta del server OAuth 2.0

Il server OAuth 2.0 risponde alla richiesta di accesso dell'applicazione utilizzando l'URL specificato nella richiesta.

Se l'utente approva la richiesta di accesso, la risposta contiene un codice di autorizzazione. Se l'utente non approva la richiesta, la risposta contiene un messaggio di errore. Il codice di autorizzazione o il messaggio di errore restituito al server Web viene visualizzato nella stringa di query, come mostrato di seguito:

Una risposta di errore:

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

Una risposta del codice di autorizzazione:

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

Esempio di risposta del server OAuth 2.0

Puoi testare questo flusso facendo clic sul seguente URL di esempio, che richiede l'accesso in sola lettura per visualizzare i metadati per i file nel tuo 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

After completing the OAuth 2.0 flow, you should be redirected to http://localhost/oauth2callback , which will likely yield a 404 NOT FOUND error unless your local machine serves a file at that address. The next step provides more detail about the information returned in the URI when the user is redirected back to your application.

Step 5: Exchange authorization code for refresh and access tokens

After the web server receives the authorization code, it can exchange the authorization code for an access token.

PHP

To exchange an authorization code for an access token, use the authenticate method:

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

You can retrieve the access token with the getAccessToken method:

$access_token = $client->getAccessToken();

Python

On your callback page, use the google-auth library to verify the authorization server response. Then, use the flow.fetch_token method to exchange the authorization code in that response for an access token:

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}

Ruby

To exchange an authorization code for an access token, use the fetch_access_token! method:

auth_client.code = auth_code
auth_client.fetch_access_token!

HTTP/REST

To exchange an authorization code for an access token, call the https://oauth2.googleapis.com/token endpoint and set the following parameters:

Fields
client_id The client ID obtained from the API ConsoleCredentials page.
client_secret The client secret obtained from the API ConsoleCredentials page.
code The authorization code returned from the initial request.
grant_type As defined in the OAuth 2.0 specification , this field's value must be set to authorization_code .
redirect_uri One of the redirect URIs listed for your project in the API ConsoleCredentials page for the given client_id .

The following snippet shows a sample request:

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

Google responds to this request by returning a JSON object that contains a short-lived access token and a refresh token. Note that the refresh token is only returned if your application set the access_type parameter to offline in the initial request to Google's authorization server .

The response contains the following fields:

Fields
access_token The token that your application sends to authorize a Google API request.
expires_in The remaining lifetime of the access token in seconds.
refresh_token A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Again, this field is only present in this response if you set the access_type parameter to offline in the initial request to Google's authorization server.
scope The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings.
token_type The type of token returned. At this time, this field's value is always set to 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

Redirect URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule.

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” .
  • Redirect 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 .

    Fragment

    Redirect URIs cannot contain the fragment component.

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