Ajout de plusieurs serveurs d'authentification au même déploiement d'API

Une exigence commune consiste à authentifier les demandes envoyées au même déploiement d'API de différentes façons. Par exemple, vous pouvez souhaiter qu'une demande entrante provenant d'un client d'API soit envoyée à une fonction d'autorisation pour authentification. Alors que, vous pouvez vouloir qu'un jeton Web JSON (JWT) inclus dans une demande entrante d'un autre client d'API soit validé avec un fournisseur d'identités. Pour des raisons pratiques, ces différents types d'authentification et d'autorisation (fonction d'autorisation, authentification JWT) sont appelés "serveurs d'authentification".

Pour répondre à l'exigence d'authentification des demandes envoyées à un déploiement d'API de différentes façons, vous pouvez définir plusieurs serveurs d'authentification pour le même déploiement d'API. Les serveurs d'authentification que vous configurez peuvent être du même type ou d'un type différent. Vous pouvez spécifier les types de serveur d'authentification suivants :

Lorsque vous définissez plusieurs serveurs d'authentification pour le même déploiement d'API, vous créez des règles pour permettre à la passerelle d'API de sélectionner dynamiquement le serveur d'authentification à utiliser pour authentifier les demandes, en fonction d'un élément de la demande initiale.

Pour permettre à la passerelle d'API de sélectionner dynamiquement le serveur d'authentification approprié, vous utilisez les variables de contexte suivantes pour saisir les éléments de la demande :

  • request.auth[<key>]<key> est le nom d'une revendication contenue dans un jeton JWT.
  • request.headers[<key>]<key> est le nom d'un en-tête inclus dans la demande à l'API.
  • request.host est le nom de l'hôte auquel la demande initiale a été envoyée.
  • request.path[<key>]<key> est le nom d'un paramètre de chemin défini dans la spécification de déploiement d'API.
  • request.query[<key>]<key> est le nom d'un paramètre d'interrogation inclus dans la demande à l'API.
  • request.subdomain[<key>]<key> est la partie de fin du nom d'hôte à ignorer lors de la saisie de la partie principale du nom d'hôte à laquelle la demande initiale a été envoyée.

Notez que si une variable de contexte comporte plusieurs valeurs, seule la première valeur est utilisée lors de la sélection du serveur d'authentification. Pour plus d'informations sur les variables de contexte, voir Ajout de variables de contexte aux politiques et aux définitions d'élément dorsal HTTP.

Vous pouvez configurer plusieurs serveurs d'authentification pour le même déploiement d'API dans une spécification de déploiement d'API en procédant comme suit :

  • Utilisation de la console.
  • En modifiant un fichier JSON.

Notes sur la mise en correspondance des règles du serveur d'authentification

Lors de la création des règles pour déterminer quel serveur d'authentification utiliser, vous pouvez spécifier à quel point la valeur de la variable de contexte doit correspondre à une valeur donnée pour que la demande soit acheminée vers un serveur d'authentification particulier. Vous pouvez exiger une correspondance exacte, ou vous pouvez spécifier une valeur commençant par un caractère générique ou se terminant par. La passerelle d'API évalue les règles dans l'ordre que vous spécifiez (règles de correspondance exactes en premier, suivies de règles génériques) et utilise la première règle de correspondance. Vous pouvez également spécifier une règle par défaut à utiliser si la valeur de la variable de contexte ne correspond à aucune règle du serveur d'authentification. Si aucune règle n'est spécifiée comme valeur par défaut et que la valeur de la variable de contexte dans une demande entrante ne correspond à aucune règle du serveur d'authentification, la demande retourne une erreur. L'ordre de priorité pour déterminer quelle règle de serveur d'authentification (et donc quel serveur d'authentification) utiliser peut être résumé comme suit :

  • Si la valeur de la variable de contexte correspond exactement à la valeur d'une règle, utilisez cette règle.
  • Sinon, si la valeur de la variable de contexte correspond à la valeur d'une règle qui commence ou se termine par un caractère générique, utilisez la première règle contenant un caractère générique qui correspond.
  • Sinon, si une règle est spécifiée comme règle par défaut, utilisez cette règle.
  • Sinon, retournez une réponse d'erreur 401 Unauthorized.

Utilisation de la console pour ajouter plusieurs serveurs d'authentification au même déploiement d'API

