Ajout de stratégies de demande d'authentification et d'autorisation

Découvrez comment ajouter des stratégies de demande pour fournir l'authentification et l'autorisation avec API Gateway.

Vous pouvez ajouter des stratégies de demande pour fournir l'authentification et l'autorisation à l'aide des éléments suivants :

jetons d'accès à arguments multiples définis par l'utilisateur transmis à des fonctions d'autorisation à arguments multiples (reportez-vous à Ajout de stratégies de demande d'authentification et d'autorisation pour les jetons d'accès à plusieurs arguments et les fonctions d'autorisation (recommandé))
jetons d'accès à argument unique transmis aux fonctions d'autorisation à argument unique (reportez-vous à Ajout de stratégies de demande d'authentification et d'autorisation pour les jetons d'accès à argument unique et les fonctions d'autorisation)

Ajout de stratégies de demande d'authentification et d'autorisation pour les jetons d'accès multi-arguments et les fonctions d'autorisation (recommandé)

Vous pouvez ajouter des stratégies de demande pour fournir une authentification et une autorisation à l'aide de jetons d'accès à arguments multiples définis par l'utilisateur et de fonctions d'autorisation à arguments multiples en :

Utilisation de la console afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation multi-arguments

Afin d'ajouter des stratégies de demande d'authentification et d'autorisation pour les jetons d'accès sans argument à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

Pour plus d'informations, reportez-vous à 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.
Sélectionnez Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour indiquer que vous souhaitez utiliser un serveur d'authentification unique pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d'authentification. Si vous souhaitez utiliser plusieurs serveurs d'authentification, vous pouvez également sélectionner Authentification multiple et suivre les instructions de la section Utilisation de la console pour ajouter plusieurs serveurs d'authentification au même déploiement d'API.
Cochez ou désélectionnez la case Activer l'accès anonyme : pour indiquer si les utilisateurs finals non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routages dans le déploiement d'API.

Par défaut, cette option n'est pas sélectionnée. Si vous voulez que les utilisateurs anonymes ne puissent jamais accéder aux routages, ne sélectionnez pas cette option. Si vous sélectionnez cette option, vous devez également indiquer explicitement tous les routages auxquels l'accès anonyme est autorisé en sélectionnant Anonyme comme type d'autorisation dans la stratégie d'autorisation de chaque routage.
Sélectionnez Fonction d'autorisation dans la liste d'options Type d'authentification.
Spécifiez la fonction d'autorisation à arguments multiples à utiliser pour authentifier le jeton d'accès à arguments multiples :
- Application Oracle Functions dans <nom- compartiment> : nom de l'application dans OCI Functions qui contient la fonction d'autorisation. Vous pouvez sélectionner une application dans un autre compartiment.
- Nom de fonction : nom de la fonction d'autorisation dans OCI Functions.
Sélectionnez Fonction d'autorisation à arguments multiples pour indiquer que vous voulez transmettre des éléments d'une demande en tant que jeton d'accès à une fonction d'autorisation pouvant accepter des jetons d'accès à arguments multiples.
Dans le panneau Arguments de fonction, indiquez des variables de contexte fournissant des valeurs à transmettre à la fonction d'autorisation en tant qu'arguments avec les noms d'argument que vous entrez :
1. Indiquez une variable de contexte fournissant une valeur à transmettre à la fonction d'autorisation en tant qu'argument :
  - Table de contexte : sélectionnez dans la liste la table de contexte contenant la variable de contexte :
    - Table de contexte request.query, contenant les noms et les valeurs de paramètre de requête inclus dans la demande
    - Table de contexte request.headers, contenant les noms d'en-tête et les valeurs inclus dans la demande
    - Table de contexte request.cert, contenant une version codée Base64 du certificat présenté par un client d'API et validée lors d'une établissement de liaison mTLS
    - Table de contexte request.host, contenant le nom de l'hôte auquel la demande a été envoyée (extrait du champ d'en-tête Host dans la demande)
    - Table de contexte request.body, contenant le corps de la demande
  - Nom d'en-tête ou Nom du paramètre de requête : si vous avez sélectionné la table de contexte request.headers ou request.params, entrez le nom du paramètre d'en-tête ou de requête à transmettre à la fonction d'autorisation. Par exemple, X-Api-Key, state.
  - Nom de l'argument : entrez le nom de l'argument auquel affecter la valeur de la variable de contexte. L'argument est transmis à la fonction d'autorisation. Le nom d'argument que vous entrez doit correspondre au nom d'argument que la fonction d'autorisation s'attend à recevoir.
2. Spécifiez des variables de contexte et des arguments supplémentaires si nécessaire (sélectionnez Autre argument si nécessaire).
Vous pouvez éventuellement personnaliser le mode de mise en cache de la réponse à partir d'une fonction d'autorisation à plusieurs arguments :
1. Sélectionnez l'option Afficher les options avancées.
  Le panneau Mise en cache des résultats de fonction indique les arguments présents dans la clé de cache. La clé de cache identifie de manière unique la réponse mise en cache renvoyée par la fonction d'autorisation, à l'aide des arguments et des valeurs d'argument transmis dans la demande d'authentification d'origine. Par défaut, tous les arguments et toutes les valeurs d'argument (à l'exception d'un argument avec une valeur de la table de contexte request.body) que vous avez indiqués pour transmettre à la fonction d'autorisation sont utilisés pour créer la clé de cache.
