Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.

Utilizzo di OAuth 2.0 per applicazioni da server a server

Il sistema Google OAuth 2.0 supporta interazioni da server a server come quelle tra un'applicazione web e un servizio Google. Per questo scenario è necessario un account di servizio, che è un account che appartiene alla vostra applicazione invece che a un singolo utente finale. La tua applicazione chiama le API di Google per conto dell'account di servizio, quindi gli utenti non sono direttamente coinvolti. Questo scenario è talvolta chiamato "OAuth a due vie" o "2LO". (Il termine correlato "OAuth a tre vie" si riferisce a scenari in cui la tua applicazione chiama le API di Google per conto degli utenti finali e in cui a volte è richiesto il consenso dell'utente.)

In genere, un'applicazione utilizza un account di servizio quando l'applicazione utilizza le API di Google per lavorare con i propri dati anziché con i dati di un utente. Ad esempio, un'applicazione che utilizza Google Cloud Datastore per la persistenza dei dati utilizzerà un account di servizio per autenticare le sue chiamate all'API Google Cloud Datastore.

Gli amministratori di dominio Google area di lavoro può concedere il servizio account autorità a livello di dominio ai dati degli utenti l'accesso per conto degli utenti del dominio.

Questo documento descrive come un'applicazione può completare il flusso OAuth 2.0 da server a server utilizzando una libreria client delle API di Google (consigliato) o HTTP.

Panoramica

Per server-to-server di interazioni di supporto, prima creare un account di servizio per il vostro progetto nel API Console. Se desideri accedere ai dati utente per gli utenti nel tuo account Google Workspace, delega l'accesso a livello di dominio all'account di servizio.

Quindi, l'applicazione si prepara a effettuare chiamate API autorizzate utilizzando le credenziali dell'account di servizio per richiedere un token di accesso dal server di autenticazione OAuth 2.0.

Infine, la tua applicazione può utilizzare il token di accesso per chiamare le API di Google.

Creazione di un account di servizio

Le credenziali di un account di servizio includono un indirizzo email generato che è univoco e almeno una coppia di chiavi pubblica/privata. Se è abilitata la delega a livello di dominio, anche un ID client fa parte delle credenziali dell'account di servizio.

Se la tua applicazione viene eseguita su Google App Engine, un account di servizio viene impostato automaticamente quando crei il tuo progetto.

Se la tua applicazione viene eseguita su Google Compute Engine, anche un account di servizio viene impostato automaticamente quando crei il progetto, ma devi specificare gli ambiti a cui la tua applicazione deve accedere quando crei un'istanza di Google Compute Engine. Per ulteriori informazioni, vedere Preparazione di un esempio per gli account di servizio uso .

Se l'applicazione non viene eseguito su Google App Engine o Google Compute Engine, è necessario ottenere queste credenziali nel Google API Console. Per generare le credenziali dell'account di servizio o per visualizzare le credenziali pubbliche che hai già generato, procedi come segue:

  1. Aprire Service accounts page .
  2. If prompted, select a project, or create a new one.
  3. Fai clic su account di servizio .
  4. In Dettagli account servizio , digitare un nome, ID e descrizione per l'account del servizio, quindi fare clic su Crea .
  5. Facoltativo: in Autorizzazioni account servizio , selezionare i ruoli IAM da concedere all'account del servizio, quindi fare clic su Continua .
  6. Facoltativo: in Concedi agli utenti l'accesso a questo account di servizio , aggiungere gli utenti o i gruppi autorizzati a utilizzare e gestire l'account di servizio.
  7. Fai clic su chiave di creazione , quindi fai clic su Crea .

La tua nuova coppia di chiavi pubblica / privata viene generata e scaricata sul tuo computer; funge da unica copia della chiave privata. Sei responsabile di conservarlo in modo sicuro. Se perdi questa coppia di chiavi, dovrai generarne una nuova.

Se devi concedere l' autorizzazione a livello di dominio G Suite all'account del servizio, fai clic sull'indirizzo email dell'account del servizio che hai creato, quindi copia il valore dalla casella ID univoco .

Per delegare l'autorizzazione all'account del servizio, utilizzare il valore copiato come ID client.

È possibile tornare alla API Console in qualsiasi momento per visualizzare l'indirizzo di posta elettronica, le impronte digitali a chiave pubblica, e altre informazioni, o per generare ulteriori / coppie di chiavi private pubblica. Per maggiori dettagli su conto credenziali del servizio nel API Console, vedere i conti Servizio in API Consolefile di aiuto.

Prendi nota dell'indirizzo e-mail dell'account di servizio e archivia il file della chiave privata dell'account di servizio in una posizione accessibile alla tua applicazione. La tua applicazione ne ha bisogno per effettuare chiamate API autorizzate.

Delegare l'autorità a livello di dominio all'account di servizio

Se disponi di un account Google Workspace, un amministratore dell'organizzazione può autorizzare un'applicazione ad accedere ai dati utente per conto degli utenti nel dominio Google Workspace. Ad esempio, un'applicazione che utilizza l'API di Google Calendar per aggiungere eventi ai calendari di tutti gli utenti in un dominio Google Workspace utilizzerebbe un account di servizio per accedere all'API di Google Calendar per conto degli utenti. L'autorizzazione di un account di servizio per accedere ai dati per conto degli utenti in un dominio viene talvolta definita "delega dell'autorità a livello di dominio" a un account di servizio.

Per delegare l'autorità a livello di dominio a un account di servizio, prima abilitare la delega a livello di dominio per un account di servizio esistente nel Service accounts page o creare un nuovo account di servizio con delega a livello di dominio abilitato.

Quindi, un super amministratore del dominio Google Workspace deve completare i seguenti passaggi:

  1. Da del dominio Google area di lavoro della Console di amministrazione , andare al menu principale > Sicurezza> Controlli API.
  2. Nel riquadro delegazione ampia di dominio, selezionare Gestione Dominio ampia delega.
  3. Fare clic su Aggiungi nuovo.
  4. Nel campo ID cliente, inserire l'ID cliente dell'account di servizio. È possibile trovare l'ID cliente del tuo account di servizio nel Service accounts page.
  5. Negli ambiti OAuth campo (delimitato da virgole), inserire l'elenco degli ambiti che l'applicazione deve essere concesso l'accesso a. Ad esempio, se l'applicazione ha bisogno di accedere a livello di dominio completo alle API di Google Drive e l'API di Google Calendar, immettere: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth calendario /.
  6. Fare clic su Autorizza.

La tua applicazione ora ha l'autorità per effettuare chiamate API come utenti nel tuo dominio (per "impersonare" utenti). Quando ti prepari a effettuare chiamate API autorizzate, specifichi l'utente da impersonare.

Preparazione per effettuare una chiamata API autorizzata

Giava

Dopo aver ottenuto l'indirizzo di posta elettronica del client e la chiave privata dal API Console, utilizzare la libreria client di Google API per Java per creare un GoogleCredential oggetto dalle credenziali dell'account di servizio e gli ambiti l'applicazione ha bisogno di accedere a. Per esempio:

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

Se si sta sviluppando un'app su Google Cloud Platform, è possibile utilizzare le credenziali predefinite applicazione , invece, in grado di semplificare il processo.

Delegare l'autorità a livello di dominio

Se è stato delegato l'accesso a livello di dominio per l'account del servizio e si desidera impersonare un account utente, specificare l'indirizzo e-mail dell'account utente con il createDelegated metodo GoogleCredential dell'oggetto. Per esempio:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("user@example.com");

Utilizzare l' GoogleCredential oggetto di chiamare Google API nell'applicazione.

Pitone

Dopo aver ottenuto l'indirizzo di posta elettronica del client e la chiave privata dal API Console, utilizzare la libreria client di Google API per Python per effettuare le seguenti operazioni:

  1. Creare un Credentials oggetto dalle credenziali dell'account di servizio e gli ambiti l'applicazione ha bisogno di accedere a. Ad esempio:
    from google.oauth2 import service_account
    
    SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
    SERVICE_ACCOUNT_FILE = '/path/to/service.json'
    
    credentials = service_account.Credentials.from_service_account_file(
            SERVICE_ACCOUNT_FILE, scopes=SCOPES)

    Se si sta sviluppando un'app su Google Cloud Platform, è possibile utilizzare le credenziali predefinite applicazione , invece, in grado di semplificare il processo.

  2. Delegare l'autorità a livello di dominio

    Se è stato delegato l'accesso a livello di dominio per l'account del servizio e si desidera impersonare un account utente, utilizzare il with_subject metodo di un esistente ServiceAccountCredentials oggetto. Per esempio:

    delegated_credentials = credentials.with_subject('user@example.org')

Utilizza l'oggetto Credentials per chiamare le API di Google nella tua applicazione.

HTTP/REST

Dopo aver ottenuto il client ID e la chiave privata dal API Console, l'applicazione deve effettuare le seguenti operazioni:

  1. Crea un token Web JSON (JWT, pronunciato, "jot") che includa un'intestazione, un set di attestazioni e una firma.
  2. Richiedi un token di accesso dal server di autorizzazione di Google OAuth 2.0.
  3. Gestire la risposta JSON restituita dal server di autorizzazione.

Le sezioni che seguono descrivono come completare questi passaggi.

Se la risposta include un token di accesso, è possibile utilizzare il token di accesso per chiamare un'API di Google . (Se la risposta non include un token di accesso, la richiesta JWT e token potrebbe non essere formata correttamente o l'account di servizio potrebbe non disporre dell'autorizzazione per accedere agli ambiti richiesti.)

Quando il token di accesso scade , l'applicazione genera un altro JWT, lo firma, e richiede un token di accesso.

La tua applicazione server utilizza un JWT per richiedere un token dal server di autorizzazione di Google, quindi utilizza il token per chiamare un endpoint dell'API di Google. Nessun utente finale è coinvolto.

Il resto di questa sezione descrive le specifiche della creazione di un JWT, della firma del JWT, della formazione della richiesta del token di accesso e della gestione della risposta.

Creazione di un JWT

Un JWT è composto da tre parti: un'intestazione, un set di attestazioni e una firma. L'intestazione e il set di attestazioni sono oggetti JSON. Questi oggetti JSON vengono serializzati in byte UTF-8, quindi codificati utilizzando la codifica Base64url. Questa codifica fornisce resilienza contro le modifiche alla codifica dovute a ripetute operazioni di codifica. L'intestazione, set rivendicazione, e la firma sono concatenati insieme con un punto ( . ) Carattere.

Un JWT è composto come segue:

{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}

La stringa di base per la firma è la seguente:

{Base64url encoded header}.{Base64url encoded claim set}
Formare l'intestazione JWT

L'intestazione è composta da due campi che indicano l'algoritmo di firma e il formato dell'asserzione. Entrambi i campi sono obbligatori e ogni campo ha un solo valore. Man mano che vengono introdotti algoritmi e formati aggiuntivi, questa intestazione cambierà di conseguenza.

Gli account di servizio si basano sull'algoritmo RSA SHA-256 e sul formato token JWT. Di conseguenza, la rappresentazione JSON dell'intestazione è la seguente:

{"alg":"RS256","typ":"JWT"}

La rappresentazione Base64url di questo è la seguente:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
Formazione del set di attestazioni JWT

Il set di attestazioni JWT contiene informazioni sul JWT, incluse le autorizzazioni richieste (ambiti), la destinazione del token, l'emittente, l'ora di emissione del token e la durata del token. La maggior parte dei campi sono obbligatori. Come l'intestazione JWT, il set di attestazioni JWT è un oggetto JSON e viene utilizzato nel calcolo della firma.

Richieste richieste

Le attestazioni richieste nel set di attestazioni JWT sono mostrate di seguito. Possono apparire in qualsiasi ordine nella serie di rivendicazioni.

Nome Descrizione
iss L'indirizzo email dell'account di servizio.
scope Un elenco delimitato da spazi delle autorizzazioni richieste dall'applicazione.
aud Un descrittore del target previsto dell'asserzione. Quando si effettua una richiesta di token di accesso questo valore è sempre https://oauth2.googleapis.com/token .
exp L'ora di scadenza dell'asserzione, specificata in secondi dalle 00:00:00 UTC, 1 gennaio 1970. Questo valore ha un massimo di 1 ora dopo l'ora emessa.
iat L'ora in cui è stata emessa l'asserzione, specificata in secondi dalle 00:00:00 UTC, 1 gennaio 1970.

La rappresentazione JSON dei campi obbligatori in un set di attestazioni JWT è mostrata di seguito:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Reclami aggiuntivi

In alcuni casi aziendali, un'applicazione può utilizzare la delega a livello di dominio per agire per conto di un particolare utente in un'organizzazione. L'autorizzazione per eseguire questo tipo di rappresentazione deve essere concessa prima che un'applicazione possa impersonare un utente e di solito è gestita da un super amministratore. Per ulteriori informazioni, consultare l'accesso alle API di controllo con delega a livello di dominio .

Per ottenere un token di accesso che garantisce un'applicazione delegato l'accesso a una risorsa, includere l'indirizzo di posta elettronica dell'utente nel set JWT sinistro, come il valore del sub campo.

Nome Descrizione
sub L'indirizzo di posta elettronica dell'utente per il quale l'applicazione richiede l'accesso delegato.

Se un'applicazione non ha il permesso di rappresentare un utente, la risposta ad una richiesta di token di accesso che include il sub campo sarà un errore .

Un esempio di un insieme rivendicazione JWT che comprende il sub campo è la seguente:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub": "some.user@example.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Codifica del set di attestazioni JWT

Come l'intestazione JWT, il set di attestazioni JWT deve essere serializzato su UTF-8 e codificato Base64url-safe. Di seguito è riportato un esempio di una rappresentazione JSON di un set di attestazioni JWT:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Calcolo della firma

JSON Web Firma (JWS) è la specifica che guide per la meccanica di generare la firma per la JWT. L'input per la firma è l'array di byte del seguente contenuto:

{Base64url encoded header}.{Base64url encoded claim set}

L'algoritmo di firma nell'intestazione JWT deve essere utilizzato durante il calcolo della firma. L'unico algoritmo di firma supportato dal server di autorizzazione OAuth 2.0 di Google è RSA che utilizza l'algoritmo di hashing SHA-256. Questo è espressa come RS256 nel alg campo nell'intestazione JWT.

Firmare la rappresentazione UTF-8 di ingresso utilizzando SHA256withRSA (noto anche come RSASSA-PKCS1-v1_5-SIGN con la funzione di hash SHA-256) con la chiave privata ottenuta dalla Google API Console. L'output sarà un array di byte.

La firma deve quindi essere codificata Base64url. L'intestazione, set rivendicazione, e la firma sono concatenati insieme con un punto ( . ) Carattere. Il risultato è il JWT. Dovrebbe essere il seguente (interruzioni di riga aggiunte per chiarezza):

{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}

Di seguito è riportato un esempio di JWT prima della codifica Base64url:

{"alg":"RS256","typ":"JWT"}.
{
"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
"scope":"https://www.googleapis.com/auth/prediction",
"aud":"https://oauth2.googleapis.com/token",
"exp":1328554385,
"iat":1328550785
}.
[signature bytes]

Di seguito è riportato un esempio di un JWT che è stato firmato ed è pronto per la trasmissione:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ

Effettuare la richiesta del token di accesso

Dopo aver generato il JWT firmato, un'applicazione può utilizzarlo per richiedere un token di accesso. Questo token di accesso richiesta è un HTTPS POST richiesta, e il corpo è URL codificato. L'URL è mostrato di seguito:

https://oauth2.googleapis.com/token

I seguenti parametri sono necessari nel HTTPS POST richiesta:

Nome Descrizione
grant_type Utilizzare la seguente stringa, URL codificato come necessario: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion Il JWT, inclusa la firma.

Di seguito è riportato un dump raw del HTTPS POST richiesta usato in un token di accesso richiesta:

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ

Qui di seguito è la stessa richiesta, utilizzando curl :

curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU
' https://oauth2.googleapis.com/token

Gestire la risposta

Se il JWT e la richiesta del token di accesso sono formati correttamente e l'account del servizio dispone dell'autorizzazione per eseguire l'operazione, la risposta JSON dal server di autorizzazione include un token di accesso. Quella che segue è una risposta di esempio:

{
  "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M",
  "scope": "https://www.googleapis.com/auth/prediction"
  "token_type": "Bearer",
  "expires_in": 3600
}

Token di accesso possono essere riutilizzati durante la finestra di durata specificata dal expires_in valore.

Chiamare le API di Google

Giava

Utilizzare l' GoogleCredential oggetto di chiamare le API di Google completando le seguenti operazioni:

  1. Creare un oggetto di servizio per l'API che si desidera chiamare utilizzando il GoogleCredential oggetto. Ad esempio:
    SQLAdmin sqladmin =
        new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
  2. Fare richieste al servizio API utilizzando l' interfaccia fornita da l'oggetto del servizio . Ad esempio, per elencare le istanze di database Cloud SQL in questo emozionante-esempio-123 del progetto:
    SQLAdmin.Instances.List instances =
        sqladmin.instances().list("exciting-example-123").execute();

Pitone

Utilizzare i autorizzate Credentials oggetto di chiamare le API di Google completando le seguenti operazioni:

  1. Crea un oggetto di servizio per l'API che vuoi chiamare. Si costruisce aa oggetto di servizio chiamando la build funzione con il nome e la versione delle API e l'autorizzato Credentials oggetto. Ad esempio, per chiamare la versione 1beta3 dell'Amministrazione API Cloud SQL:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. Fare richieste al servizio API utilizzando l' interfaccia fornita da l'oggetto del servizio . Ad esempio, per elencare le istanze di database Cloud SQL in questo emozionante-esempio-123 del progetto:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

HTTP/REST

Dopo che la tua applicazione ottiene un token di accesso, puoi utilizzare il token per effettuare chiamate a un'API di Google per conto di un determinato account di servizio o account utente se sono stati concessi gli ambiti di accesso richiesti dall'API. Per fare questo, includere il token di accesso in una richiesta alla API includendo sia un access_token parametro di ricerca o un Authorization HTTP intestazione Bearer valore. Quando possibile, è preferibile l'intestazione HTTP, perché le stringhe di query tendono ad essere visibili nei log del server. Nella maggior parte dei casi è possibile utilizzare una libreria client per impostare le chiamate a API di Google (ad esempio, quando si chiama l'API Drive Files ).

