Cette page a été traduite par l'API Cloud Translation.

Utiliser OAuth 2.0 pour l'authentification serveur à serveur

Le système Google OAuth 2.0 prend en charge les interactions de serveur à serveur, comme celles entre et un service Google. Dans ce scénario, vous avez besoin d'un compte de service, est un compte qui appartient à votre application et non à un utilisateur final individuel. Votre appelle des API Google au nom du compte de service. Par conséquent, les utilisateurs ne sont pas directement impliqués. Ce scénario est parfois appelé "OAuth à deux acteurs", ou « 2LO ». (Le terme associé "OAuth en trois étapes" fait référence aux scénarios dans lesquels votre application appelle des API Google des utilisateurs finaux, et pour lesquels leur consentement est parfois requis.)

Généralement, une application utilise un compte de service lorsqu'elle utilise les API Google pour fonctionner avec ses propres données plutôt que celles d'un utilisateur. Par exemple, une application qui utilise Google Cloud Datastore pour la persistance des données utilise un compte de service pour authentifier ses appels à API Google Cloud Datastore.

Les administrateurs de domaine Google Workspace peuvent également accorder aux comptes de service l'autorité au niveau du domaine d'accéder aux utilisateurs pour le compte des utilisateurs du domaine.

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

Présentation

Pour prendre en charge les interactions de serveur à serveur, commencez par créer 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, puis déléguez l'accès au compte de service au niveau du domaine.

Ensuite, votre application se prépare à effectuer des appels d'API autorisés à l'aide de l'API 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éer un compte de service

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

Si votre application s'exécute sur Google App Engine, un compte de service est automatiquement configuré 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 niveaux d'accès application a besoin d'accéder lorsque vous créez une instance Google Compute Engine. Pour plus pour en savoir plus, consultez Préparez une instance à utiliser des comptes de service.

Si votre application ne s'exécute pas sur Google App Engine ou Google Compute Engine, vous devez obtenir ces identifiants dans Google API Console. Générer un compte de service identifiants ou pour afficher les identifiants publics que vous avez déjà générés, procédez comme suit:

首先，创建一个服务帐户：

打开 Service accounts page。
If prompted, select a project, or create a new one.
单击创建服务帐户。
在Service account details下，键入服务帐户的名称、ID 和描述，然后点击Create and continue 。
可选：在Grant this service account access to project下，选择要授予服务帐户的 IAM 角色。
单击继续。
可选：在Grant users access to this service account下，添加允许使用和管理服务帐户的用户或组。
单击完成。

接下来，创建一个服务帐户密钥：

单击您创建的服务帐户的电子邮件地址。
单击密钥选项卡。
在添加密钥下拉列表中，选择创建新密钥。
单击创建。

您的新公钥/私钥对已生成并下载到您的机器上；它作为私钥的唯一副本。您有责任安全地存储它。如果您丢失了这个密钥对，您将需要生成一个新的。

Vous pouvez revenir au API Console à tout moment pour afficher l'adresse e-mail, publique des empreintes de clé et d'autres informations, ou pour générer des paires de clés publiques/privées supplémentaires. Pour pour en savoir plus sur les identifiants du compte de service API Console, consultez Comptes de service dans la région API Console fichier d'aide.

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

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

Avec un compte Google Workspace, un administrateur Workspace de l'organisation peut autoriser un d'accéder aux données utilisateur Workspace pour le compte des utilisateurs du domaine Google Workspace. Par exemple : Une application qui utilise l'API Google Calendar pour ajouter des événements aux agendas de tous les utilisateurs de un domaine Google Workspace utilise un compte de service pour accéder à l'API Google Calendar sur pour le compte des utilisateurs. Autoriser un compte de service à accéder aux données au nom des utilisateurs d'un domaine parfois appelée "délégation de l'autorité au niveau du domaine" à un compte de service.

Pour déléguer l'autorité au niveau du domaine à un compte de service, un super-administrateur du compte Pour le domaine Workspace, procédez comme suit:

À partir du de votre domaine Google Workspace Console d'administration, accédez au Menu principal > Sécurité > Contrôle des accès et des données > Commandes des API.
Dans le volet Délégation au niveau du domaine, sélectionnez Gérer la délégation au niveau du domaine.
Cliquez sur Ajouter.
Dans le champ ID client, saisissez l'ID client du compte de service. Vous trouverez l'ID client de votre compte de service Service accounts page
Dans le champ Champs d'application OAuth (séparés par une virgule), saisissez la liste des champs d'application l'accès doit être accordé à l'application. Par exemple, si votre application nécessite des requêtes un accès complet à l'API Google Drive et à l'API Google Calendar, saisissez: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar
Cliquez sur Autoriser.

