Gérer les profils d'authentification

Les tâches de votre intégration Apigee peuvent nécessiter une connexion à une application, un service ou une source de données externe. Un profil d'authentification vous permet de configurer et de stocker les détails de l'authentification pour la connexion dans Apigee Integration. Vous pouvez configurer la tâche pour qu'elle utilise le profil d'authentification stocké. La création d'un profil d'authentification est une opération unique. Vous pouvez réutiliser le même profil dans plusieurs intégrations.

Créer un ID client OAuth 2.0

Un ID client sert à identifier une application unique auprès des serveurs OAuth de Google. Si votre application s'exécute sur plusieurs plates-formes, chacune d'elle devra posséder son propre ID client. Pour utiliser OAuth 2.0 dans votre application, vous avez besoin d'un ID client OAuth 2.0, que votre application utilise pour demander un jeton d'accès OAuth 2.0.

Pour créer un ID client OAuth 2.0, procédez comme suit :

  1. Dans la console Google Cloud, accédez à API et services > Identifiants.

    Accéder à "Identifiants"

  2. Cliquez sur Créer des identifiants et sélectionnez ID client OAuth dans la liste des options disponibles.

    La page Créer un ID client OAuth s'affiche.

  3. Type d'application : sélectionnez Application Web dans la liste déroulante.
  4. Nom : saisissez un nom pour votre client OAuth 2.0 afin d'identifier le client dans la console Cloud.
  5. Sous URI de redirection autorisés, cliquez sur +Ajouter un URI et saisissez les informations suivantes :
    https://apigee.google.com/organizations/GOOGLE_CLOUD_PROJECT_NAME/integrations/callback/locations/AUTH_PROFILE_REGION
  6. Cliquez sur Créer.

    Un ID client OAuth 2.0 a bien été créé.

Créer un nouveau profil d'authentification

Pour créer un profil d'authentification, sélectionnez l'une des options suivantes :

Console

  1. Dans l'interface utilisateur Apigee, sélectionnez votre organisation Apigee.
  2. Cliquez sur Développer > Intégrations.
  3. Sélectionnez une intégration existante pour laquelle vous souhaitez créer le profil d'authentification.

    Cela entraîne son ouverture dans l'éditeur d'intégration.

  4. Dans la barre d'outils de l'éditeur d'intégration, cliquez sur (Gérer les profils d'authentification).

    La page Profils d'authentification s'affiche.

  5. Sélectionnez une région pour le profil d'authentification à l'aide du menu déroulant de la page Profils d'authentification.
  6. Cliquez sur Créer et saisissez les informations suivantes :
    • Nom du profil d'authentification : saisissez le nom du profil d'authentification à afficher dans l'éditeur d'intégration.
    • Description du profil d'authentification : saisissez une description du profil d'authentification.
    • Visibilité du profil d'authentification : sélectionnez l'une des options de visibilité de profil suivantes :
      • Visible par tous les utilisateurs du client : le profil d'authentification créé est disponible pour tous les utilisateurs de l'organisation.

      • Seulement visible par vous : le profil d'authentification créé n'est visible par aucun autre utilisateur de l'organisation.
    • Type d'authentification : sélectionnez le type d'authentification dans la liste déroulante, puis saisissez les informations requises. En fonction de votre sélection, la boîte de dialogue affiche des champs supplémentaires requis pour les identifiants d'authentification. Vous pouvez sélectionner l'un des types d'authentification suivants :
  7. Cliquez sur Enregistrer.

Terraform

Utilisez la ressource google_integrations_client. Vous pouvez utiliser Terraform pour créer les profils d'authentification suivants :

Jeton d'authentification

L'exemple suivant crée un type d'authentification par jeton d'authentification dans la région us-central1 :

resource "google_integrations_client" "client" {
  location = "us-central1"
}

resource "google_integrations_auth_config" "auth_config_auth_token" {
  location     = "us-central1"
  display_name = "tf-auth-token"
  description  = "Test auth config created via terraform"
  decrypted_credential {
    credential_type = "AUTH_TOKEN"
    auth_token {
      type  = "Basic"
      token = "some-random-token"
    }
  }
  depends_on = [google_integrations_client.client]
}

Certification des clients SSL/TLS

L'exemple suivant crée un type d'authentification par certification des clients SSL/TLS dans la région us-central1 :