Pour ajouter plusieurs serveurs d'authentification pour le même déploiement d'API à une spécification de déploiement d'API à l'aide de la console :

  1. Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

    Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.

  2. Sélectionnez Suivant pour afficher la page Authentification.
  3. Sélectionnez Authentification multiple pour spécifier que les demandes d'authentification doivent être acheminées vers différents serveurs d'authentification, en fonction de la variable de contexte et des règles que vous entrez :
    1. Dans la liste Sélecteur, sélectionnez la table de contexte (contenant la variable de contexte) à utiliser pour déterminer le serveur d'authentification vers lequel envoyer la demande d'authentification, comme suit :
      • Authentification : Utilisez la valeur d'une revendication contenue dans un JWT (et enregistrée dans la table de contexte request.auth) pour déterminer le serveur d'authentification. Notez que si vous sélectionnez Authentification, vous devez spécifier des serveurs d'authentification de type Jeton Web JSON (JWT) pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous sélectionnez Authentification dans la liste Sélecteur, notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification avec jeton Web JSON (JWT) (soit le même en-tête de demande et le même modèle d'autorisation, soit le même paramètre d'interrogation).
      • En-têtes : Utilisez la valeur d'un en-tête de la demande initiale (et enregistrée dans la table de contexte request.headers) pour déterminer le serveur d'authentification.
      • Hôte : Utilisez le nom de l'hôte auquel la demande initiale a été envoyée (extrait du champ hôte de l'en-tête d'hôte dans la demande et enregistré dans la table de contexte request.host) pour déterminer le serveur d'authentification.
      • Chemin : Utilisez un paramètre de chemin à partir de la demande initiale (et enregistré dans la table de contexte request.path) pour déterminer le serveur d'authentification.
      • Paramètres d'interrogation : Utilisez la valeur d'un paramètre d'interrogation de la demande initiale (et enregistrée dans la table de contexte request.query) pour déterminer le serveur d'authentification.
      • Sous-domaine : Utilisez la partie principale du nom d'hôte auquel la demande initiale a été envoyée (juste la partie du nom d'hôte non spécifiée en tant que clé, et enregistrée dans la table de contexte request.subdomain) pour déterminer le serveur d'authentification. Notez que la clé est la partie de fin du nom d'hôte à ne pas utiliser.
    2. Selon la table de contexte que vous sélectionnez, entrez le nom de la clé à utiliser pour déterminer le serveur d'authentification vers lequel envoyer la demande d'authentification.
  4. Sélectionnez Définir une politique pour entrer une règle pour la variable de contexte qui, si elle est satisfaite, achemine la demande d'authentification vers le serveur d'authentification que vous définissez.
  5. Entrez les détails de la règle du serveur d'authentification comme suit :
    • Nom : Entrez un nom pour la règle de serveur d'authentification. Utilisez le nom que vous entrez pour identifier le serveur d'authentification lors de la référence aux journaux et aux mesures. Le nom doit être unique dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
    • Type de correspondance : Spécifiez à quel point la valeur de la variable de contexte doit correspondre à une valeur que vous entrez pour que la demande soit acheminée vers ce serveur d'authentification. Sélectionnez Au choix si la variable de contexte doit correspondre exactement à la valeur du champ Valeurs. Sélectionnez Caractère générique si la variable de contexte doit correspondre à une valeur du champ Expression qui contient des caractères génériques. La correspondance de valeurs n'est pas sensible à la casse si vous sélectionnez Au choix et sensible à la casse si vous sélectionnez Caractère générique.
    • Valeurs : (Affiché si vous avez sélectionné N'importe lequel dans le champ Type de correspondance.) Spécifiez une valeur (ou plusieurs valeurs dans une liste séparée par des virgules) que la variable de contexte doit correspondre exactement. Notez que la correspondance n'est pas sensible à la casse si vous avez sélectionné Au choix. Notez également que les valeurs doivent être uniques dans une seule règle de serveur d'authentification et dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
    • Expression : (Affichée si vous avez sélectionné Caractère générique dans le champ Type de correspondance) Spécifiez une valeur commençant par, ou se terminant par, un caractère générique que la variable de contexte doit correspondre. Utilisez le caractère générique * (astérisque) pour indiquer zéro caractère ou plus, et/ou le caractère générique + (signe plus) pour indiquer un ou plusieurs caractères. Notez que la correspondance est sensible à la casse si vous avez sélectionné Caractère générique. Notez que vous ne pouvez pas inclure plus d'un caractère générique dans une valeur et que vous ne pouvez pas inclure un caractère générique au milieu d'une valeur.
    • Définir la valeur par défaut : Spécifiez si le serveur d'authentification défini pour cette règle doit être utilisé si aucune autre règle de serveur d'authentification ne correspond à la valeur de la variable de contexte. Vous ne pouvez spécifier qu'une seule règle de serveur d'authentification par défaut pour un déploiement d'API. Si aucune règle n'est marquée comme valeur par défaut et que la valeur de la variable de contexte dans une demande entrante ne correspond à aucune règle de serveur d'authentification définie pour un déploiement d'API, la demande retourne une réponse d'erreur 401 Unauthorized.
  6. Cochez ou désélectionnez la case Activer l'accès anonyme pour spécifier si les utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes du déploiement d'API.

    Par défaut, cette option n'est pas sélectionnée. Si vous voulez que des utilisateurs anonymes ne puissent jamais accéder aux routes, ne sélectionnez pas cette option. Notez que si vous sélectionnez cette option, vous devez également spécifier explicitement toutes les routes pour lesquelles un accès anonyme est autorisé en sélectionnant Anonyme comme Type d'autorisation dans la politique d'autorisation de chaque route.

  7. Entrez les détails du serveur d'authentification comme suit :
    1. Dans le champ Type d'authentification, sélectionnez Jeton Web JSON (JWT) ou Fonction d'autorisation comme serveur d'authentification vers lequel acheminer la demande d'authentification si la règle que vous avez entrée est satisfaite.

      Notez que si vous avez sélectionné Authentification dans la liste Sélecteur, vous devez sélectionner Jeton Web JSON (JWT) comme type de serveur d'authentification. Si vous avez sélectionné Authentification dans la liste Sélecteur, notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification avec jeton Web JSON (JWT) (soit le même en-tête de demande et le même modèle d'autorisation, soit le même paramètre d'interrogation).

    2. Entrez les détails du serveur d'authentification que vous avez sélectionné. Les détails à entrer dépendent du type de serveur d'authentification que vous avez sélectionné :
    3. Sélectionnez Définir pour créer le serveur d'authentification et la règle associée.
  8. Facultativement, sélectionnez de nouveau Définir une politique pour définir des serveurs d'authentification supplémentaires et des règles associées.
  9. Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
  10. Sélectionnez Enregistrer les modifications, puis sélectionnez Suivant pour vérifier les détails que vous avez entrés pour le déploiement d'API.
  11. Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
  12. (Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter plusieurs serveurs d'authentification au même déploiement d'API

Pour ajouter plusieurs serveurs d'authentification pour le même déploiement d'API à une spécification de déploiement d'API dans un fichier JSON :

  1. Dans votre éditeur JSON préféré, créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API) au format suivant :

    {
      "requestPolicies": {
        "dynamicAuthentication": {
          "selectionSource": {
            "selector": "<context-table-key>",
            "type": "SINGLE"
          },
          "authenticationServers": [
            {
              "key": {
                "type": "<ANY_OF|WILDCARD>",
                "values": ["<context-variable-value>"],
                "isDefault": "<true|false>",
                "name": "<rule-name>"
              },
              "authenticationServerDetail": {
                "type": "<authentication-server-type>",
                "<auth-server-attribute-name>": "<auth-server-attribute-value>",
                ...
                "<auth-server-attribute-name>": "<auth-server-attribute-value>"
              }
            }
          ]
        }
      },
      "routes": []
    }

    où :

    • "dynamicAuthentication" indique que vous voulez que la passerelle d'API sélectionne dynamiquement le serveur d'authentification à utiliser pour authentifier les demandes, en fonction d'un élément de la demande.
    • "selector": "<context-table-key>" spécifie la table de contexte (et la clé, le cas échéant) à partir de laquelle obtenir la valeur de variable de contexte qui détermine le serveur d'authentification auquel envoyer les demandes d'authentification, comme suit :
      • request.auth[<key>] Utilisez la valeur d'une revendication contenue dans un jeton Web JSON (JWT) pour déterminer le serveur d'authentification. <key> est le nom de la revendication. Par exemple, request.auth[tenant]. Notez que si vous spécifiez request.auth[<key>], vous devez spécifier des serveurs d'authentification de type JWT_AUTHENTICATION pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous spécifiez request.auth[<key>], notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification (soit le même en-tête de demande et le même modèle d'autorisation, soit le même paramètre d'interrogation).
      • request.headers[<key>] Utilisez la valeur d'un en-tête de la demande initiale pour déterminer le serveur d'authentification. <key> est le nom de l'en-tête. Par exemple, request.headers[Accept]
      • request.host Utilisez le nom de l'hôte auquel la demande initiale a été envoyée (extrait du champ hôte de l'en-tête d'hôte dans la demande) pour déterminer le serveur d'authentification.
      • request.path[<key>] Utilisez un paramètre de chemin à partir de la demande initiale pour déterminer le serveur d'authentification. <key> est le nom du paramètre de chemin. Par exemple, request.path[region]
      • request.query[<key>] Utilisez la valeur d'un paramètre d'interrogation de la demande initiale pour déterminer le serveur d'authentification. <key> est le nom du paramètre d'interrogation. Par exemple, request.query[state]
      • request.subdomain[<key>] Utilisez la partie principale du nom d'hôte à laquelle la demande initiale a été envoyée (juste la partie du nom d'hôte non spécifiée en tant que clé) pour déterminer le serveur d'authentification. Notez que <key> est la partie de fin du nom d'hôte à ne pas utiliser. Par exemple, request.subdomain[example.com]
    • "type": "SINGLE" indique que vous voulez utiliser une seule variable de contexte pour sélectionner dynamiquement le serveur d'authentification.
    • "key": {...} spécifie la règle à respecter pour envoyer une demande au serveur d'authentification spécifié par "authenticationServerDetail": {…}.
    • "type": "<ANY_OF|WILDCARD>" indique à quel point la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre à la valeur entrée pour <context-variable-value> pour que la demande soit envoyée au serveur d'authentification spécifié par "authenticationServerDetail": {…}. Spécifiez ANY_OF si la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre exactement à la valeur que vous spécifiez pour <context-variable-value>. Spécifiez WILDCARD si la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre à une valeur contenant des caractères génériques que vous spécifiez pour <context-variable-value>. La correspondance de valeurs n'est pas sensible à la casse si vous spécifiez ANY_OF et la casse si vous spécifiez WILDCARD.
    • <context-variable-value> est une valeur qui correspond éventuellement à la valeur de la variable de contexte identifiée par <context-table-key>. Vous pouvez inclure plusieurs entrées "<context-variable-value>" dans le tableau values:[...], séparées par des virgules. La demande est envoyée au serveur d'authentification spécifié par "authenticationServerDetail": {…} si les valeurs correspondent, comme suit :
      • Si vous avez spécifié "type": "ANY_OF", les valeurs doivent correspondre exactement. Notez que les valeurs doivent être uniques dans une seule règle de serveur d'authentification et dans toutes les règles de serveur d'authentification définies pour un déploiement d'API. La correspondance de valeurs n'est pas sensible à la casse si vous avez spécifié ANY_OF.
      • Si vous avez spécifié "type": "WILDCARD", vous pouvez spécifier une valeur pour <context-variable-value> qui commence par un caractère générique ou qui se termine par. Utilisez le caractère générique * (astérisque) pour indiquer zéro caractère ou plus, et/ou le caractère générique + (signe plus) pour indiquer un ou plusieurs caractères. Notez que vous ne pouvez pas inclure plus d'un caractère générique dans une valeur et que vous ne pouvez pas inclure un caractère générique au milieu d'une valeur. La correspondance de valeurs est sensible à la casse si vous avez spécifié WILDCARD.
      Par exemple, si vous voulez qu'une demande d'un client d'API qui peut accepter une réponse xml (comme indiqué dans l'en-tête Accepter de la demande) soit acheminée vers un serveur d'authentification particulier, vous pouvez spécifier :
      • "selector": "request.headers[Accept]"
      • "type": "ANY_OF"
      • "values": ["application/xml"]
    • "isDefault": "<true|false>" est une valeur booléenne facultative (true ou false) indiquant si le serveur d'authentification doit être utilisé pour cette règle si aucune autre règle du serveur d'authentification ne correspond à la valeur de la variable de contexte. S'il n'est pas spécifié, "isDefault": "false" est supposé. Vous ne pouvez spécifier qu'une seule règle de serveur d'authentification par défaut pour un déploiement d'API. Si aucune règle n'est marquée comme valeur par défaut et que la valeur de la variable de contexte dans une demande entrante ne correspond à aucune règle de serveur d'authentification définie pour un déploiement d'API, la demande retourne une réponse d'erreur 401 Unauthorized.
    • "name": "<rule-name>" indique un nom pour la règle. Utilisez ce nom pour identifier le serveur d'authentification lors de la référence aux journaux et aux mesures. Le nom doit être unique dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
    • "type": "<authentication-server-type>" indique le type du serveur d'authentification. Les valeurs valides sont JWT_AUTHENTICATION et CUSTOM_AUTHENTICATION. Notez que si vous avez spécifié request.auth[<key>], vous devez spécifier des serveurs d'authentification de type JWT_AUTHENTICATION pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous avez spécifié request.auth[<key>], notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification (soit le même en-tête de demande et le même modèle d'autorisation, soit le même paramètre d'interrogation).
    • "<auth-server-attribute-name>": "<auth-server-attribute-value>" sont des attributs et des valeurs d'attribut pour le type de serveur d'authentification que vous avez spécifié. Les attributs et les valeurs d'attribut à entrer dépendent du type de serveur d'authentification que vous avez spécifié :

    Par exemple, la spécification de déploiement d'API suivante inclut une sélection de serveur d'authentification dynamique qui traite les demandes d'authentification en fonction de la valeur du paramètre d'interrogation vehicle-type transmis dans la demande. Pour une explication plus détaillée de cet exemple, voir Exemple 1 : Sélectionner JWT ou fonction sans serveur comme serveur d'authentification à l'aide d'un paramètre d'interrogation (y compris la sélection de caractères génériques et la valeur par défaut).

    {
      "requestPolicies": {
        "dynamicAuthentication": {
          "selectionSource": {
            "selector": "request.query[vehicle-type]",
            "type": "SINGLE"
          },
          "authenticationServers": [
            {
              "key": {
                "type": "ANY_OF",
                "values": ["car"],
                "isDefault": "true",
                "name": "authServer1"
              },
              "authenticationServerDetail": {
                "type": "JWT_AUTHENTICATION",
                "tokenHeader": "Authorization",
                "tokenAuthScheme": "Bearer",
                "isAnonymousAccessAllowed": true,
                "issuers": ["https://recommend-app.eu.auth0.com/"],
                "audiences": ["api.dev.io"],
                "maxClockSkewInSeconds": 0,
                "verifyClaims": [
                  {
                    "key": "gty",
                    "value": ["client-credentials"],
                    "isRequired": true
                  }
                ],
                "publicKeys": {
                  "type": "REMOTE_JWKS",
                  "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
                  "maxCacheDurationInHours": 1
                }
              }
            },
            {
              "key": {
                "type": "WILDCARD",
                "expression": "mini*",
                "name": "authServer2"
              },
              "authenticationServerDetail": {
                "type": "CUSTOM_AUTHENTICATION",
                "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
                "isAnonymousAccessAllowed": true
              }
            }
          ]
        }
      },
      "routes": []
    }
  2. Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
  3. Utilisez comme suit la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API :

    • En spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Charger une API existante.
    • En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.

    Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.

  4. (Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Exemples

Exemple 1 : Sélectionner JWT ou une fonction sans serveur en tant que serveur d'authentification à l'aide d'un paramètre d'interrogation (y compris la sélection de caractères génériques et la valeur par défaut)

Dans cet exemple, la passerelle d'API détermine le serveur d'authentification vers lequel envoyer la demande d'authentification en fonction de la valeur du paramètre d'interrogation vehicle-type transmis dans la demande. Si le paramètre d'interrogation vehicle-type a la valeur car, le JWT dans l'en-tête d'autorisation de la demande est validé en extrayant les clés de vérification publiques du fournisseur d'identités https://recommend-app.eu.auth0.com. Si le paramètre d'interrogation vehicle-type a une valeur qui commence par mini, une demande d'authentification est envoyée à une fonction sans serveur dans le service des fonctions pour OCI pour traitement. Si la valeur du paramètre d'interrogation vehicle-type n'est ni car ni mini*, la passerelle d'API suppose par défaut qu'il existe un JWT dans l'en-tête d'autorisation de la demande et tente de la valider en extrayant les clés de vérification publiques du fournisseur d'identités https://recommend-app.eu.auth0.com :

{
  "requestPolicies": {
    "dynamicAuthentication": {
      "selectionSource": {
        "selector": "request.query[vehicle-type]",
        "type": "SINGLE"
      },
      "authenticationServers": [
        {
          "key": {
            "type": "ANY_OF",
            "values": ["car"],
            "isDefault": "true",
            "name": "authServer1"
          },
          "authenticationServerDetail": {
            "type": "JWT_AUTHENTICATION",
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "isAnonymousAccessAllowed": true,
            "issuers": ["https://recommend-app.eu.auth0.com/"],
            "audiences": ["api.dev.io"],
            "maxClockSkewInSeconds": 0,
            "verifyClaims": [
              {
                "key": "gty",
                "value": ["client-credentials"],
                "isRequired": true
              }
            ],
            "publicKeys": {
              "type": "REMOTE_JWKS",
              "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
              "maxCacheDurationInHours": 1
            }
          }
        },
        {
          "key": {
            "type": "WILDCARD",
            "expression": "mini*",
            "name": "authServer2"
          },
          "authenticationServerDetail": {
            "type": "CUSTOM_AUTHENTICATION",
            "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
            "isAnonymousAccessAllowed": true
          }
        }
      ]
    }
  },
  "routes": []
}

Exemple 2 : Sélectionner un serveur d'authentification JWT à l'aide de revendications provenant de jetons JWT

Dans cet exemple, la passerelle d'API détermine le serveur d'authentification vers lequel envoyer la demande d'authentification en fonction de la revendication tenant dans un jeton JWT transmis dans l'en-tête d'autorisation de la demande. Deux exemples de jetons JWT suivent la spécification de déploiement d'API :

{
  "pathPrefix": "/deployment-path",
  "specification": {
    "requestPolicies": {
      "dynamicAuthentication": {
        "selectionSource": {
          "selector": "request.auth[tenant]",
          "type": "SINGLE"
        },
        "authenticationServers": [
          {
            "key": {
              "values": ["cars"],
              "type": "ANY_OF",
              "name": "authServer1"
            },
            "authenticationServerDetail": {
              "type": "JWT_AUTHENTICATION",
              "tokenHeader": "Authorization",
              "tokenAuthScheme": "Bearer",
              "isAnonymousAccessAllowed": true,
              "issuers": ["https://tenant-2.us.auth0.com/"],
              "audiences": ["https://tenant-2"],
              "maxClockSkewInSeconds": 0,
              "verifyClaims": [
                {
                  "key": "gty",
                  "value": ["client-credentials"],
                  "isRequired": true
                }
              ],
              "publicKeys": {
                "type": "REMOTE_JWKS",
                "uri": "https://car.us.auth0.com/.well-known/jwks.json",
                "maxCacheDurationInHours": 1
              }
            }
          },
          {
            "key": {
              "values": ["trucks"],
              "type": "ANY_OF",
              "name": "authServer2"
            },
            "authenticationServerDetail": {
              "type": "JWT_AUTHENTICATION",
              "tokenHeader": "Authorization",
              "tokenAuthScheme": "Bearer",
              "isAnonymousAccessAllowed": true,
              "issuers": ["https://tenant-2.us.auth0.com/"],
              "audiences": ["https://tenant-2"],
              "maxClockSkewInSeconds": 0,
              "verifyClaims": [
                {
                  "key": "gty",
                  "value": ["client-credentials"],
                  "isRequired": true
                }
              ],
              "publicKeys": {
                "type": "REMOTE_JWKS",
                "uri": "https://truck.us.auth0.com/.well-known/jwks.json",
                "maxCacheDurationInHours": 1
              }
            }
          }
        ]
      }
    }
  },
  "loggingPolicies": {},
  "routes": []
}

Lors de l'authentification d'une demande avec le jeton JWT suivant dans l'en-tête d'autorisation, la passerelle d'API extrait le jeu de clés Web JSON (JWKS) pour vérifier la signature à partir de https://car.us.auth0.com/.well-known/jwks.json.

{
  "iss": "https://tenant-2.us.auth0.com/",
  "sub": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a@clients",
  "aud": "https://tenant-2",
  "iat": 1641282986,
  "exp": 1641369386,
  "azp": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a",
  "gty": "client-credentials",
  "tenant":"cars"
}

Lors de l'authentification d'une demande avec le jeton JWT suivant dans l'en-tête d'autorisation, la passerelle d'API extrait le jeu de clés Web JSON (JWKS) pour vérifier la signature à partir de https://truck.us.auth0.com/.well-known/jwks.json.

{
  "iss": "https://tenant-2.us.auth0.com/",
  "sub": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a@clients",
  "aud": "https://tenant-2",
  "iat": 1641282986,
  "exp": 1641369386,
  "azp": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a",
  "gty": "client-credentials",
  "tenant":"trucks"
}