2. Pour ajouter ou enlever des arguments de la clé de cache, sélectionnez Modifier.
3. Sélectionnez ou désélectionnez les arguments transmis à la fonction d'autorisation pour les inclure ou les exclure de la clé de cache.
Reportez-vous à Remarques sur la mise en cache des résultats de la fonction d'autorisation à arguments multiples.
Vous pouvez éventuellement personnaliser la gestion d'une réponse d'authentification en échec à partir d'une fonction d'autorisation à plusieurs arguments en configurant une stratégie d'échec de validation :
1. Sélectionnez l'option Afficher les options avancées.
  Le panneau Réponse personnalisée pour l'échec de l'authentification affiche le code de statut HTTP et le corps du message à renvoyer au client d'API si la fonction d'autorisation ne peut pas authentifier la demande. Par défaut, la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse. Reportez-vous à Remarques sur les stratégies d'échec de validation et la gestion des réponses d'authentification ayant échoué à partir de fonctions d'autorisation à arguments multiples.
2. Indiquez un code de statut (et un corps de message facultatif) à renvoyer au client API si la fonction d'autorisation ne peut pas authentifier la demande :
  - Code de statut HTTP : entrez un autre code de statut HTTP (par exemple, 500). Vous pouvez également inclure une variable de contexte pour renvoyer le code renvoyé par la fonction d'autorisation. Par exemple, si la fonction d'autorisation renvoie un code de réponse dans le paramètre responseCode, indiquez request.auth[responseCode].
  - Corps du message : entrez un corps de message. Par exemple, Unfortunately, authentication failed.Le corps du message peut inclure n'importe quelle variable de contexte (à l'exception de request.body). Par exemple, Unfortunately, authentication failed ${request.auth[my-auth-variable]}.
3. Vous pouvez éventuellement modifier les en-têtes de la réponse renvoyée par la passerelle d'API au client d'API en sélectionnant Afficher les options avancées et en indiquant une stratégie de réponse de transformation d'en-tête :
  - Pour limiter les en-têtes inclus dans une réponse, renseignez les paramètres suivants :
    - Action : filtrer.
    - Type : sélectionnez Bloquer pour enlever les en-têtes explicitement indiqués de la réponse ou Autoriser pour autoriser uniquement les en-têtes explicitement définis dans la réponse (tous les autres en-têtes sont enlevés de la réponse).
    - Noms d'en-tête : liste des en-têtes à enlever de la réponse ou à autoriser dans la réponse (en fonction du paramètre Type). Les noms que vous indiquez ne font pas la distinction entre les majuscules et les minuscules, et ne doivent être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, User-Agent.
  - Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), renseignez les paramètres suivants :
    - Action : renommer.
    - Nom d'en-tête : nom d'origine de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage. Par exemple, X-Username.
    - Nouveau nom d'en-tête : nouveau nom de l'en-tête que vous renommez. Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments contenus dans les listes ALLOW). Par exemple, X-User-ID.
  - Pour ajouter un nouvel en-tête à une réponse (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une réponse), renseignez les paramètres suivants :
    - Action : définir.
    - Comportement : si l'en-tête existe déjà, indiquez le traitement à appliquer à la valeur existante de l'en-tête :
      - Ecraser, pour remplacer la valeur existante de l'en-tête par la valeur que vous indiquez.
      - Ajouter à la fin, pour ajouter la valeur que vous indiquez à la fin de la valeur existante de l'en-tête.
      - Ignorer, pour conserver la valeur existante de l'en-tête.
    - Nom d'en-tête : nom de l'en-tête à ajouter à la réponse (ou dont vous voulez modifier la valeur). Le nom que vous indiquez ne fait pas la distinction entre les majuscules et les minuscules, et ne doit être inclus dans aucune autre stratégie de réponse de transformation pour le routage (à l'exception des éléments que vous filtrez comme autorisés). Par exemple, X-Api-Key.
    - Valeurs : valeur du nouvel en-tête (ou valeur destinée à remplacer la valeur d'un en-tête existant ou à y être ajoutée en fonction du paramètre Comportement). Vous pouvez indiquer plusieurs valeurs. La valeur que vous indiquez peut être une chaîne simple. Elle peut également inclure des variables de contexte (à l'exception de request.body) placées entre les délimiteurs ${...}. Par exemple, "value": "zyx987wvu654tsu321".
  Pour plus d'informations sur les stratégies de réponse de transformation d'en-tête, reportez-vous à Ajout de stratégies de réponse de transformation d'en-tête.
Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.
Dans la section Routage 1, spécifiez le premier routage du déploiement d'API qui met en correspondance un chemin et des méthodes avec un service back-end :
- Chemin : chemin pour les appels d'API utilisant les méthodes répertoriées vers le service back-end. Le chemin d'accès que vous spécifiez doit remplir les conditions suivantes :
  - Il est relatif au préfixe de chemin de déploiement.
  - Il doit être précédé d'une barre oblique (/). Il peut également consister en une unique barre oblique.
  - Il peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes), ainsi que se terminer par une barre oblique.
  - Il peut inclure des caractères alphanumériques en majuscules et minuscules.
  - Il peut inclure les caractères spéciaux $ - _ . + ! * ' ( ) , % ; : @ & = .
  - Il peut inclure des paramètres et des caractères génériques (reportez-vous à Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : méthodes acceptées par le service back-end, séparées par des virgules. Par exemple, GET, PUT.
- Ajouter un seul back-end : ou Ajouter plusieurs back-ends : indique si toutes les demandes doivent être acheminées vers le même back-end ou si elles doivent l'être vers d'autres back-ends en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous souhaitez utiliser un back-end unique. Sélectionnez donc Ajouter un back-end unique. Si vous souhaitez utiliser des back-ends différents, vous pouvez également sélectionner Ajouter plusieurs back-ends et suivre les instructions fournies dans Utilisation de la console pour ajouter une sélection de back-end dynamique à une spécification de déploiement d'API.
- Type de back-end : type du service back-end :
  - HTTP : pour un back-end HTTP, vous devez également spécifier une URL et des détails d'expiration. Vous devez aussi indiquer si la vérification SSL doit être désactivée (reportez-vous à Ajout d'une URL HTTP ou HTTPS en tant que back-end de passerelle d'API).
  - Oracle Functions : pour un back-end OCI Functions, vous devez également indiquer l'application et la fonction (reportez-vous à Ajout d'une fonction dans OCI Functions en tant que back-end de passerelle d'API).
  - Réponse par défaut : pour un back-end de réponse par défaut, vous devez également indiquer le code de statut HTTP, le contenu du corps de la réponse et des champs d'en-tête HTTP (reportez-vous à Ajout de réponses par défaut en tant que back-end de passerelle d'API).