resource "google_integrations_auth_config" "auth_config_certificate" {
  location     = "us-central1"
  display_name = "tf-certificate"
  description  = "Test auth config created via terraform"
  decrypted_credential {
    credential_type = "CLIENT_CERTIFICATE_ONLY"
  }
  client_certificate {
    ssl_certificate       = <<EOT
-----BEGIN CERTIFICATE-----
MIICTTCCAbagAwIBAgIJAPT0tSKNxan/MA0GCSqGSIb3DQEBCwUAMCoxFzAVBgNV
BAoTDkdvb2dsZSBURVNUSU5HMQ8wDQYDVQQDEwZ0ZXN0Q0EwHhcNMTUwMTAxMDAw
MDAwWhcNMjUwMTAxMDAwMDAwWjAuMRcwFQYDVQQKEw5Hb29nbGUgVEVTVElORzET
MBEGA1UEAwwKam9lQGJhbmFuYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
vDYFgMgxi5W488d9J7UpCInl0NXmZQpJDEHE4hvkaRlH7pnC71H0DLt0/3zATRP1
JzY2+eqBmbGl4/sgZKYv8UrLnNyQNUTsNx1iZAfPUflf5FwgVsai8BM0pUciq1NB
xD429VFcrGZNucvFLh72RuRFIKH8WUpiK/iZNFkWhZ0CAwEAAaN3MHUwDgYDVR0P
AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMBkGA1UdDgQSBBCVgnFBCWgL/iwCqnGrhTPQMBsGA1UdIwQUMBKAEKey
Um2o4k2WiEVA0ldQvNYwDQYJKoZIhvcNAQELBQADgYEAYK986R4E3L1v+Q6esBtW
JrUwA9UmJRSQr0N5w3o9XzarU37/bkjOP0Fw0k/A6Vv1n3vlciYfBFaBIam1qRHr
5dMsYf4CZS6w50r7hyzqyrwDoyNxkLnd2PdcHT/sym1QmflsjEs7pejtnohO6N2H
wQW6M0H7Zt8claGRla4fKkg=
-----END CERTIFICATE-----
EOT
    encrypted_private_key = <<EOT
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCA/Oj2HXqs5fTk
j/8DrlOQtLG3K9RMsYHvnwICLxkGqVcTfut58hDFLbQM8C3C0ENAKitNJplCJmYG
8VpgZzgq8VxaGnlP/sXUFLMGksd5sATn0sY3SkPndTKk/dqqA4MIh/dYfh19ynEN
hB9Ll/h54Yic2je2Qaxe/uMMu8RODTz3oCn7FcoYpPvfygfU0ntn4IcqH/hts5DG
s+3otJk4entRZglQDxR+sWOsbLtJIQZDP8rH3jDVdl5l3wspgtMTY8b5T5+pLm0p
/OzCmxT0dq/O6BhpxI1xf/zcdRZeWk5DTJxTi5AgPquTlAG/B6A3HkqBJ14hT/Rk
iv7Ma3DLAgMBAAECggEABATkf9VfpiAT9zYdouk50bBpckvymQTyQLD8SlBaX+KY
kgv/pHSXK4Pm4iensrQerFLgfqPA3U+FiqjW5Mv7c1VRK6HJbuVkpdzoXLI9IQsL
vsBY7//9Ajk5P7NokjdB6JPdU/2dHROuQVa59cxPtzpHo0htnPlDOKXfFZZuoZ17
Nr8WQHrHy8P8ABM1tLOzvU9Nlh7TcjQvev+HxkLek4qzYyJ/Ac7XOjg/XKUm1tZk
O3BHr8YLabwyjO7l1t+2b14rUTL/8pfUZnAkEi3FAlPxm3ilftmX65zliC9G4ghk
dr5PByT3DqnuIIglua9bISv1H34ogecd+9a6EU7RxQKBgQC2RPKLounXZo8vYiU4
sFTEvjbs+u9Ypk4OrNLnb8KdacLBUaJGnf++xbBoKpwFCBJfy//fvuQfusYF9Gyn
GxL43tw94C/H5upQYnDsmnQak6TbOu3mA24OGK7Rcq6NEHgeCY4HomutnSiPTZJq
8jlpqgqh1itETe5avgkMNq3zBwKBgQC1KlztGzvbB+rUDc6Kfvk5pUbCSFKMMMa2
NWNXeD6i2iA56zEYSbTjKQ3u9pjUV8LNqAdUFxmbdPxZjheNK2dEm68SVRXPKOeB
EmQT+t/EyW9LqBEA2oZt3h2hXtK8ppJjQm4XUCDs1NphP87eNzx5FLzJWjG8VqDq
jOvApNqPHQKBgDQqlZSbgvvwUYjJOUf5R7mri0LWKwyfRHX0xsQQe43cCC6WM7Cs
Zdbu86dMkqzp+4BJfalHFDl0llp782D8Ybiy6CwZbvNyxptNIW7GYfZ9TVCllBMh
5izIqbgub4DWNtq591l+Bf2BnmstU3uiagYw8awSBP4eo9p6y1IgkDafAoGBAJbi
lIiqEP0IqA06/pWc0Qew3rD7OT0ndqjU6Es2i7xovURf3QDkinJThBZNbdYUzdsp
IgloP9yY33/a90SNLLIYlARJtyNVZxK59X4qiOpF9prlfFvgpOumfbkj15JljTB8
aGKkSvfVA5jRYwLysDwMCHwO0bOR1u3itos5AgsFAoGAKEGms1kuQ5/HyFgSmg9G
wBUzu+5Y08/A37rvyXsR6GjmlZJvULEopJNUNCOOpITNQikXK63sIFry7/59eGv5
UwKadZbfwbVF5ipu59UxfVE3lipf/mYePDqMkHVWv/8p+OnnJt9uKnyW8VSOu5uk
82QF30zbIWDTUjrcugVAs+E=
-----END PRIVATE KEY-----
EOT
  }
  depends_on = [google_integrations_client.client]
}