È possibile provare tutte le API di Google e visualizzare i loro scopi a OAuth 2.0 Playground .

Esempi HTTP GET

Una chiamata al drive.files punto finale (l'API File Drive) con l' Authorization: Bearer header HTTP potrebbe essere simile alla seguente. Tieni presente che devi specificare il tuo token di accesso:

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

Ecco una chiamata alla stessa API per l'utente autenticato utilizzando il access_token parametro stringa di query:

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

curl esempi

È possibile verificare questi comandi con il curl applicazione a riga di comando. Ecco un esempio che utilizza l'opzione di intestazione HTTP (preferita):

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

O, in alternativa, l'opzione del parametro della stringa di query:

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

Quando scadono i token di accesso

Token di accesso rilasciata dal autorizzazione del server di Google OAuth 2.0 scadere dopo la durata prevista dal expires_in valore. Quando un token di accesso scade, l'applicazione dovrebbe generare un altro JWT, firmarlo e richiedere un altro token di accesso.

Codici di errore JWT

error campo error_description campo Significato Come risolvere
unauthorized_client Unauthorized client or scope in request. Se stai tentando di utilizzare la delega a livello di dominio, l'account di servizio non è autorizzato nella Console di amministrazione del dominio dell'utente.

Assicurarsi che l'account di servizio è autorizzato nella delegazione di dominio a livello di pagina della console di amministrazione per l'utente nel sub reclamo (campo).

Anche se in genere sono necessari alcuni minuti, potrebbero essere necessarie fino a 24 ore prima che l'autorizzazione si propaghi a tutti gli utenti nel tuo account Google.

unauthorized_client Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. Un account di servizio è stato autorizzato utilizzando l'indirizzo email del cliente anziché l'ID cliente (numerico) nella Console di amministrazione. Nella delegazione di dominio a livello di pagina nella Console di amministrazione, rimuovere il client, e ri-inserirlo con l'ID numerico.
access_denied (qualsiasi valore) Se utilizzi la delega a livello di dominio, uno o più ambiti richiesti non sono autorizzati nella Console di amministrazione.

Assicurarsi che l'account di servizio è autorizzato nella delegazione di dominio a livello di pagina della console di amministrazione per l'utente nel sub reclamo (campo), e che include tutti gli ambiti si sta richiedendo in scope pretesa del JWT.

Anche se in genere sono necessari alcuni minuti, potrebbero essere necessarie fino a 24 ore prima che l'autorizzazione si propaghi a tutti gli utenti nel tuo account Google.

invalid_grant Not a valid email. L'utente non esiste. Verificare che l'indirizzo di posta elettronica nel sub reclamo (campo) è corretta.
invalid_grant

Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your 'iat' and 'exp' values and use a clock with skew to account for clock differences between systems.

Di solito, significa che l'ora del sistema locale non è corretta. Potrebbe anche accadere se l' exp valore è superiore a 65 minuti, in futuro, dalla iat valore o l' exp valore è inferiore iat valore.

Assicurati che l'orologio sul sistema in cui viene generato il JWT sia corretto. Se necessario, sincronizzare il tempo con Google NTP .

invalid_grant Invalid JWT Signature.

L'asserzione JWT è firmata con una chiave privata non associata all'account di servizio identificato dall'e-mail del client o la chiave utilizzata è stata eliminata, disabilitata o è scaduta.

In alternativa, l'asserzione JWT potrebbe essere codificata in modo errato: deve essere codificata in Base64, senza nuove righe o segni di uguale a riempimento.

Decodifica il set di attestazioni JWT e verifica che la chiave che ha firmato l'asserzione sia associata all'account del servizio.

Prova a utilizzare una libreria OAuth fornita da Google per assicurarti che il JWT sia generato correttamente.

invalid_scope Invalid OAuth scope or ID token audience provided. Non sono stati richiesti ambiti (elenco vuoto di ambiti) oppure uno degli ambiti richiesti non esiste (ovvero non è valido).

Assicurarsi che il scope pretesa (campo) della JWT è popolato, e confrontare gli scopi che esso contiene con gli ambiti documentate per le API che si desidera utilizzare, per assicurarsi che non ci siano errori o refusi.

Si noti che l'elenco degli ambiti in scope esigenze sostengono di essere separati da spazi, non da virgole.

disabled_client The OAuth client was disabled. La chiave utilizzata per firmare l'asserzione JWT è disabilitata.

Vai alla Google API Console, e sotto IAM e Amministrazione> Account di servizio, abilitare l'account di servizio che contiene il "Key ID" utilizzata per firmare l'asserzione.

Addendum: autorizzazione dell'account di servizio senza OAuth

Con alcune API di Google, puoi effettuare chiamate API autorizzate utilizzando un JWT firmato direttamente come token di connessione, anziché un token di accesso OAuth 2.0. Quando ciò è possibile, puoi evitare di dover effettuare una richiesta di rete al server di autorizzazione di Google prima di effettuare una chiamata API.

Se l'API che si desidera chiamare ha una definizione di servizio pubblicato sulla repository di Google API GitHub , è possibile effettuare chiamate API autorizzati utilizzando un JWT, invece di un token di accesso. Fare così:

  1. Creare un account di servizio come descritto sopra. Assicurati di conservare il file JSON che ottieni quando crei l'account.
  2. L'utilizzo di qualsiasi libreria JWT standard, come quella che si trova a jwt.io , creare un JWT con un colpo di testa e payload come il seguente esempio:
    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "abcdef1234567890"
    }
    .
    {
      "iss": "123456-compute@developer.gserviceaccount.com",
      "sub": "123456-compute@developer.gserviceaccount.com",
      "aud": "https://firestore.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600
    }
    • Per il kid campo nell'intestazione, specificare il vostro account di servizio ID chiave privata. È possibile trovare questo valore nel private_key_id campo del vostro file dell'account JSON servizio.
    • Per i iss e sub campi, specificare l'indirizzo e-mail del tuo account di servizio. È possibile trovare questo valore nel client_email campo del vostro file dell'account JSON servizio.
    • Per l' aud campo, specificare il punto finale API. Ad esempio: https:// SERVICE .googleapis.com/ .
    • Per iat campo, specificare l'ora corrente di Unix, e per exp campo, specificare il tempo di esattamente 3.600 secondi più tardi, quando il JWT scadrà.