Pour indiquer une stratégie d'autorisation qui s'applique à un routage individuel, sélectionnez Afficher les stratégies de demande de routage, sélectionnez le bouton Ajouter en regard du champ Autorisation et indiquez les éléments suivants :
- Type d'autorisation : mode d'octroi de l'accès au routage. Indiquez l'une des valeurs suivantes :
  - Tous : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés, à condition que la fonction d'autorisation renvoie également l'une des portées d'accès indiquées dans le champ Portée autorisée. Dans ce cas, l'option Activer l'accès anonyme de la stratégie d'authentification n'a aucun effet.
  - Anonyme : autorise l'accès à tous les utilisateurs finals, même s'ils n'ont pas été authentifiés par la fonction d'autorisation. Dans ce cas, vous devez avoir sélectionné l'option Activer l'accès anonyme de la stratégie d'authentification.
  - Authentification uniquement : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés par la fonction d'autorisation. Dans ce cas, l'option Activer l'accès anonyme de la stratégie d'authentification n'a aucun effet.
- Portée autorisée : si vous avez sélectionné N'importe lequel pour Type d'autorisation, entrez la liste des chaînes, séparées par des virgules, correspondant aux portées d'accès renvoyées par la fonction d'autorisation. L'accès ne sera octroyé qu'aux utilisateurs finals qui ont été authentifiés si la fonction d'autorisation renvoie l'une des portées d'accès que vous indiquez. Par exemple, read:hello
Remarque

Si vous n'incluez pas de stratégie d'autorisation pour un routage particulier, l'accès est accordé comme si une stratégie existait et que Type d'autorisation était défini sur Authentification uniquement. En d'autres termes, quel que soit le paramétrage de l'option Activer l'accès anonyme de la stratégie d'authentification, les conditions suivantes sont vraies :
- Seuls les utilisateurs finals authentifiés peuvent accéder au routage.
- Tous les utilisateurs finals authentifiés peuvent accéder au routage, quelles que soient les portées d'accès renvoyées par la fonction d'autorisation.
- Les utilisateurs finals anonymes ne peuvent pas accéder au routage.
Sélectionnez Appliquer les modifications, puis Suivant afin de vérifier les détails saisis pour le déploiement d'API.
Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation multi-arguments

Afin d'ajouter des stratégies de demande d'authentification et d'autorisation pour des jetons d'accès à plusieurs arguments à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle vous voulez ajouter la fonctionnalité d'authentification et d'autorisation ou créez une spécification de déploiement d'API (reportez-vous à Création d'une spécification de déploiement d'API).