Jeton Web JSON (JWT)

L'exemple suivant crée un type d'authentification par jeton Web JSON (JWT) dans la région us-central1 :

resource "google_integrations_auth_config" "auth_config_jwt" {
  location     = "us-central1"
  display_name = "tf-jwt"
  description  = "Test auth config created via terraform"
  decrypted_credential {
    credential_type = "JWT"
    jwt {
      jwt_header  = "{\"alg\": \"HS256\", \"typ\": \"JWT\"}"
      jwt_payload = "{\"sub\": \"1234567890\", \"name\": \"John Doe\", \"iat\": 1516239022}"
      secret      = "secret"
    }
  }
  depends_on = [google_integrations_client.client]
}

Code d'autorisation OAuth 2.0

L'exemple suivant crée un type d'authentification par certification des clients SSL/TLS dans la région us-central1 :

resource "google_integrations_auth_config" "auth_config_oauth2_authorization_code" {
  location     = "us-central1"
  display_name = "tf-oauth2-authorization-code"
  description  = "Test auth config created via terraform"
  decrypted_credential {
    credential_type = "OAUTH2_AUTHORIZATION_CODE"
    oauth2_authorization_code {
      client_id      = "Kf7utRvgr95oGO5YMmhFOLo8"
      client_secret  = "D-XXFDDMLrg2deDgczzHTBwC3p16wRK1rdKuuoFdWqO0wliJ"
      scope          = "photo offline_access"
      auth_endpoint  = "https://authorization-server.com/authorize"
      token_endpoint = "https://authorization-server.com/token"
    }
  }
  depends_on = [google_integrations_client.client]
}

Identifiants clients OAuth 2.0

L'exemple suivant crée un type d'authentification par identifiants client OAuth 2.0 dans la région us-central1 :

resource "google_integrations_auth_config" "auth_config_oauth2_client_credentials" {
  location     = "us-central1"
  display_name = "tf-oauth2-client-credentials"
  description  = "Test auth config created via terraform"
  decrypted_credential {
    credential_type = "OAUTH2_CLIENT_CREDENTIALS"
    oauth2_client_credentials {
      client_id      = "demo-backend-client"
      client_secret  = "MJlO3binatD9jk1"
      scope          = "read"
      token_endpoint = "https://login-demo.curity.io/oauth/v2/oauth-token"
      request_type   = "ENCODED_HEADER"
      token_params {
        entries {
          key {
            literal_value {
              string_value = "string-key"
            }
          }
          value {
            literal_value {
              string_value = "string-value"
            }
          }
        }
      }
    }
  }
  depends_on = [google_integrations_client.client]
}

Une fois enregistré, le nouveau profil d'authentification est disponible dans la liste déroulante Profil d'autorisation à utiliser de toute tâche nécessitant une authentification.