Votre application est désormais autorisée à effectuer des appels d'API en tant qu'utilisateurs de votre domaine Workspace "emprunter l'identité" utilisateurs). Lorsque vous vous préparerez à effectuer ces appels d'API délégués, vous indiquerez explicitement à l'utilisateur usurpent l'identité.

Préparer un appel d'API délégué

Java

Après avoir obtenu l'adresse e-mail du client et la clé privée à partir du API Console, utilisez le Bibliothèque cliente des API Google pour Java pour créer un objet GoogleCredential à partir des identifiants du compte de service et les champs d'application auxquels votre application a besoin d'accéder. 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 le identifiants par défaut de l'application ce qui peut simplifier le processus.

Déléguer l'autorité au niveau du domaine

Si vous avez délégué l'accès au compte de service au niveau du domaine et que vous souhaitez emprunter l'identité un compte d'utilisateur, spécifiez son adresse e-mail avec le Méthode createDelegated de l'objet GoogleCredential. Par exemple :

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

Le code ci-dessus utilise l'objet GoogleCredential pour appeler sa fonction createDelegated(). . L'argument de la méthode createDelegated() doit être un utilisateur appartenant à votre Workspace. Le code effectuant la requête utilisera cet identifiant pour appeler Google à l'aide de votre compte de service.

Python

Après avoir obtenu l'adresse e-mail du client et la clé privée à partir du API Console, utilisez le Bibliothèque cliente des API Google pour Python pour effectuer les étapes suivantes:

Créez un objet Credentials à partir des identifiants du compte de service et du auxquels 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 le identifiants par défaut de l'application ce qui peut simplifier le processus.
Déléguer l'autorité au niveau du domaine
Si vous avez délégué l'accès au compte de service au niveau du domaine et que vous souhaitez emprunter l'identité d'un compte utilisateur, utilisez la méthode with_subject d'un ServiceAccountCredentials. 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 API Console, votre application doit effectuer la en suivant les étapes ci-dessous:

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

Les sections suivantes décrivent comment effectuer ces étapes.

Si la réponse inclut un jeton d'accès, vous pouvez l'utiliser pour d'appeler une API Google. (Si la réponse n'inclut pas d'autorisation votre requête de jeton JWT et de jeton n'est peut-être pas correctement formée, ou le compte de service peut ne dispose pas des autorisations nécessaires pour accéder aux champs d'application demandés.)

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 de serveur utilise un jeton JWT pour demander un jeton au serveur
le serveur d'autorisation, puis utilise le jeton pour appeler un point de terminaison de l'API Google. Non
l’utilisateur final
est impliqué.

Le reste de cette section décrit les spécificités de la création et de la signature d'un jeton JWT, formant la requête de jeton d'accès et en gérant la réponse.

Créer un jeton JWT

Un jeton JWT est composé de trois parties: un en-tête, un ensemble de revendications signature. L'en-tête et l'ensemble de revendications sont des objets JSON. Ces objets JSON sont sérialisés Octets UTF-8, puis encodés en Base64url. Cet encodage assure la résilience contre les changements d'encodage dus à des opérations d'encodage répétées. L'en-tête, l'ensemble de revendications sont concaténées avec un point (.).

Un jeton 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}

Créer l'en-tête JWT

L'en-tête se compose de trois champs qui indiquent l'algorithme de signature, au format l'assertion et l'[ID de clé du compte de service key](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) utilisé pour signer le jeton JWT. L'algorithme et le format sont obligatoires, et chaque champ ne contient une valeur. À mesure que d'autres algorithmes et formats seront ajoutés, cet en-tête changera en conséquence. L'ID de clé est facultatif. Si un ID de clé incorrect est spécifié, GCP essaiera toutes les clés associées au compte de service pour vérifier le jeton et le rejeter si Aucune clé valide n'a été trouvée. Google se réserve le droit de rejeter les jetons dont l'ID de clé est incorrect. à l'avenir.

Les comptes de service s'appuient 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", "kid":"370ab79b4513eb9bad7c9bd16a95cb76b5b2a56a"}

Voici la représentation en Base64url:

          eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

Créer l'ensemble de revendications JWT

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

Revendications requises

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