Au minimum, la spécification de déploiement d'API doit inclure une section routes contenant les éléments suivants :
- Un chemin. Par exemple, /hello.
- Des méthodes. Par exemple, GET.
- La définition d'un back-end. Par exemple, une URL ou l'OCID d'une fonction dans OCI Functions.
Par exemple, la spécification de déploiement d'API de base suivante définit une fonction simple sans serveur Hello World dans OCI Functions en tant que back-end unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une stratégie de demande authentication qui s'applique à tous les routages de la spécification de déploiement d'API :
1. Insérez une section requestPolicies avant la section routes, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Ajoutez la stratégie authentication suivante à la nouvelle section requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      "parameters": {
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>"
      },
      "cacheKey": [
        "<cache-key-argument-n>", "<cache-key-argument-n>"
      ]
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - <type-value> est le type d'authentification. Pour utiliser une fonction d'autorisation à des fins d'authentification, indiquez CUSTOM_AUTHENTICATION.
  - "isAnonymousAccessAllowed": <true|false> indique éventuellement si les utilisateurs finals non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routages dans la spécification de déploiement d'API. Si vous voulez que les utilisateurs finals anonymes ne puissent jamais accéder aux routages, définissez cette propriété sur false. Si vous n'incluez pas cette propriété dans la stratégie authentication, la valeur par défaut false est utilisée. Si vous incluez cette propriété et que vous la définissez sur true, vous devez également indiquer explicitement les routages auxquels l'accès anonyme est autorisé en définissant la propriété type sur "ANONYMOUS" dans la stratégie authorization de chaque routage.
  - <function-ocid> est l'OCID de la fonction d'autorisation déployée vers OCI Functions.
  - <argument-n> est le nom de l'argument auquel affecter la valeur d'une seule variable de contexte. L'argument est transmis à la fonction d'autorisation. Le nom d'argument que vous entrez doit correspondre au nom d'argument que la fonction d'autorisation attend de recevoir. Vous pouvez inclure plusieurs paires argument-contexte.
  - <context-variable> est une variable de contexte dont vous voulez affecter la valeur à l'argument correspondant. <context-variable> doit être au format <context-table-name> ou <context-table-name>[<key>], où <context-table-name> est l'une des valeurs suivantes :
    - request.query, table de contexte contenant les noms et les valeurs de paramètre de requête inclus dans la demande. Si vous voulez indiquer un paramètre de requête, vous devez indiquer à la fois la table de contexte request.query et le nom du paramètre de requête en tant que clé, au format request.query[<query-parameter-name>]. Par exemple, request.query[state].
    - request.headers, table de contexte contenant les noms d'en-tête et les valeurs inclus dans la demande. Pour indiquer un en-tête, vous devez indiquer à la fois la table de contexte request.headers et le nom de l'en-tête en tant que clé, au format request.headers[<header-name>]. Par exemple, request.headers[X-Api-Key].
    - Table de contexte request.cert, contenant une version codée Base64 du certificat présenté par un client d'API et validée lors d'une établissement de liaison mTLS
    - request.host, table de contexte contenant le nom de l'hôte auquel la demande a été envoyée (extrait du champ d'en-tête Host dans la demande)
    - request.body, table de contexte contenant le corps de la demande.
  - "cacheKey": ["<cache-key-argument-n>", "<cache-key-argument-n>"] limite éventuellement la clé de cache à l'utilisation des arguments que vous indiquez uniquement. La clé de cache identifie de manière unique la réponse mise en cache renvoyée par la fonction d'autorisation, à l'aide d'arguments et de valeurs d'argument transmis dans la demande d'authentification d'origine. Par défaut, tous les arguments et valeurs d'argument (à l'exception d'un argument avec une valeur de la table de contexte request.body) de la liste parameters: {…} sont utilisés pour créer la clé de cache. Un argument que vous indiquez pour <cache-key-argument-n> doit être l'un des arguments de la liste parameters: {…}. Reportez-vous à Remarques sur la mise en cache des résultats de la fonction d'autorisation à arguments multiples.
3. Ajoutez éventuellement un élément validationFailurePolicy à la section de stratégie authentication :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      "parameters": {
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>"
      },
      "cacheKey": [
        "<cache-key-argument-n>", "<cache-key-argument-n>"
      ],
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "<alternative-response-code>",
        "responseMessage": "<custom-message-body>",
        "responseTransformations": {
          "headerTransformations": {
            <valid-header-transformation-response-policy>
          }
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - "validationFailurePolicy": {…} vous permet éventuellement de modifier le code de statut HTTP, le corps du message et les en-têtes dans la réponse au client d'API si la fonction d'autorisation ne peut pas authentifier une demande. Par défaut, la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse. Reportez-vous à Remarques sur les stratégies d'échec de validation et la gestion des réponses d'authentification en échec à partir des fonctions d'autorisation à arguments multiples.
  - <policy-type> est le type de stratégie d'échec de validation. Pour modifier la réponse, indiquez MODIFY_RESPONSE.
  - "responseCode": "<alternative-response-code>" indique un autre code de statut HTTP. Par exemple, "responseCode": "500". Vous pouvez également inclure une variable de contexte pour renvoyer le code renvoyé par la fonction d'autorisation. Par exemple, si la fonction d'autorisation renvoie un code de réponse dans le paramètre responseCode, indiquez "request.auth[responseCode]".
  - "responseMessage": "<custom-message-body>" indique le contenu à inclure dans le corps du message. Par exemple, "responseMessage": "Unfortunately, authentication failed.". Le corps du message peut inclure n'importe quelle variable de contexte (à l'exception de request.body). Par exemple, "responseMessage": "Unfortunately, authentication failed ${request.auth[my-auth-variable]}".
  - "headerTransformations": {<valid-header-transformation-response-policy>} est une stratégie de réponse de transformation d'en-tête valide. Reportez-vous à Modification d'un fichier JSON pour ajouter des stratégies de réponse de transformation d'en-tête.