Facultatif. Si vous n'avez pas créé de profil d'authentification avant de configurer une tâche d'intégration, vous pouvez accéder à la boîte de dialogue de création du profil en sélectionnant + Ajouter un profil d'authentification depuis la liste déroulante Profil d'autorisation à utiliser dans le volet de configuration de la tâche. Suivez les étapes précédentes pour créer un nouveau profil d'authentification.

Modifier les profils d'authentification

Pour modifier un profil d'authentification, procédez comme suit :

  1. Dans l'interface utilisateur Apigee, sélectionnez votre organisation Apigee.
  2. Cliquez sur Développer > Intégrations.
  3. Sélectionnez une intégration existante pour laquelle vous souhaitez créer le profil d'authentification.

    Cela entraîne son ouverture dans l'éditeur d'intégration.

  4. Dans la barre d'outils de l'éditeur d'intégration, cliquez sur (Gérer les profils d'authentification).

    La page Profils d'authentification s'affiche.

  5. Sélectionnez une région pour le profil d'authentification à l'aide du menu déroulant de la page Profils d'authentification.
  6. Cliquez sur (menu d'actions), puis sur Modifier.

    La boîte de dialogue Profils d'authentification s'affiche.

  7. Modifiez les détails, puis cliquez sur Enregistrer.

Supprimer les profils d'authentification

Pour supprimer un profil d'authentification, procédez comme suit :

  1. Dans l'interface utilisateur Apigee, sélectionnez votre organisation Apigee.
  2. Cliquez sur Développer > Intégrations.
  3. Sélectionnez une intégration existante pour laquelle vous souhaitez créer le profil d'authentification.

    Cela entraîne son ouverture dans l'éditeur d'intégration.

  4. Dans la barre d'outils de l'éditeur d'intégration, cliquez sur (Gérer les profils d'authentification).

    La page Profils d'authentification s'affiche.

  5. Sélectionnez une région pour le profil d'authentification à l'aide du menu déroulant de la page Profils d'authentification.
  6. Cliquez sur Supprimer.

Types d'authentification

Le type d'authentification requis pour effectuer une tâche d'intégration dépend de l'authentification configurée dans le serveur d'autorisation. Le serveur d'autorisation peut être un serveur autonome ou une API qui émet des identifiants au client appelant. Apigee Integration est compatible avec les types d'authentification suivants :

Les sections suivantes décrivent les propriétés de configuration des types d'authentification.

Jeton d'authentification

Le type d'authentification par jeton d'authentification utilise un jeton (identifiants) pour l'authentification. Les identifiants sont envoyés au serveur dans l'en-tête de requête HTTP Authorization au format Authorization: TYPE CREDENTIALS. Pour configurer ce type d'authentification, définissez les propriétés suivantes :
  • Type : type d'authentification, tel que Basic, Bearer ou MAC.
  • Jeton : identifiants pour le type d'authentification.

Si le serveur d'authentification nécessite un certificat SSL/TLS, importez le certificat et la clé privée.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Jeton d'ID Google OIDC

Le type d'authentification Jeton d'ID OIDC Google utilise des jetons Web JSON (JWT) pour l'authentification. Le fournisseur OIDC (Google OpenID Connect), accounts.google.com, signe et émet ces jetons JWT pour l'authentification à l'aide d'un compte de service. Pour configurer ce type d'authentification, définissez les propriétés suivantes :
  • Compte de service : compte de service (principal) de votre projet Google Cloud autorisé à accéder à votre API.
  • Audience : audience du jeton OIDC (qui identifie les destinataires auxquels le jeton JWT est destiné). Par exemple, URL du déclencheur est l'audience de la tâche Cloud Functions.
Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Jeton Web JSON (JWT)

Le type d'authentification JWT utilise un jeton Web JSON (JWT) pour l'authentification. Pour plus d'informations sur les jetons JWT, consultez le document RFC7519. Pour configurer ce type d'authentification, définissez les propriétés suivantes :
  • En-tête JWT : algorithme pour générer la signature.

    Remarque : Vous ne pouvez spécifier que l'algorithme HS256.

  • Charge utile JWT : ensemble de revendications. Vous pouvez utiliser des revendications enregistrées, publiques ou personnalisées.
  • Secret : clé partagée entre le client et le serveur d'authentification.

Si le serveur d'authentification nécessite un certificat SSL, importez le certificat et la clé privée à l'aide du sélecteur de fichier. Saisissez la phrase secrète de la clé privée.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Code d'autorisation OAuth 2.0

