Utilisation d'OAuth 2.0 pour les applications de serveur à serveur

Le système Google OAuth 2.0 prend en charge les interactions de serveur à serveur telles que celles entre une application Web et un service Google. Pour ce scénario , vous avez besoin d' un compte de service, qui est un compte qui appartient à votre application au lieu de l'utilisateur final individuel. Votre application appelle les API Google au nom du compte de service, de sorte que les utilisateurs ne sont pas directement impliqués. Ce scénario est parfois appelé « OAuth à deux étapes » ou « 2LO ». (Le terme connexe « OAuth à trois étapes » fait référence à des scénarios dans lesquels votre application appelle les API Google au nom des utilisateurs finaux, et dans lesquels le consentement de l'utilisateur est parfois requis.)

En règle générale, une application utilise un compte de service lorsque l'application utilise les API Google pour travailler avec ses propres données plutôt qu'avec les données d'un utilisateur. Par exemple, une application qui utilise Google Cloud Datastore pour la persistance des données utiliserait un compte de service pour authentifier ses appels à l'API Google Cloud Datastore.

Les administrateurs de domaine Google Espace de travail peut également donner un service comptes autorité de domaine à l' échelle des données utilisateur d'accès au nom des utilisateurs dans le domaine.

Ce document décrit comment une application peut effectuer le flux OAuth 2.0 de serveur à serveur à l'aide d'une bibliothèque cliente d'API Google (recommandé) ou de HTTP.

Aperçu

Pour prendre en charge les interactions serveur-à-serveur, créez un compte de service pour votre projet dans le API Console. Si vous souhaitez accéder aux données utilisateur des utilisateurs de votre compte Google Workspace, déléguez l'accès à l'échelle du domaine au compte de service.

Ensuite, votre application se prépare à effectuer des appels d'API autorisés en utilisant les informations d'identification du compte de service pour demander un jeton d'accès au serveur d'authentification OAuth 2.0.

Enfin, votre application peut utiliser le jeton d'accès pour appeler les API Google.

Création d'un compte de service

Les informations d'identification d'un compte de service incluent une adresse e-mail générée qui est unique et au moins une paire de clés publique/privée. Si la délégation à l'échelle du domaine est activée, un ID client fait également partie des informations d'identification du compte de service.

Si votre application s'exécute sur Google App Engine, un compte de service est configuré automatiquement lorsque vous créez votre projet.

Si votre application s'exécute sur Google Compute Engine, un compte de service est également configuré automatiquement lorsque vous créez votre projet, mais vous devez spécifier les champs d'application auxquels votre application doit accéder lorsque vous créez une instance Google Compute Engine. Pour plus d' informations, consultez la section Préparation d' une instance à l' utilisation des comptes de service .

Si votre application ne fonctionne pas sur Google App Engine ou Google Compute Engine, vous devez obtenir ces informations d' identification dans le Google API Console. Pour générer des informations d'identification de compte de service ou pour afficher les informations d'identification publiques que vous avez déjà générées, procédez comme suit :

Tout d'abord, créez un compte de service :

  1. Ouvrez le Service accounts page.
  2. If prompted, select a project, or create a new one.
  3. Cliquez sur Créer compte de service.
  4. Sous les détails du compte de service, saisissez un nom, ID, et une description pour le compte de service, puis cliquez sur Créer et continuer.
  5. Facultatif: Dans le cadre Accorde compte un service d' accès au projet, sélectionnez les rôles IAM pour accorder au compte de service.
  6. Cliquez sur Continuer.
  7. En option: Les utilisateurs de moins autoriser l' accès à ce compte de service, ajoutez les utilisateurs ou les groupes qui sont autorisés à utiliser et à gérer le compte de service.
  8. Cliquez sur Terminé.
  9. Cliquez sur Créer clé, puis cliquez sur Créer.

Ensuite, créez une clé de compte de service :

  1. Cliquez sur l'adresse e-mail du compte de service que vous avez créé.
  2. Cliquez sur l'onglet Clés.
  3. Dans la liste déroulante touche Ajouter, sélectionnez Créer une nouvelle clé.
  4. Cliquez sur Créer.

Votre nouvelle paire de clés publique/privée est générée et téléchargée sur votre machine ; elle sert de seule copie de la clé privée. Vous êtes responsable de le stocker en toute sécurité. Si vous perdez cette paire de clés, vous devrez en générer une nouvelle.

Vous pouvez revenir à la API Console à tout moment pour voir l'adresse e - mail, les empreintes digitales de clé publique et d' autres informations, ou pour générer des paires supplémentaires clés publiques / privées. Pour plus de détails sur les informations d' identification de compte de service dans le API Console, voir Comptes de API Consoleservice dans le API Consolefichier d'aide.

Notez l'adresse e-mail du compte de service et stockez le fichier de clé privée du compte de service dans un emplacement accessible à votre application. Votre application en a besoin pour effectuer des appels d'API autorisés.

Déléguer l'autorité à l'échelle du domaine au compte de service

Si vous disposez d'un compte Google Workspace, un administrateur de l'organisation peut autoriser une application à accéder aux données utilisateur au nom des utilisateurs du domaine Google Workspace. Par exemple, une application qui utilise l'API Google Calendar pour ajouter des événements aux calendriers de tous les utilisateurs d'un domaine Google Workspace utiliserait un compte de service pour accéder à l'API Google Calendar au nom des utilisateurs. Autoriser un compte de service à accéder aux données au nom des utilisateurs d'un domaine est parfois appelé « déléguer l'autorité à l'échelle du domaine » à un compte de service.

Pour déléguer l'autorité à l'échelle du domaine à un compte de service, un super-administrateur du domaine Google Workspace doit effectuer les étapes suivantes :

  1. A partir de votre espace de travail de domaine Google console d' administration , accédez au menu principal > Sécurité> Contrôles de l' API.
  2. Dans le volet de large délégation de domaine, sélectionnez Gérer Délégation large domaine.
  3. Cliquez sur Ajouter.
  4. Dans le champ ID client, entrez l'ID client du compte de service. Vous pouvez trouver votre client de compte de service ID dans le Service accounts page.
  5. Dans le champ champs OAuth (délimité par des virgules), entrez la liste des champs que votre demande devrait être accordée à l' accès. Par exemple, si votre application a besoin d' accéder au niveau du domaine complet à l'API Google Drive et l'API Google Agenda, entrez: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth calendrier /.
  6. Cliquez sur Autoriser.

Votre application est désormais autorisée à effectuer des appels d'API en tant qu'utilisateurs de votre domaine (pour « usurper l'identité » des utilisateurs). Lorsque vous vous préparez à effectuer des appels d'API autorisés, vous spécifiez l'utilisateur à emprunter.

Se préparer à passer un appel API autorisé

Java

Après avoir obtenu l'adresse e - mail du client et la clé privée de la API Console, utilisez l' API Google Client Library pour Java pour créer un GoogleCredential objet à partir des informations d' identification du compte de service et les champs d' application de votre application a besoin d' accéder. Par exemple:

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

Si vous développez une application sur Google Cloud Platform, vous pouvez utiliser les informations d' identification par défaut de l' application à la place, ce qui peut simplifier le processus.

Déléguer l'autorité à l'échelle du domaine

Si vous avez délégué accès au domaine à l' échelle pour le compte de service et que vous voulez usurper l' identité d' un compte d'utilisateur, indiquez l'adresse e - mail du compte utilisateur avec la createDelegated méthode de l' GoogleCredential objet. Par exemple:

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

Utilisez le GoogleCredential objet pour appeler des API Google dans votre application.

Python

Après avoir obtenu l'adresse e - mail du client et la clé privée de la API Console, utilisez l' API Google Client Library pour Python pour compléter les étapes suivantes:

  1. Créer une Credentials des Credentials objet à partir des informations d' identification du compte de service et les champs d' application de votre application a besoin d' accéder. Par exemple:
    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)

    Si vous développez une application sur Google Cloud Platform, vous pouvez utiliser les informations d' identification par défaut de l' application à la place, ce qui peut simplifier le processus.

  2. Déléguer l'autorité à l'échelle du domaine

    Si vous avez délégué accès au domaine à l' échelle pour le compte de service et que vous voulez usurper l' identité d' un compte d'utilisateur, utilisez la with_subject méthode existante d'un ServiceAccountCredentials objet. Par exemple:

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

Utilisez l'objet Credentials pour appeler les API Google dans votre application.

HTTP/REST

Après avoir obtenu l'ID client et la clé privée de la API Console, votre application doit effectuer les étapes suivantes:

  1. Créez un jeton Web JSON (JWT, prononcé, "jot") qui comprend un en-tête, un ensemble de revendications et une signature.
  2. Demandez un jeton d'accès au serveur d'autorisation Google OAuth 2.0.
  3. Gérez la réponse JSON renvoyée par le serveur d'autorisation.

Les sections qui suivent décrivent comment effectuer ces étapes.

Si la réponse comprend un jeton d'accès, vous pouvez utiliser l'jeton d' accès pour appeler une API Google . (Si la réponse n'inclut pas de jeton d'accès, votre demande JWT et de jeton peut ne pas être correctement formée, ou le compte de service peut ne pas avoir l'autorisation d'accéder aux étendues demandées.)

Lorsque le jeton d'accès expire , votre application génère une autre JWT, le signe, et demande un autre jeton d'accès.

Votre application serveur utilise un jeton JWT pour demander un jeton au serveur d'autorisation Google, puis utilise le jeton pour appeler un point de terminaison d'API Google. Aucun utilisateur final n'est impliqué.

Le reste de cette section décrit les spécificités de la création d'un JWT, de la signature du JWT, de la formation de la demande de jeton d'accès et de la gestion de la réponse.

Création d'un JWT

Un JWT est composé de trois parties : un en-tête, un ensemble de revendications et une signature. L'en-tête et l'ensemble de revendications sont des objets JSON. Ces objets JSON sont sérialisés en octets UTF-8, puis encodés à l'aide de l'encodage Base64url. Ce codage offre une résilience contre les modifications de codage dues à des opérations de codage répétées. L' en- tête, appareil de la revendication, et la signature sont concaténés avec une période ( . De caractères).

Un JWT est composé comme suit :

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

La chaîne de base de la signature est la suivante :

{Base64url encoded header}.{Base64url encoded claim set}
Former l'en-tête JWT

L'en-tête se compose de deux champs qui indiquent l'algorithme de signature et le format de l'assertion. Les deux champs sont obligatoires et chaque champ n'a qu'une seule valeur. Au fur et à mesure de l'introduction d'algorithmes et de formats supplémentaires, cet en-tête changera en conséquence.

Les comptes de service reposent sur l'algorithme RSA SHA-256 et le format de jeton JWT. Par conséquent, la représentation JSON de l'en-tête est la suivante :

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

La représentation Base64url de ceci est la suivante :

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
Former l'ensemble de revendications JWT

L'ensemble de revendications JWT contient des informations sur le JWT, y compris les autorisations demandées (étendues), la cible du jeton, l'émetteur, l'heure à laquelle le jeton a été émis et la durée de vie du jeton. La plupart des champs sont obligatoires. Comme l'en-tête JWT, l'ensemble de revendications JWT est un objet JSON et est utilisé dans le calcul de la signature.

Allégations requises

Les revendications requises dans l'ensemble de revendications JWT sont indiquées ci-dessous. Ils peuvent apparaître dans n'importe quel ordre dans l'ensemble de revendications.

Nom La description
iss L'adresse e-mail du compte de service.
scope Une liste délimitée par des espaces des autorisations demandées par l'application.
aud Descripteur de la cible prévue de l'assertion. Lorsque vous effectuez une demande de jeton d'accès cette valeur est toujours https://oauth2.googleapis.com/token .
exp L'heure d'expiration de l'assertion, spécifiée en secondes depuis 00:00:00 UTC, le 1er janvier 1970. Cette valeur a un maximum de 1 heure après l'heure émise.
iat L'heure à laquelle l'assertion a été émise, spécifiée en secondes depuis 00:00:00 UTC, le 1er janvier 1970.

La représentation JSON des champs obligatoires dans un ensemble de revendications JWT est illustrée ci-dessous :

{
  "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
}
Réclamations supplémentaires

Dans certains cas d'entreprise, une application peut utiliser la délégation à l'échelle du domaine pour agir au nom d'un utilisateur particulier dans une organisation. L'autorisation d'effectuer ce type d'emprunt d'identité doit être accordée avant qu'une application puisse emprunter l'identité d'un utilisateur et est généralement gérée par un super administrateur. Pour plus d' informations, consultez l' accès aux API de contrôle avec la délégation de domaine à l' échelle .

Pour obtenir un jeton d' accès qui attribue une demande de déléguer l' accès à une ressource, y compris l'adresse e - mail de l'utilisateur dans l'ensemble de revendication JWT que la valeur du sub - champ.

Nom La description
sub L'adresse e-mail de l'utilisateur pour lequel l'application demande un accès délégué.

Si une application n'a pas l' autorisation d'usurper l' identité d' un utilisateur, la réponse à une demande de jeton d'accès qui inclut le sub champ sera une erreur .

Un exemple d'un ensemble de la revendication JWT qui comprend le sub - domaine est illustré ci - dessous:

{
  "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
}
Encodage de l'ensemble de revendications JWT

Comme l'en-tête JWT, l'ensemble de revendications JWT doit être sérialisé en UTF-8 et codé en Base64url. Vous trouverez ci-dessous un exemple de représentation JSON d'un ensemble de revendications JWT :

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

JSON Signature Web (JWS) est la spécification qui guide les mécanismes de génération de la signature pour le JWT. L'entrée pour la signature est le tableau d'octets du contenu suivant :

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

L'algorithme de signature dans l'en-tête JWT doit être utilisé lors du calcul de la signature. Le seul algorithme de signature pris en charge par le serveur d'autorisation Google OAuth 2.0 est RSA utilisant l'algorithme de hachage SHA-256. Ceci est exprimé en RS256 dans le alg champ dans l' en- tête de JWT.

Signer la représentation UTF-8 sur l'entrée en utilisant SHA256withRSA (également connu sous le nom RSASSA-PKCS1-v1_5-SIGN avec la fonction de hachage SHA-256) avec la clé privée obtenue à partir du Google API Console. La sortie sera un tableau d'octets.

La signature doit alors être encodée en Base64url. L' en- tête, appareil de la revendication, et la signature sont concaténés avec une période ( . De caractères). Le résultat est le JWT. Il devrait être le suivant (sauts de ligne ajoutés pour plus de clarté) :

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

Vous trouverez ci-dessous un exemple de JWT avant l'encodage 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]

Vous trouverez ci-dessous un exemple de JWT qui a été signé et est prêt à être transmis :

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

Faire la demande de jeton d'accès

Après avoir généré le JWT signé, une application peut l'utiliser pour demander un jeton d'accès. Ce jeton d' accès demande est un HTTPS POST demande, et le corps est codé URL. L'URL est indiquée ci-dessous :

https://oauth2.googleapis.com/token

Les paramètres suivants sont requis dans le protocole HTTPS POST demande:

Nom La description
grant_type Utilisez la chaîne suivante, codé URL si nécessaire: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion Le JWT, y compris la signature.

Ci - dessous une décharge brute du protocole HTTPS POST demande utilisé dans un jeton d' accès demande:

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

Voici la même demande, en utilisant 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

Gérer la réponse

Si le JWT et la demande de jeton d'accès sont correctement formés et que le compte de service est autorisé à effectuer l'opération, la réponse JSON du serveur d'autorisation inclut un jeton d'accès. Voici un exemple de réponse :

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

Les jetons d'accès peuvent être réutilisés pendant la fenêtre de durée déterminée par la expires_in valeur.

Appel des API Google

Java

Utilisez le GoogleCredential objet pour appeler les API Google en suivant les étapes suivantes:

  1. Créer un objet de service pour l'API que vous souhaitez appeler en utilisant le GoogleCredential objet. Par exemple:
    SQLAdmin sqladmin =
        new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
  2. Faire des demandes au service de l' API en utilisant l' interface fournie par l'objet de service . Par exemple, pour lister les instances de bases de données Cloud SQL dans le projet passionnant exemple-123:
    SQLAdmin.Instances.List instances =
        sqladmin.instances().list("exciting-example-123").execute();

Python

Utilisez les autorisés Credentials d' Credentials d' objet pour appeler les API Google en suivant les étapes suivantes:

  1. Créez un objet de service pour l'API que vous souhaitez appeler. Vous construisez aa objet de service en appelant la build fonction avec le nom et la version de l'API et l'autorisation de Credentials des Credentials objet. Par exemple, pour appeler la version 1beta3 de l'API d' administration Cloud SQL:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. Faire des demandes au service de l' API en utilisant l' interface fournie par l'objet de service . Par exemple, pour lister les instances de bases de données Cloud SQL dans le projet passionnant exemple-123:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

HTTP/REST

Une fois que votre application a obtenu un jeton d'accès, vous pouvez utiliser le jeton pour passer des appels à une API Google au nom d'un compte de service ou d'un compte utilisateur donné si la ou les étendues d'accès requises par l'API ont été accordées. Pour ce faire, ajoutez le jeton d' accès dans une requête à l'API en incluant soit un access_token paramètre de requête ou une Authorization en- tête HTTP Bearer valeur. Lorsque cela est possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas , vous pouvez utiliser une bibliothèque client pour configurer vos appels aux API Google (par exemple, lorsque l' appel de l'API des fichiers Drive ).

Vous pouvez essayer toutes les API Google et consulter leurs champs d' application au OAuth 2.0 Playground .

Exemples HTTP GET

Un appel au drive.files point final (l'API des fichiers Drive) en utilisant l' Authorization: Bearer - tête HTTP pourrait ressembler à ce qui suit. Notez que vous devez spécifier votre propre jeton d'accès :

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

Voici un appel à la même API pour l'utilisateur authentifié à l' aide du access_token paramètre de chaîne de requête:

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

curl exemples

Vous pouvez tester ces commandes avec la curl l' application en ligne de commande. Voici un exemple qui utilise l'option d'en-tête HTTP (de préférence) :

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

Ou, alternativement, l'option de paramètre de chaîne de requête :

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

Quand les jetons d'accès expirent

Accès jetons émis par l'autorisation Google OAuth 2.0 serveur expire après la durée prévue par la expires_in valeur. Lorsqu'un jeton d'accès expire, l'application doit générer un autre jeton JWT, le signer et demander un autre jeton d'accès.

Codes d'erreur JWT

error domaine error_description champ Sens Comment résoudre
unauthorized_client Unauthorized client or scope in request. Si vous essayez d'utiliser la délégation à l'échelle du domaine, le compte de service n'est pas autorisé dans la console d'administration du domaine de l'utilisateur.

Assurez -vous que le compte de service est autorisé dans la délégation du sub domaine à l' échelle page de la console d' administration pour l'utilisateur dans la sub réclamation (champ).

Bien que cela prenne généralement quelques minutes, l'autorisation peut prendre jusqu'à 24 heures pour se propager à tous les utilisateurs de votre compte Google.

unauthorized_client Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. Un compte de service a été autorisé à l'aide de l'adresse e-mail du client plutôt que de l'ID client (numérique) dans la console d'administration. Dans la délégation du domaine à l' échelle page dans la console d'administration, retirez le client, et ajouter de nouveau avec l'ID numérique.
access_denied (de n'importe quelle valeur) Si vous utilisez la délégation à l'échelle du domaine, un ou plusieurs champs d'application demandés ne sont pas autorisés dans la console d'administration.

Assurez -vous que le compte de service est autorisé dans la délégation du sub scope domaine à l' échelle page de la console d' administration pour l'utilisateur dans la sub réclamation (champ), et qu'il comprend tous les vous étendues vous demandez dans le scope réclamation de votre JWT.

Bien que cela prenne généralement quelques minutes, l'autorisation peut prendre jusqu'à 24 heures pour se propager à tous les utilisateurs de votre compte Google.

invalid_grant Not a valid email. L'utilisateur n'existe pas. Vérifiez que l'adresse e - mail dans la sub réclamation (champ) est correct.
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.

Habituellement, cela signifie que l'heure système locale n'est pas correcte. Il pourrait également se produire si l' exp valeur est plus de 65 minutes à l'avenir de la iat valeur, ou l' exp valeur est inférieure à iat valeur.

Assurez-vous que l'horloge du système sur lequel le JWT est généré est correcte. Si nécessaire, synchroniser votre temps avec Google NTP .

invalid_grant Invalid JWT Signature.

L'assertion JWT est signée avec une clé privée non associée au compte de service identifié par l'e-mail du client ou la clé qui a été utilisée a été supprimée, désactivée ou a expiré.

Alternativement, l'assertion JWT peut être encodée de manière incorrecte - elle doit être encodée en Base64, sans saut de ligne ni signe égal de remplissage.

Décodez l'ensemble de revendications JWT et vérifiez que la clé qui a signé l'assertion est associée au compte de service.

Essayez d'utiliser une bibliothèque OAuth fournie par Google pour vous assurer que le JWT est généré correctement.

invalid_scope Invalid OAuth scope or ID token audience provided. Aucune étendue n'a été demandée (liste d'étendues vide) ou l'une des étendues demandées n'existe pas (c'est-à-dire qu'elle n'est pas valide).

Assurez -vous que la scope réclamation (champ) du JWT est peuplé, et de comparer les champs qu'il contient les champs documentés pour les API que vous souhaitez utiliser, pour assurer qu'il n'y a pas d' erreurs ou fautes de frappe.

Notez que la liste des champs d' application dans le scope des besoins de demande à être séparés par des espaces, non par des virgules.

disabled_client The OAuth client was disabled. La clé utilisée pour signer l'assertion JWT est désactivée.

Aller à la Google API Console, et sous IAM & Administration> Comptes de service, activer le compte de service qui contient le « ID de clé » utilisé pour signer l'affirmation.

Addendum : autorisation de compte de service sans OAuth

Avec certaines API Google, vous pouvez effectuer des appels d'API autorisés en utilisant un JWT signé directement comme jeton de support, plutôt qu'un jeton d'accès OAuth 2.0. Lorsque cela est possible, vous pouvez éviter d'avoir à faire une requête réseau au serveur d'autorisation de Google avant de faire un appel d'API.

Si l'API que vous voulez appeler a une définition de service publiée dans le référentiel des API Google GitHub , vous pouvez effectuer des appels API autorisés en utilisant un JWT au lieu d'un jeton d'accès. Faire cela:

  1. Créer un compte de service tel que décrit ci - dessus. Assurez-vous de conserver le fichier JSON que vous obtenez lorsque vous créez le compte.
  2. L' utilisation d' une bibliothèque de JWT standard, comme celle qui se trouve à jwt.io , créez un JWT avec un en- tête et la charge utile à l'exemple suivant:
    {
      "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
    }
    • Pour l' kid champ dans l' en- tête, spécifiez la clé privée de votre compte de service ID. Vous pouvez trouver cette valeur dans le private_key_id domaine de votre compte de service fichier JSON.
    • Pour les iss et sub champs, indiquez l'adresse e - mail de votre compte de service. Vous pouvez trouver cette valeur dans le client_email domaine de votre compte de service fichier JSON.
    • Pour le aud champ, spécifiez le point final de l' API. Par exemple: https:// SERVICE .googleapis.com/ .
    • Pour le iat , spécifiez le temps Unix en cours et pour l' exp , spécifiez le temps exactement 3600 secondes plus tard, lorsque le JWT expirera.

Signez le JWT avec RSA-256 à l'aide de la clé privée trouvée dans le fichier JSON de votre compte de service.

Par exemple:

Java

En utilisant google-api-java-client et 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 ...

Python

En utilisant 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. Appelez l'API, en utilisant l'JWT signé comme le jeton porteur:
    GET /v1/projects/abc/databases/123/indexes HTTP/1.1
    Authorization: Bearer SIGNED_JWT
    Host: firestore.googleapis.com