Ajoutez une stratégie de demande authorization à chaque routage dans la spécification de déploiement d'API :
1. Insérez une section requestPolicies après la section backend du premier routage, s'il n'en existe pas déjà une. Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Ajoutez la stratégie authorization suivante à la section requestPolicies :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}
```
  où :
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indique comment accorder l'accès au routage :
    - "AUTHENTICATION_ONLY" : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la stratégie authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANY_OF" : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés, à condition que la fonction d'autorisation renvoie également l'une des portées d'accès que vous avez indiquées dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la stratégie authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANONYMOUS" : accorde l'accès à tous les utilisateurs finals, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez définir explicitement la propriété "isAnonymousAccessAllowed" sur true dans la stratégie authentication de la spécification de déploiement d'API.
  - "allowedScope": [ "<scope>" ] est une liste de chaînes séparées par des virgules correspondant aux portées d'accès renvoyées par la fonction d'autorisation. Dans ce cas, vous devez définir la propriété type sur "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est définie sur "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Si vous indiquez plusieurs portées, l'accès au routage est accordé si l'une des portées que vous indiquez est renvoyée par la fonction d'autorisation.
  Par exemple, la stratégie de demande suivante définit un routage /hello auquel seuls les utilisateurs finals authentifiés avec la portée read:hello peuvent accéder :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
```
3. Ajoutez une stratégie de demande authorization pour tous les routages restants dans la spécification de déploiement d'API.
Remarque

Si vous n'incluez pas de stratégie authorization pour un routage particulier, l'accès est accordé comme si une stratégie existait et que la propriété type était définie sur "AUTHENTICATION_ONLY". En d'autres termes, quel que soit le paramètre de la propriété isAnonymousAccessAllowed dans la stratégie authentication de la spécification de déploiement d'API, les conditions suivantes sont vraies :
- Seuls les utilisateurs finals authentifiés peuvent accéder au routage.
- Tous les utilisateurs finals authentifiés peuvent accéder au routage, quelles que soient les portées d'accès renvoyées par la fonction d'autorisation.
- Les utilisateurs finals anonymes ne peuvent pas accéder au routage.
Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.
Utilisez 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 Télécharger une API existante,
- spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.
Pour plus d'informations, reportez-vous à 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.
(Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Remarques sur l'utilisation de fonctions d'autorisation à arguments multiples et de jetons d'accès

Remarques sur la mise en cache des résultats de la fonction d'autorisation à arguments multiples

Lorsque vous utilisez des fonctions d'autorisation, la passerelle d'API met en cache en interne la réponse de la fonction d'autorisation par défaut. La mise en cache de la réponse permet de la réutiliser ultérieurement pour répondre à une demande d'authentification similaire, sans appeler à nouveau la fonction d'autorisation.

Pour identifier de manière unique une réponse mise en cache renvoyée par une fonction d'autorisation pour une demande d'authentification, la passerelle d'API utilise une clé de cache dérivée des arguments et des valeurs d'argument transmis à la fonction d'autorisation qui a généré la réponse. Si les valeurs d'argument et d'argument d'une demande d'authentification ultérieure correspondent à une clé de cache, la réponse mise en cache est utilisée au lieu d'appeler inutilement la fonction d'autorisation.

Dans le cas des fonctions d'autorisation à arguments multiples, tous les arguments et valeurs d'argument (à l'exception d'un argument avec une valeur de la table de contexte request.body) transmis à la fonction d'autorisation sont utilisés par défaut pour créer la clé de cache. Toutefois, vous pouvez personnaliser les arguments et les valeurs d'argument utilisés pour créer la clé de cache. Par conséquent, la clé de cache inclut uniquement les arguments et les valeurs d'argument que vous indiquez. Notez que si vous supprimez des arguments et des valeurs d'argument de la clé de cache, vous risquez d'introduire le risque qu'une demande d'authentification entrante non valide corresponde à la clé de cache d'une réponse précédente à une demande authentifiée avec succès. Supprimez uniquement les arguments de la clé de cache si vous êtes sûr qu'ils ne jouent aucun rôle dans l'authentification de la demande.

Remarques sur les stratégies d'échec de validation et la gestion des réponses d'authentification en échec à partir des fonctions d'autorisation à arguments multiples

Lorsque vous utilisez une fonction d'autorisation à arguments multiples, vous pouvez définir une stratégie d'échec de validation. Une stratégie d'échec de validation vous permet de personnaliser le code de statut HTTP, le message et les en-têtes de réponse que la passerelle d'API envoie à un client d'API en cas d'échec de la réponse d'authentification d'une fonction d'autorisation à plusieurs arguments.

Une fonction d'autorisation à arguments multiples doit renvoyer une réponse HTTP 200 (avec le corps JSON de la réponse contenant "active": false et un en-tête WWW-Authenticate) si un jeton d'accès a été vérifié avec un fournisseur d'identités, mais que le fournisseur d'identités a déterminé que le jeton n'est pas valide,

Si la fonction d'autorisation renvoie une réponse HTTP 200 avec "active": false dans le corps de la réponse, la passerelle d'API envoie par défaut un code de statut HTTP 401 au client d'API (ainsi que l'en-tête WWW-Authenticate dans la réponse). Toutefois, vous pouvez définir une stratégie d'échec de validation pour indiquer un autre code de statut HTTP à renvoyer et pour indiquer un message personnalisé à renvoyer dans le corps de la réponse.

Vous pouvez également inclure une stratégie de réponse de transformation d'en-tête dans une stratégie d'échec de validation pour modifier l'en-tête de la réponse renvoyée par la passerelle d'API au client d'API. En incluant une stratégie de réponse de transformation d'en-tête dans une stratégie d'échec de validation, vous pouvez :