Firma il JWT con RSA-256 utilizzando la chiave privata che si trova nel file JSON dell'account di servizio.

Per esempio:

Giava

Utilizzando google-api-java-client e java-JWT :

GoogleCredential credential =
        GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = credential.getServiceAccountPrivateKey();
String privateKeyId = credential.getServiceAccountPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("123456-compute@developer.gserviceaccount.com")
        .withSubject("123456-compute@developer.gserviceaccount.com")
        .withAudience("https://firestore.googleapis.com/")
        .withIssuedAt(new Date(now))
        .withExpiresAt(new Date(now + 3600 * 1000L))
        .sign(algorithm);
} catch ...

Pitone

Utilizzando PyJWT :

iat = time.time()
exp = iat + 3600
payload = {'iss': '123456-compute@developer.gserviceaccount.com',
           'sub': '123456-compute@developer.gserviceaccount.com',
           'aud': 'https://firestore.googleapis.com/',
           'iat': iat,
           'exp': exp}
additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}
signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers,
                       algorithm='RS256')
  1. Chiamare l'API, utilizzando la JWT firmato come portatrice token:
    GET /v1/projects/abc/databases/123/indexes HTTP/1.1
    Authorization: Bearer SIGNED_JWT
    Host: firestore.googleapis.com