Le type d'authentification Code d'autorisation OAuth 2.0 utilise un jeton d'autorisation OAuth 2.0 pour l'authentification. Pour configurer ce type d'authentification, définissez les propriétés suivantes :

  • Point de terminaison d'authentification : point de terminaison pour le point de terminaison d'authentification de l'application. Vous serez redirigé vers cette URL afin d'examiner les autorisations d'accès de l'application. Le jeton ne sera généré qu'une fois l'accès accordé.
  • Point de terminaison de jeton : point de terminaison qui accorde ou actualise le jeton d'accès.
  • ID client : chaîne unique fournie par le serveur d'authentification au client enregistré. L'ID client n'est pas un secret et il est exposé au propriétaire de la ressource. Utilisez ce champ avec un code secret du client.
  • Code secret du client : clé secrète partagée entre le client (intégration) et le serveur d'authentification.
  • Champ(s) d'application : champ d'application du jeton d'accès. Les champs d'application vous permettent de spécifier les autorisations d'accès des utilisateurs. Vous pouvez spécifier plusieurs champs d'application séparés par un espace (" "). Pour plus d'informations, consultez la section Champs d'application OAuth 2.0 pour les API Google.

Si le serveur d'authentification nécessite un certificat SSL, importez le certificat et la clé privée à l'aide du sélecteur de fichier. Si nécessaire, saisissez la phrase secrète de la clé privée dans le champ disponible.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Identifiants clients OAuth 2.0

Le type d'authentification Identifiants client OAuth 2.0 utilise un jeton d'autorisation OAuth 2.0 pour l'authentification. Cette authentification demande d'abord un jeton d'accès à l'aide des identifiants client, puis utilise le jeton pour accéder aux ressources protégées. Pour configurer ce type d'authentification, définissez les propriétés suivantes :

  • Point de terminaison de jeton : point de terminaison qui accorde ou actualise le jeton d'accès.
  • ID client : chaîne unique fournie par le serveur d'authentification au client enregistré. L'ID client n'est pas un secret et il est exposé au propriétaire de la ressource. Utilisez ce champ avec un code secret du client.
  • Code secret du client : clé secrète partagée entre le client (intégration) et le serveur d'authentification.
  • Champ(s) d'application : champ d'application du jeton d'accès. Les champs d'application vous permettent de spécifier les autorisations d'accès des utilisateurs. Vous pouvez spécifier plusieurs champs d'application séparés par un espace (" "). Pour plus d'informations, consultez la section Champs d'application OAuth 2.0 pour les API Google.
  • Types de requête : mécanismes permettant d'envoyer les paramètres de requête au serveur d'authentification afin de récupérer le jeton d'accès. Vous pouvez spécifier l'un des types de requêtes suivants :

    • En-tête d'encodage : encode les CLIENT ID et CLIENT SECRET au format Base64, et envoie la chaîne encodée dans l'en-tête d'autorisation HTTP. Les autres paramètres de requête sont envoyés dans le corps de la requête HTTP.
    • Paramètres de requête : permet d'envoyer les paramètres de requête dans une chaîne de requête.
    • Corps de la requête : permet d'envoyer les paramètres de requête en utilisant le type de contenu application/x-www-form-urlencoded et le jeu de caractères UTF-8 dans le entity-body de la requête HTTP.
    • Non spécifié
  • Paramètres de jeton : paramètres de requête requis pour obtenir le jeton. Spécifiez les valeurs au format clé-valeur où Key est le nom du paramètre et Value est la valeur de paramètre correspondante.

Si le serveur d'authentification nécessite un certificat SSL, importez le certificat et la clé privée à l'aide du sélecteur de fichier. Si nécessaire, saisissez la phrase secrète de la clé privée dans le champ disponible.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Identifiants de mots de passe des propriétaires de ressources OAuth 2.0