limiter les en-têtes inclus dans une réponse
modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale)
ajouter un nouvel en-tête à une réponse (ou modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une réponse)

Pour plus d'informations sur l'ajout d'une stratégie d'échec de validation, reportez-vous à Modification d'un fichier JSON pour ajouter des stratégies de demande pour l'authentification et l'autorisation multi-arguments.

Exemple de spécification de déploiement à l'aide de jetons d'accès multi-arguments

La spécification de déploiement d'API suivante définit :

Stratégie de demande d'authentification qui appelle une fonction d'autorisation à arguments multiples pour effectuer l'authentification.
Stratégie de demande d'autorisation qui spécifie ce que les utilisateurs finaux authentifiés peuvent faire.

{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "isAnonymousAccessAllowed": true,
      "parameters": {
        "xapikey": "request.headers[X-Api-Key]",
        "referer": "request.headers[Referer]",
        "state": "request.query[state]",
        "city": "request.query[city]",
        "cert": "request.cert",
        "body": "request.body",
        "host": "request.host"
        },
      "cacheKey": [
        "xapikey", "referer"
        ],
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "request.auth[responseCode]",
        "responseMessage": "Unfortunately, authentication failed.",
        "responseTransformations": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "Location",
                "values": [
                  "${request.auth[location]}"
                  ]
                }
              ]
            },
          "filterHeaders": {
            "type": "BLOCK",
            "items": [
              {
                "name": "topSecret"
                }
              ]
            }
          }
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}

Stratégie de demande d'authentification dans cette spécification de déploiement d'API :

