Utiliser OAuth 2.0 pour l'authentification serveur à serveur

Le système OAuth 2.0 de Google est compatible avec les interactions entre serveurs, par exemple entre une application Web et un service Google. Pour ce scénario, vous avez besoin d'un compte de service, qui appartient à votre application et non à un 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 acteurs" ou "2LO". (Le terme associé "OAuth à trois étapes" fait référence aux scénarios dans lesquels votre application appelle des 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 lorsqu'elle utilise des API Google pour travailler avec ses propres données plutôt qu'avec celles 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 Workspace peuvent également accorder aux comptes de service une autorité au niveau du domaine pour accéder aux données utilisateur pour le compte des utilisateurs du domaine.

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

Présentation

Pour prendre en charge les interactions entre serveurs, créez d'abord un compte de service pour votre projet dans API Console. Si vous souhaitez accéder aux données utilisateur des utilisateurs de votre compte Google Workspace, 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 des identifiants 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é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 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. Toutefois, vous devez spécifier les niveaux d'accès dont votre application a besoin lorsque vous créez une instance Google Compute Engine. Pour en savoir plus, consultez la section Préparer 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. Pour générer des identifiants de compte de service ou afficher les identifiants publics que vous avez déjà générés, procédez comme suit:

First, create a service account:

1. Open the Service accounts page.
2. If prompted, select a project, or create a new one.
3. Click add Create service account.
4. Under Service account details, type a name, ID, and description for the service account, then click Create and continue.
5. Optional: Under Grant this service account access to project, select the IAM roles to grant to the service account.
6. Click Continue.
7. Optional: Under Grant users access to this service account, add the users or groups that are allowed to use and manage the service account.
8. Click Done.

Next, create a service account key:

1. Click the email address for the service account you created.
2. Click the Keys tab.
3. In the Add key drop-down list, select Create new key.
4. Click Create.

Your new public/private key pair is generated and downloaded to your machine; it serves as the only copy of the private key. You are responsible for storing it securely. If you lose this key pair, you will need to generate a new one.

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

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é au niveau du domaine au compte de service

À l'aide d'un compte Google Workspace, un administrateur Workspace de l'organisation peut autoriser une application à accéder aux données utilisateur Workspace pour le compte des utilisateurs du domaine Google Workspace. Par exemple, une application qui se sert de l'API Google Agenda pour ajouter des événements aux agendas de tous les utilisateurs d'un domaine Google Workspace peut accéder à l'API Google Agenda pour le compte des utilisateurs via un compte de service. Le fait d'autoriser un compte de service à accéder aux données pour le compte d'utilisateurs d'un domaine est parfois appelé "délégation de l'autorité au niveau du domaine" à ce compte de service.

Pour déléguer une autorité de domaine à un compte de service, un super-administrateur du domaine Google Workspace doit suivre ces étapes:

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

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

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

Java

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

Délégation d'autorité au niveau du domaine

Si vous avez délégué un accès au niveau du domaine au compte de service et que vous souhaitez usurper l'identité d'un compte utilisateur, spécifiez l'adresse e-mail du compte utilisateur avec la 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 méthode createDelegated(). L'argument de la méthode createDelegated() doit être un utilisateur appartenant à votre compte Workspace. Votre code effectuant la requête utilisera ces identifiants pour appeler les API Google à l'aide de votre compte de service.

Python

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

1. Créez un objet Credentials à partir des identifiants du compte de service et des champs d'application auxquels votre application doit accéder. 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 identifiants par défaut de l'application à la place, ce qui peut simplifier le processus.

2. Délégation d'autorité au niveau du domaine

   Si vous avez délégué un accès au niveau du domaine au compte de service et que vous souhaitez usurper l'identité d'un compte utilisateur, utilisez la méthode with_subject d'un objet ServiceAccountCredentials existant. Exemple :

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

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

HTTP/REST

Une fois que vous avez obtenu l'ID client et la clé privée de API Console, votre application doit suivre 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 suivantes décrivent comment suivre ces étapes.

Si la réponse inclut un jeton d'accès, vous pouvez l'utiliser pour appeler une API Google. (Si la réponse n'inclut pas de jeton d'accès, il est possible que votre JWT et votre requête de jeton ne soient pas correctement formés, ou que le compte de service ne soit pas autorisé à accéder aux champs d'application d'accès demandés.)

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

Le reste de cette section décrit les détails de la création d'un jeton JWT, de sa signature, de la création de la requête de jeton d'accès et de la gestion de la réponse.