Le type d'authentification Identifiants de mots de passe des propriétaires de ressources OAuth 2.0 utilise un jeton d'autorisation OAuth 2.0 pour l'authentification. Cette authentification demande d'abord un jeton d'accès à l'aide des identifiants du propriétaire de la ressource (nom d'utilisateur et mot de passe), puis utilise le jeton pour accéder aux ressources protégées. Pour configurer ce type d'authentification, définissez les propriétés suivantes en fonction du type d'instance auquel vous vous connectez :

  • Point de terminaison de jeton : point de terminaison qui accorde ou actualise le jeton d'accès.
  • ID client : chaîne unique fournie par le serveur d'authentification au client enregistré. L'ID client n'est pas un secret et il est exposé au propriétaire de la ressource. Utilisez ce champ avec un code secret du client.
  • Code secret du client : clé secrète partagée entre le client (intégration) et le serveur d'authentification.
  • Champ(s) d'application : champ d'application du jeton d'accès. Les champs d'application vous permettent de spécifier les autorisations d'accès des utilisateurs. Vous pouvez spécifier plusieurs champs d'application séparés par un espace (" "). Pour plus d'informations, consultez la section Champs d'application OAuth 2.0 pour les API Google.
  • Nom d'utilisateur : nom d'utilisateur du propriétaire de la ressource.
  • Mot de passe : mot de passe de l'utilisateur.
  • Types de requête : mécanismes permettant d'envoyer les paramètres de requête au serveur d'authentification afin de récupérer le jeton d'accès. Vous pouvez spécifier l'un des types de requêtes suivants :

    • En-tête d'encodage : encode les CLIENT ID et CLIENT SECRET au format Base64, et envoie la chaîne encodée dans l'en-tête d'autorisation HTTP. Les autres paramètres de requête sont envoyés dans le corps de la requête HTTP.
    • Paramètres de requête : permet d'envoyer les paramètres de requête dans une chaîne de requête.
    • Corps de la requête : permet d'envoyer les paramètres de requête en utilisant le type de contenu application/x-www-form-urlencoded et le jeu de caractères UTF-8 dans le entity-body de la requête HTTP.
  • Paramètres de jeton : paramètres de requête requis pour obtenir le jeton. Spécifiez les valeurs au format clé-valeur où Key est le nom du paramètre et Value est la valeur de paramètre correspondante.

Si le serveur d'authentification nécessite un certificat SSL, importez le certificat et la clé privée à l'aide du sélecteur de fichier. Si nécessaire, saisissez la phrase secrète de la clé privée dans le champ disponible.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Certificat client SSL/TLS uniquement

Le type d'authentification Certificat client SSL/TLS uniquement n'utilise que le certificat SSL/TLS pour l'authentification. Importez le certificat requis et la clé privée. Pour configurer ce type d'authentification, importez les fichiers suivants :
  • Certificat SSL : certificat encodé au format PEM.
  • Clé privée : fichier de clé privée du certificat encodé au format PEM.

    Si la clé privée nécessite une phrase secrète (passphrase), saisissez la phrase secrète de la clé privée.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Compte de service

Le type d'authentification Compte de service utilise les identifiants du compte de service d'un projet Google Cloud pour l'authentification. Pour configurer ce type d'authentification, définissez les propriétés suivantes :

  • Compte de service : compte de service (principal) de votre projet Google Cloud autorisé à accéder à votre API.
  • Champ(s) d'application : champ d'application des autorisations d'accès accordées aux utilisateurs. Vous pouvez spécifier plusieurs champs d'application séparés par un espace (" "). Pour plus d'informations, consultez la section Champs d'application OAuth 2.0 pour les API Google.

Pour en savoir plus sur les bonnes pratiques à suivre pour créer et gérer des comptes de service, consultez la documentation Bonnes pratiques d'utilisation des comptes de service.

Si le serveur d'authentification nécessite un certificat SSL, importez le certificat et la clé privée à l'aide du sélecteur de fichier. Si nécessaire, saisissez la phrase secrète de la clé privée dans le champ disponible.

Pour découvrir quelles tâches sont compatibles avec ce type d'authentification, consultez la section Compatibilité des types d'authentification avec les tâches.

Compatibilité des types d'authentification avec les tâches

Le tableau suivant répertorie les types d'authentification et les tâches compatibles correspondantes. Vous pouvez utiliser ces informations pour décider du type d'authentification à utiliser pour une tâche.

Type d'authentification Tâches et déclencheurs compatibles
Jeton d'authentification
Jeton d'ID Google OIDC
Jeton Web JSON (JWT)
Code d'autorisation OAuth 2.0
Identifiants clients OAuth 2.0
Identifiants de mots de passe des propriétaires de ressources OAuth 2.0
Certificat client SSL/TLS uniquement
Compte de service

Règle d'authentification

Si le profil OAuth 2.0 et un compte de service géré par l'utilisateur sont tous deux configurés pour votre intégration, le profil OAuth 2.0 est utilisé par défaut pour l'authentification. Lorsqu'aucun des deux n'est configuré, le compte de service par défaut (service-PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com) est utilisé. Si la tâche n'utilise pas le compte de service par défaut, l'exécution échoue.