Spécifie la fonction d'autorisation à arguments multiples à appeler pour effectuer l'authentification et définit les arguments xapikey, referer, state, city, cert, body et host à transmettre à la fonction d'autorisation. Les valeurs de ces arguments sont obtenues à partir de variables de contexte qui ont des valeurs de la demande d'origine.
Définit une clé de cache personnalisée pour identifier de manière unique la réponse en cache renvoyée par la fonction d'autorisation. Plutôt que d'utiliser la clé de cache par défaut (qui inclut tous les arguments envoyés à la fonction d'autorisation, et est recommandée), cette stratégie de demande d'authentification indique que la clé de cache doit contenir uniquement les valeurs des arguments xapikey et referrer transmis à la fonction d'autorisation.
Inclut une stratégie d'échec de validation qui modifie la réponse d'échec de validation par défaut pour remplacer le code de statut HTTP 401 par défaut par la valeur de la variable de contexte request.auth[responseCode]. La variable de contexte request.auth[responseCode] a la valeur d'un paramètre d'authentification (dans ce cas, nommé responseCode) renvoyé par la fonction d'autorisation. De même, le message d'échec de validation par défaut est remplacé par une chaîne de message personnalisée ("Unfortunately, authentication failed.").
Inclut une stratégie de demande de transformation d'en-tête dans la stratégie d'échec de validation qui ajoute l'en-tête location à la réponse d'échec de validation. L'en-tête location reçoit la valeur de la variable de contexte request.auth[location], qui a la valeur d'un paramètre d'authentification (dans ce cas, nommé location) renvoyé par la fonction d'autorisation. La stratégie de demande de transformation d'en-tête enlève également les en-têtes nommés topSecret de la réponse.

La stratégie de demande d'autorisation dans cette spécification de déploiement d'API autorise uniquement les utilisateurs finaux authentifiés par la fonction d'autorisation et avec la portée read:hello à accéder au routage /hello.

Ajout de stratégies de demande d'authentification et d'autorisation pour les jetons d'accès à un seul argument et les fonctions d'autorisation

Vous pouvez ajouter des stratégies de demande pour fournir une authentification et une autorisation à l'aide de jetons d'accès à argument unique et de fonctions d'autorisation à argument unique en :

Remarque

Oracle recommande d'utiliser des fonctions d'autorisation à arguments multiples plutôt que des fonctions d'autorisation à argument unique en raison de leur polyvalence supplémentaire. Des fonctions d'autorisation à argument unique ont été fournies dans les versions précédentes et continuent d'être prises en charge. Cependant, étant donné que les fonctions d'autorisation à arguments multiples peuvent également accepter des jetons d'accès à argument unique contenus dans les en-têtes de demande et le paramètre de requête, il n'y a aucune raison de créer de nouvelles fonctions d'autorisation à arguments uniques. En outre, les fonctions d'autorisation à argument unique seront abandonnées dans une prochaine version.

Utilisation de la console afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation à un seul argument

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

Pour plus d'informations, reportez-vous à 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.
Sélectionnez Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour indiquer que vous souhaitez utiliser un serveur d'authentification unique pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d'authentification. Si vous souhaitez utiliser plusieurs serveurs d'authentification, vous pouvez également sélectionner Authentification multiple et suivre les instructions de la section Utilisation de la console pour ajouter plusieurs serveurs d'authentification au même déploiement d'API.
Cochez ou désélectionnez la case Activer l'accès anonyme : pour indiquer si les utilisateurs finals non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routages dans le déploiement d'API.

Par défaut, cette option n'est pas sélectionnée. Si vous voulez que les utilisateurs anonymes ne puissent jamais accéder aux routages, ne sélectionnez pas cette option. Si vous sélectionnez cette option, vous devez également indiquer explicitement tous les routages auxquels l'accès anonyme est autorisé en sélectionnant Anonyme comme type d'autorisation dans la stratégie d'autorisation de chaque routage.
Sélectionnez Fonction d'autorisation dans la liste d'options Type d'authentification.
Indiquez la fonction d'autorisation à argument unique à utiliser pour authentifier le jeton d'accès à argument unique :
- Application Oracle Functions dans <nom- compartiment> : nom de l'application dans OCI Functions qui contient la fonction d'autorisation. Vous pouvez sélectionner une application dans un autre compartiment.
- Nom de fonction : nom de la fonction d'autorisation dans OCI Functions.
Sélectionnez Fonction d'autorisation à argument unique pour indiquer que vous voulez transmettre un jeton d'accès à argument unique dans un paramètre d'en-tête ou de requête à une fonction d'autorisation à argument unique.
Dans le panneau Jeton d'accès, identifiez le jeton d'accès à utiliser pour l'authentification :
- Emplacement du jeton : sélectionnez En-tête ou Paramètre de requête pour indiquer l'emplacement du jeton d'accès dans la demande.
- Nom d'en-tête de jeton ou Nom de paramètre de jeton : selon l'emplacement du jeton d'accès, entrez le nom du paramètre d'en-tête ou de requête contenant le jeton d'accès.
Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.
Dans la section Routage 1, spécifiez le premier routage du déploiement d'API qui met en correspondance un chemin et des méthodes avec un service back-end :
- Chemin : chemin pour les appels d'API utilisant les méthodes répertoriées vers le service back-end. Le chemin d'accès que vous spécifiez doit remplir les conditions suivantes :
  - Il est relatif au préfixe de chemin de déploiement.
  - Il doit être précédé d'une barre oblique (/). Il peut également consister en une unique barre oblique.
  - Il peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes), ainsi que se terminer par une barre oblique.
  - Il peut inclure des caractères alphanumériques en majuscules et minuscules.
  - Il peut inclure les caractères spéciaux $ - _ . + ! * ' ( ) , % ; : @ & = .
  - Il peut inclure des paramètres et des caractères génériques (reportez-vous à Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : méthodes acceptées par le service back-end, séparées par des virgules. Par exemple, GET, PUT.
- Ajouter un seul back-end : ou Ajouter plusieurs back-ends : indique si toutes les demandes doivent être acheminées vers le même back-end ou si elles doivent l'être vers d'autres back-ends en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous souhaitez utiliser un back-end unique. Sélectionnez donc Ajouter un back-end unique. Si vous souhaitez utiliser des back-ends différents, vous pouvez également sélectionner Ajouter plusieurs back-ends et suivre les instructions fournies dans Utilisation de la console pour ajouter une sélection de back-end dynamique à une spécification de déploiement d'API.
- Type de back-end : type du service back-end :
  - HTTP : pour un back-end HTTP, vous devez également spécifier une URL et des détails d'expiration. Vous devez aussi indiquer si la vérification SSL doit être désactivée (reportez-vous à Ajout d'une URL HTTP ou HTTPS en tant que back-end de passerelle d'API).
  - Oracle Functions : pour un back-end OCI Functions, vous devez également indiquer l'application et la fonction (reportez-vous à Ajout d'une fonction dans OCI Functions en tant que back-end de passerelle d'API).
  - Réponse par défaut : pour un back-end de réponse par défaut, vous devez également indiquer le code de statut HTTP, le contenu du corps de la réponse et des champs d'en-tête HTTP (reportez-vous à Ajout de réponses par défaut en tant que back-end de passerelle d'API).
Pour indiquer une stratégie d'autorisation qui s'applique à un routage individuel, sélectionnez Afficher les stratégies de demande de routage, sélectionnez le bouton Ajouter en regard du champ Autorisation et indiquez les éléments suivants :
- Type d'autorisation : mode d'octroi de l'accès au routage. Indiquez l'une des valeurs suivantes :
  - Tous : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés, à condition que la fonction d'autorisation renvoie également l'une des portées d'accès indiquées dans le champ Portée autorisée. Dans ce cas, l'option Activer l'accès anonyme de la stratégie d'authentification n'a aucun effet.
  - Anonyme : autorise l'accès à tous les utilisateurs finals, même s'ils n'ont pas été authentifiés par la fonction d'autorisation. Dans ce cas, vous devez avoir sélectionné l'option Activer l'accès anonyme de la stratégie d'authentification.
  - Authentification uniquement : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés par la fonction d'autorisation. Dans ce cas, l'option Activer l'accès anonyme de la stratégie d'authentification n'a aucun effet.
- Portée autorisée : si vous avez sélectionné N'importe lequel pour Type d'autorisation, entrez la liste des chaînes, séparées par des virgules, correspondant aux portées d'accès renvoyées par la fonction d'autorisation. L'accès ne sera octroyé qu'aux utilisateurs finals qui ont été authentifiés si la fonction d'autorisation renvoie l'une des portées d'accès que vous indiquez. Par exemple, read:hello
Remarque