Créer un jeton JWT

Un jeton JWT se compose 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. Cet encodage offre une résilience contre les modifications d'encodage dues à des opérations d'encodage répétées. L'en-tête, l'ensemble de revendications et la signature sont concaténés avec un caractère point (.).

Un jeton JWT se compose 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 trois champs qui indiquent l'algorithme de signature, le format de l'assertion et l'[ID de clé du compte de service](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 comporte qu'une seule valeur. À mesure que des algorithmes et des formats supplémentaires seront introduits, cet en-tête changera en conséquence. L'ID de clé est facultatif. Si un ID de clé incorrect est spécifié, GCP essaie toutes les clés associées au compte de service pour valider le jeton et le rejette si aucune clé valide n'est trouvée. Google se réserve le droit de rejeter les jetons avec des ID de clé incorrects à 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"}

La représentation en base64url est la suivante:

          eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

Former l'ensemble de revendications JWT

L'ensemble de revendications JWT contient des informations sur le jeton JWT, y compris les autorisations demandées (champs d'application), 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.

Revendications requises

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

Nom	Description
iss	Adresse e-mail du compte de service.
scope	Liste des autorisations demandées par l'application, délimitées par des espaces.
aud	Descripteur de la cible visée de l'assertion. Lorsque vous effectuez une requête de jeton d'accès, 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, le 1er janvier 1970. Cette valeur ne doit pas dépasser une heure après l'heure d'émission.
iat	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 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 au nom d'un utilisateur particulier d'une organisation. L'autorisation d'effectuer ce type d'usurpation d'identité doit être accordée avant qu'une application puisse usurper l'identité d'un utilisateur. Elle est généralement gérée par un super-administrateur. Pour en savoir plus, consultez Contrôler 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 la revendication JWT définie comme valeur du champ sub.

Nom	Description
sub	Adresse e-mail de l'utilisateur pour lequel l'application demande un accès délégué.

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

Un exemple d'ensemble de revendications JWT incluant le champ sub est présenté 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 encodé 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
}

Calculer la signature

La signature Web JSON (JWS) est la spécification qui guide la mécanique de génération de la signature pour le JWT. L'entrée de la signature est la matrice 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. Le seul algorithme de signature compatible avec le serveur d'autorisation Google OAuth 2.0 est RSA, qui utilise l'algorithme de hachage SHA-256. Cette valeur est exprimée sous la forme RS256 dans le champ alg de 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) avec la clé privée obtenue à partir de Google API Console. La sortie sera 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 sont concaténés avec un caractère point (.). Le résultat est le JWT. Il doit ê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 jeton JWT signé et prêt à être transmis:

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

Envoyer la demande de jeton d'accès

Une fois le jeton JWT signé généré, une application peut l'utiliser pour demander un jeton d'accès. Cette requête de jeton d'accès est une requête POST HTTPS, et le corps est encodé en URL. L'URL est indiquée ci-dessous:

https://oauth2.googleapis.com/token

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

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	Le jeton JWT, y compris la signature.

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

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

Gérer la réponse

Si le JWT et la requête 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 période de validité spécifiée par la valeur expires_in.

Appeler des API Google

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

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

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

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

Codes d'erreur JWT

Avenant: Autorisation du 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 jeton de support, plutôt qu'un jeton d'accès OAuth 2.0. Lorsque cela est possible, vous pouvez éviter d'envoyer une requête réseau au serveur d'autorisation de Google avant d'effectuer un appel d'API.

Si la définition de service de l'API que vous souhaitez appeler est 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 :

1. Créez un compte de service comme décrit ci-dessus. Veillez à conserver le fichier JSON que vous obtenez lorsque vous créez le compte.
2. À l'aide de n'importe quelle bibliothèque JWT standard, comme celle disponible sur jwt.io, créez un jeton JWT avec un en-tête et une 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
   }

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

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

Exemple :

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

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 le jeton JWT signé comme jeton porteur:

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

Implémenter la protection multicompte

Pour protéger les comptes de vos utilisateurs, vous devez également implémenter la protection multicompte à l'aide du service de protection multicompte de Google. Ce service vous permet de vous abonner à des notifications d'événements de sécurité qui fournissent des informations à votre application sur les modifications majeures apportées au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de la façon dont 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

Pour en savoir plus sur l'implémentation de la Protection multicompte et obtenir la liste complète des événements disponibles, consultez la page Protéger les comptes utilisateur avec la Protection multicompte .