Nom	Description
`iss`	Adresse e-mail du compte de service.
`scope`	Liste des autorisations demandées par l'application, séparées par un espace.
`aud`	Descripteur de la cible visée de l'assertion. Lors de la création d'un jeton d'accès requête, cette valeur est toujours `https://oauth2.googleapis.com/token`.
`exp`	Heure d'expiration de l'assertion, spécifiée en secondes depuis 00:00:00 UTC 1er janvier 1970. Cette valeur est postérieure d'une heure au maximum à l'heure d'émission.
`iat`	Heure d'émission de l'assertion, spécifiée en secondes depuis 00:00:00 UTC. 1er janvier 1970.

La représentation JSON des champs obligatoires dans un ensemble de revendications JWT est présenté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
}

Revendications supplémentaires

Dans certains cas d'entreprise, une application peut utiliser la délégation au niveau du domaine pour agir en son nom d'un utilisateur particulier dans une organisation. Autorisation d'effectuer ce type d'usurpation d'identité doit être accordée pour qu'une application puisse emprunter l'identité d'un utilisateur. Cette règle est généralement gérée super-administrateur. Pour en savoir plus, consultez Contrôlez l'accès à l'API à l'aide de la délégation au niveau du domaine.

Pour obtenir un jeton d'accès qui accorde à une application un accès délégué à une ressource, incluez l'adresse e-mail de l'utilisateur dans l'ensemble de revendications JWT comme valeur du paramètre sub.

Nom	Description
`sub`	Adresse e-mail de l'utilisateur pour lequel l'application demande la délégation y accéder.

Si une application n'est pas autorisée à usurper l'identité d'un utilisateur, la réponse à une une requête de jeton d'accès incluant le champ sub est une erreur.

Voici un exemple d'ensemble de revendications JWT incluant le champ sub. 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
}

Encoder l'ensemble de revendications JWT

Tout comme l'en-tête JWT, l'ensemble de revendications JWT doit être sérialisé au format UTF-8 et compatible avec Base64url. ou encore encodée. 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
}

Calculer la signature

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

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

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

Signez la représentation UTF-8 de l'entrée à l'aide de SHA256withRSA (également appelé RSASSA-PKCS1-V1_5-SIGN avec la fonction de hachage SHA-256) par la clé privée obtenue à partir de le Google API Console. La sortie est un tableau d'octets.

La signature doit ensuite être encodée au format Base64url. L'en-tête, l'ensemble de revendications et la signature concaténés avec un point (.). Le résultat est le JWT. Il doivent être les suivants (des sauts de ligne ont été ajoutés pour plus de clarté):

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

Vous trouverez ci-dessous un exemple de jeton 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 jeton JWT signé et prêt à être transmis:

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

Envoyer la requête de jeton d'accès

Après avoir généré le jeton JWT signé, une application peut l'utiliser pour demander un jeton d'accès. Cette requête de jeton d'accès est une requête HTTPS POST dont le corps est une URL. ou encore encodée. L'URL est la suivante:

https://oauth2.googleapis.com/token

Les paramètres suivants sont obligatoires dans la requête HTTPS POST:

Nom	Description
`grant_type`	Utilisez la chaîne suivante, encodée au format URL si nécessaire: `urn:ietf:params:oauth:grant-type:jwt-bearer`
`assertion`	Jeton JWT, y compris la signature.

Vous trouverez ci-dessous un vidage brut de la requête HTTPS POST utilisée dans un jeton d'accès. requête:

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

Vous trouverez ci-dessous la même requête 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

Traiter la réponse

Si le jeton JWT et la requête de jeton d'accès sont correctement formés et si le compte de service a l'autorisation d'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 période spécifiée par le champ Valeur expires_in.

Appeler des API Google

Java

Utilisez l'objet GoogleCredential pour appeler les API Google en exécutant la commande en suivant les étapes ci-dessous:

Créez un objet de service pour l'API que vous souhaitez appeler à l'aide de la méthode GoogleCredential. Exemple :
```
SQLAdmin sqladmin =
    new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
```
Envoyez des requêtes au service d'API à l'aide de la méthode interface fournie par l'objet de service. Par exemple, pour répertorier les instances de bases de données Cloud SQL dans la commande "excitation-example-123" projet:
```
SQLAdmin.Instances.List instances =
    sqladmin.instances().list("exciting-example-123").execute();
```

Python

Utilisez l'objet Credentials autorisé pour appeler les API Google en exécutant la commande en suivant les étapes ci-dessous:

Créez un objet de service pour l'API que vous souhaitez appeler. Vous créez un objet de service en appelant la fonction build avec le nom et la version de l'API, ainsi que objet Credentials autorisé. Par exemple, pour appeler la version 1beta3 de API Cloud SQL Administration:
```
import googleapiclient.discovery

sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
```
Envoyez des requêtes au service d'API à l'aide de la méthode interface fournie par l'objet de service. Par exemple, pour répertorier les instances de bases de données Cloud SQL dans la commande "excitation-example-123" projet:
```
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 l'utiliser pour effectuer des appels vers au nom d'un compte de service donné ou compte utilisateur si les niveaux d'accès requis par l'API ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant une requête access_token ou une valeur Bearer d'en-tête HTTP Authorization. Si 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 cliente pour configurer vos appels aux API Google (par exemple, lorsque appelez l'API Drive Files).

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

Exemples de requête HTTP GET

Un appel à la fonction drive.files (API Drive Files) via le protocole HTTP Authorization: Bearer peut se présenter comme 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 de 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 l'application de ligne de commande curl. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandé):

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

Vous pouvez également utiliser l'option de paramètre de chaîne de requête:

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

Expiration des jetons d'accès

Les jetons d'accès émis par le serveur d'autorisation Google OAuth 2.0 expirent après la durée fournies par la valeur expires_in. 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

Champ `error`	Champ `error_description`	Signification	Résoudre le problème
`unauthorized_client`	`Unauthorized client or scope in request.`	Si vous essayez d'utiliser la délégation au niveau du domaine, le compte de service n'est pas autorisé dans dans la console d'administration du domaine de l'utilisateur.	Assurez-vous que le compte de service est autorisé dans le la page "Délégation au niveau du domaine" de la console d'administration pour l'utilisateur Revendication `sub` (champ). Bien que cela ne prenne généralement que quelques minutes, l'autorisation peut prendre jusqu'à 24 heures. sont propagées à 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 section <ph type="x-smartling-placeholder"></ph> Délégation au niveau du domaine dans la console d'administration, supprimez le client, puis ajoutez-le à nouveau par l'ID numérique.
`access_denied`	(n'importe quelle valeur)	Si vous utilisez la délégation au niveau 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 le la page "Délégation au niveau du domaine" de la console d'administration pour l'utilisateur `sub` (champ) et qu'elle inclut tous les champs d'application que vous demandez dans la revendication `scope` de votre jeton JWT. Bien que cela ne prenne généralement que quelques minutes, l'autorisation peut prendre jusqu'à 24 heures. sont propagées à tous les utilisateurs de votre compte Google.
`admin_policy_enforced`	(n'importe quelle valeur)	Le compte Google n'est pas en mesure d'autoriser une ou plusieurs des habilitations demandées en raison de la de leur administrateur Google Workspace.	Consultez l'article d'aide Administrateur Google Workspace Contrôlez les enregistrements les applications internes à accéder aux données Google Workspace. peut limiter l'accès à tous les niveaux d'accès ou aux niveaux d'accès sensibles et restreints jusqu'à ce que l'accès est accordé explicitement à votre ID client OAuth.
`invalid_client`	(n'importe quelle valeur)	Le client OAuth ou le jeton JWT n'est pas valide ou n'est pas configuré correctement. Pour en savoir plus, consultez la description de l'erreur.	Assurez-vous que le jeton JWT est valide et qu'il contient des revendications correctes. Vérifiez que les client et compte de service OAuth sont configuré correctement et que vous utilisez la bonne adresse e-mail. Vérifiez que le jeton JWT est correct et qu'il a été émis pour l'ID client dans le requête.
`invalid_grant`	`Not a valid email.`	L'utilisateur n'existe pas.	Vérifiez que l'adresse e-mail indiquée dans le champ de la revendication `sub` est correcte.
`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.`	Cela signifie généralement que l'heure du système local n'est pas correcte. Cela peut également se produire si le La valeur de `exp` est postérieure de plus de 65 minutes à la valeur de `iat`, ou si la valeur `exp` est inférieure à la valeur `iat`.	Assurez-vous que l'horloge du système sur lequel le JWT est généré est correcte. Si si nécessaire, synchronisez 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'adresse e-mail du client ou la clé utilisée a été supprimée, désactivée ou a expiré. Il est également possible que l'assertion JWT ne soit pas encodée correctement. Valeur encodée en base64, sans signes égal de remplissage ou de saut de ligne.	Décodez l'ensemble de revendications JWT et vérifiez que la clé qui a signé l'assertion est associée avec le compte de service. Essayez d'utiliser une bibliothèque OAuth fournie par Google pour vous assurer que le jeton JWT est généré correctement.
`invalid_scope`	`Invalid OAuth scope or ID token audience provided.`	Aucun champ d'application n'a été demandé (liste de champs d'application vide) ou l'un des champs d'application demandés n'est pas existe (non valide).	Assurez-vous que la revendication `scope` (champ) du jeton JWT est renseignée, puis comparez les données. les champs d'application qu'il contient avec les champs d'application documentés pour les API que vous voulez utiliser, pour s'assurer qu'il n'y a pas d'erreurs ni de fautes de frappe. Notez que la liste des champs d'application dans la revendication `scope` doit être séparée par et non des virgules.
`disabled_client`	`The OAuth client was disabled.`	La clé utilisée pour signer l'assertion JWT est désactivée.	Accédez à Google API Console, puis sous IAM et Administrateur > Comptes de service, activez le compte de service qui contient l'ID de clé utilisés pour signer l'assertion.
`org_internal`	`This client is restricted to users within its organization.`	L'ID client OAuth de la requête fait partie d'un projet limitant l'accès à Google Les comptes d'un Organisation Google Cloud.	Utilisez un compte de service de l'organisation pour vous authentifier. Confirmez le type d'utilisateur la configuration de votre application OAuth.

Avenant: Autorisation de compte de service sans OAuth

Avec certaines API Google, vous pouvez effectuer des appels d'API autorisés à l'aide d'un jeton JWT signé directement en tant que et non un jeton d'accès OAuth 2.0. Lorsque cela est possible, vous pouvez éviter d'avoir d'envoyer une requête réseau au serveur d'autorisation de Google avant d'effectuer un appel d'API.

Si l'API que vous souhaitez appeler a une définition de service publiée dans le Dépôt GitHub des API Google vous pouvez effectuer des appels d'API autorisés à l'aide d'un jeton JWT au lieu d'un jeton d'accès. Procédez comme suit :

Créez un compte de service comme décrit ci-dessus. N'oubliez pas conservez le fichier JSON que vous obtenez lors de la création du compte.

Utiliser n'importe quelle bibliothèque JWT standard, telle que celle trouvée à l'adresse jwt.io, crée un jeton JWT avec un en-tête. et charge utile comme dans 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
}

Dans le champ kid de l'en-tête, spécifiez la clé privée de votre compte de service. ID. Vous trouverez cette valeur dans le champ private_key_id de votre compte de service JSON.
Dans les champs iss et sub, indiquez l'adresse e-mail de votre compte de service. adresse e-mail. Vous trouverez cette valeur dans le champ client_email de votre service fichier JSON du compte de service.
Dans le champ aud, spécifiez le point de terminaison de l'API. Exemple : https://SERVICE.googleapis.com/.
Pour le champ iat, indiquez l'heure Unix actuelle, et pour le champ exp, spécifiez l'heure exactement 3 600 secondes plus tard, lorsque le jeton JWT arrive à expiration.

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

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

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

Appelez l'API en utilisant le jeton JWT signé comme jeton de support:

GET /v1/projects/abc/databases/123/indexes HTTP/1.1
Authorization: Bearer SIGNED_JWT
Host: firestore.googleapis.com

Implémenter la protection multicompte

Une mesure supplémentaire à prendre pour protéger l'expérience utilisateur implémente les stratégies d'enchères à l'aide du service de protection multicompte de Google. Ce service vous permet vous abonner aux notifications d'événements liés à la sécurité, qui fournissent des informations à votre application sur des modifications majeures au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de comment vous décidez de répondre aux événements.

Voici quelques exemples de types d'événements envoyés à votre application par le service de protection multicompte de Google:

https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
https://schemas.openid.net/secevent/risc/event-type/account-disabled

Consultez le Protéger les comptes utilisateur grâce à la page "Protection multicompte" pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles.

Utiliser OAuth 2.0 pour l'authentification serveur à serveur

Présentation

Créer un compte de service

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

Préparer un appel d'API délégué

Java

Déléguer l'autorité au niveau du domaine

Python

HTTP/REST

Créer un jeton JWT

Créer l'en-tête JWT

Créer l'ensemble de revendications JWT

Revendications requises

Revendications supplémentaires

Encoder l'ensemble de revendications JWT

Calculer la signature

Envoyer la requête de jeton d'accès

Traiter la réponse

Appeler des API Google

Java

Python

HTTP/REST

Exemples de requête HTTP GET

curl exemples

Expiration des jetons d'accès

Codes d'erreur JWT

Avenant: Autorisation de compte de service sans OAuth

Java

Python

Implémenter la protection multicompte

`curl` exemples