Si vous n'incluez pas de stratégie d'autorisation pour un routage particulier, l'accès est accordé comme si une stratégie existait et que Type d'autorisation était défini sur Authentification uniquement. En d'autres termes, quel que soit le paramétrage de l'option Activer l'accès anonyme de la stratégie d'authentification, les conditions suivantes sont vraies :
- Seuls les utilisateurs finals authentifiés peuvent accéder au routage.
- Tous les utilisateurs finals authentifiés peuvent accéder au routage, quelles que soient les portées d'accès renvoyées par la fonction d'autorisation.
- Les utilisateurs finals anonymes ne peuvent pas accéder au routage.
Sélectionnez Suivant afin de vérifier les détails saisis pour le déploiement d'API.
Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation à un seul argument

Afin d'ajouter des stratégies de demande d'authentification et d'autorisation pour des jetons d'accès à argument unique à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle vous voulez ajouter la fonctionnalité d'authentification et d'autorisation ou créez une spécification de déploiement d'API (reportez-vous à Création d'une spécification de déploiement d'API).

Au minimum, la spécification de déploiement d'API doit inclure une section routes contenant les éléments suivants :
- Un chemin. Par exemple, /hello.
- Des méthodes. Par exemple, GET.
- La définition d'un back-end. Par exemple, une URL ou l'OCID d'une fonction dans OCI Functions.
Par exemple, la spécification de déploiement d'API de base suivante définit une fonction simple sans serveur Hello World dans OCI Functions en tant que back-end unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une stratégie de demande authentication qui s'applique à tous les routages de la spécification de déploiement d'API :
1. Insérez une section requestPolicies avant la section routes, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Ajoutez la stratégie authentication suivante à la nouvelle section requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - <type-value> est le type d'authentification. Pour utiliser une fonction d'autorisation à des fins d'authentification, indiquez CUSTOM_AUTHENTICATION.
  - "isAnonymousAccessAllowed": <true|false> indique éventuellement si les utilisateurs finals non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routages dans la spécification de déploiement d'API. Si vous voulez que les utilisateurs finals anonymes ne puissent jamais accéder aux routages, définissez cette propriété sur false. Si vous n'incluez pas cette propriété dans la stratégie authentication, la valeur par défaut false est utilisée. Si vous incluez cette propriété et que vous la définissez sur true, vous devez également indiquer explicitement les routages auxquels l'accès anonyme est autorisé en définissant la propriété type sur "ANONYMOUS" dans la stratégie authorization de chaque routage.
  - <function-ocid> est l'OCID de la fonction d'autorisation déployée vers OCI Functions.
  - <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indique s'il s'agit d'un en-tête de demande qui contient le jeton d'accès (et, le cas échéant, le nom de l'en-tête) ou d'un paramètre de requête contenant le jeton d'accès (et, le cas échéant, le nom du paramètre de requête). Vous pouvez spécifier "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mais pas les deux.
  Par exemple, la stratégie authentication suivante spécifie une fonction OCI destinée à valider le jeton d'accès dans l'en-tête de demande d'autorisation :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une stratégie de demande authorization à chaque routage dans la spécification de déploiement d'API :
1. Insérez une section requestPolicies après la section backend du premier routage, s'il n'en existe pas déjà une. Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Ajoutez la stratégie authorization suivante à la section requestPolicies :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}
```
  où :
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indique comment accorder l'accès au routage :
    - "AUTHENTICATION_ONLY" : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la stratégie authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANY_OF" : n'accorde l'accès qu'aux utilisateurs finals qui ont été authentifiés, à condition que la fonction d'autorisation renvoie également l'une des portées d'accès que vous avez indiquées dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la stratégie authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANONYMOUS" : accorde l'accès à tous les utilisateurs finals, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez définir explicitement la propriété "isAnonymousAccessAllowed" sur true dans la stratégie authentication de la spécification de déploiement d'API.
  - "allowedScope": [ "<scope>" ] est une liste de chaînes séparées par des virgules correspondant aux portées d'accès renvoyées par la fonction d'autorisation. Dans ce cas, vous devez définir la propriété type sur "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est définie sur "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Si vous indiquez plusieurs portées, l'accès au routage est accordé si l'une des portées que vous indiquez est renvoyée par la fonction d'autorisation.
  Par exemple, la stratégie de demande suivante définit un routage /hello auquel seuls les utilisateurs finals authentifiés avec la portée read:hello peuvent accéder :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
```
3. Ajoutez une stratégie de demande authorization pour tous les routages restants dans la spécification de déploiement d'API.
Remarque

Si vous n'incluez pas de stratégie authorization pour un routage particulier, l'accès est accordé comme si une stratégie existait et que la propriété type était définie sur "AUTHENTICATION_ONLY". En d'autres termes, quel que soit le paramètre de la propriété isAnonymousAccessAllowed dans la stratégie authentication de la spécification de déploiement d'API, les conditions suivantes sont vraies :
- Seuls les utilisateurs finals authentifiés peuvent accéder au routage.
- Tous les utilisateurs finals authentifiés peuvent accéder au routage, quelles que soient les portées d'accès renvoyées par la fonction d'autorisation.
- Les utilisateurs finals anonymes ne peuvent pas accéder au routage.
Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.
Utilisez 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 Télécharger une API existante,
- spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.
Pour plus d'informations, reportez-vous à 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.
(Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Documentation Oracle Cloud Infrastructure