Validation des jetons pour ajouter l'authentification et l'autorisation aux déploiements d'API

Vous pouvez ajouter des fonctionnalités d'authentification et d'autorisation à une passerelle d'API en demandant à la passerelle d'API elle-même de valider les jetons inclus dans une demande (comme décrit dans cette rubrique). Vous pouvez également demander à la passerelle d'API de transmettre un jeton d'accès à plusieurs arguments ou à un seul argument inclus dans une demande à une fonction d'autorisation déployée sur OCI Functions pour validation (comme décrit dans Transmission de jetons aux fonctions d'autorisation pour ajouter l'authentification et l'autorisation aux déploiements d'API).

Pour que la passerelle d'API elle-même valide le jeton inclus dans une demande, vous créez une politique de demande d'authentification de type TOKEN_AUTHENTICATION. Les jetons que vous utilisez pour contrôler l'accès aux API sont souvent, mais pas toujours, des jetons Web JSON (JWT).

Lorsque vous utilisez une politique TOKEN_AUTHENTICATION, vous autorisez un déploiement d'API à utiliser des jetons pour l'authentification et l'autorisation en incluant deux types de politique de demande différents dans la spécification de déploiement d'API :

Politique de demande d'authentification pour l'ensemble du déploiement d'API qui spécifie l'utilisation de jetons, notamment comment les valider et si les utilisateurs finaux non authentifiés peuvent accéder aux routes du déploiement d'API.
Politique de demande d'autorisation pour chaque route qui spécifie les opérations qu'un utilisateur final est autorisé à effectuer, éventuellement en fonction des valeurs spécifiées pour la revendication scope d'un JWT.

Vous pouvez ajouter des politiques de demande d'authentification et d'autorisation à une spécification de déploiement d'API comme suit :

Utilisation de la console.
En modifiant un fichier JSON.

Note

Dans les versions antérieures, vous créiez des politiques de demande d'authentification de type JWT_AUTHENTICATION pour utiliser des JWT pour l'authentification. Les politiques de demande d'authentification JWT_AUTHENTICATION existantes sont toujours prises en charge (voir Notes sur l'utilisation des politiques de demande JWT_AUTHENTICATION). Toutefois, si vous créez de nouvelles politiques de demande d'authentification pour authentifier les JWT, nous vous recommandons de créer des politiques de demande d'authentification en tant que politiques TOKEN_AUTHENTICATION. L'utilisation des politiques TOKEN_AUTHENTICATION vous permet de :

Validez les jetons JWT et les jetons non JWT.
Valider les jetons à l'aide d'un fournisseur d'identités pour obtenir un point d'extrémité d'introspection.
Spécifiez les politiques d'échec de validation, notamment la génération d'un nouveau jeton JWT en cas de jeton JWT non valide ou manquant dans la demande initiale.

Que se passe-t-il lors de l'authentification par jeton?

Lorsqu'une passerelle d'API reçoit une demande d'un client d'API et que vous avez spécifié une politique d'authentification de jeton, la passerelle d'API localise un jeton (par exemple, dans un en-tête de jeton) et l'utilise.

Vous spécifiez comment la passerelle d'API valide le jeton qu'elle a obtenu en définissant la politique de validation de la politique d'authentification de jeton comme étant l'un des types suivants :

Point d'extrémité d'introspection OAuth 2.0 : Spécifiez ce type de politique de validation si vous voulez que la passerelle d'API valide un jeton JWT ou non JWT avec le point d'extrémité d'introspection d'un fournisseur d'identités. Vous devez spécifier l'URL de détection du fournisseur d'identités à partir duquel obtenir le point d'extrémité d'introspection. Dans ce cas, la passerelle d'API transmet les données d'identification du client (ID client, ainsi que la clé secrète client extraite du service de chambre forte) au fournisseur d'identités pour valider le jeton. Le jeton est validé sans l'utilisation de clés publiques. Pour accélérer la validation future, vous pouvez spécifier que la passerelle d'API doit mettre en mémoire cache la réponse du point d'extrémité d'introspection, pendant 1 heure (valeur par défaut) et 24 heures. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous voulez ce comportement, incluez une politique de validation de type REMOTE_DISCOVERY.
JWKS distant : Spécifiez ce type de politique de validation si vous voulez que la passerelle d'API utilise des clés de vérification publiques extraites d'un fournisseur d'identités lors de l'exécution pour vérifier un JWT. Dans ce cas, la passerelle d'API contacte le fournisseur d'identités pour vérifier le JWT. Le fournisseur d'identités agit en tant que serveur d'autorisation. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous voulez ce comportement, incluez une politique de validation de type REMOTE_JWKS.
Clés statiques : Spécifiez ce type de politique de validation si vous voulez que la passerelle d'API utilise des clés de vérification publiques déjà émises par un fournisseur d'identités (appelées "clés statiques") pour vérifier un JWT. Dans ce cas, la passerelle d'API peut vérifier JWT localement au moment de l'exécution sans avoir à communiquer avec le fournisseur d'identités. Il en résulte une validation plus rapide des jetons. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous voulez ce comportement, incluez une politique de validation de type STATIC_KEYS

Si la validation réussit, la passerelle d'API achemine la demande vers le point d'extrémité d'API approprié.

Si la validation échoue en raison d'un jeton non valide ou manquant dans la demande initiale, vous spécifiez le comportement de la passerelle d'API en définissant la politique d'échec de validation de la politique d'authentification de jeton comme étant l'un des types suivants :

Par défaut (HTTP 401 non autorisé) : Spécifiez ce type de politique d'échec de validation si vous voulez que la passerelle d'API retourne une réponse HTTP-401 au client d'API. Il s'agit de la réponse par défaut. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous souhaitez ce comportement, n'incluez tout simplement pas de politique d'échec de validation.
Réponse personnalisée : Spécifiez ce type de politique d'échec de validation si vous voulez que la passerelle d'API retourne une réponse alternative (une réponse modifiée) au client d'API, au lieu d'une réponse HTTP-401. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous voulez ce comportement, incluez une politique d'échec de validation de type MODIFY_RESPONSE.
OAuth 2.0 : Spécifiez ce type de politique d'échec de validation si vous voulez que la passerelle d'API obtienne un jeton JWT nouveau et valide du fournisseur d'identités pour les demandes GET (qui ont d'abord stocké en toute sécurité les paramètres d'interrogation de la demande initiale). Pour les demandes PUT et POST, vous pouvez spécifier un chemin relatif dans le déploiement d'API courant vers lequel rediriger les clients d'API. À l'aide de ce type de politique d'échec de validation, vous pouvez également définir un élément dorsal de déconnexion pour supprimer les témoins de session associés, révoquer les jetons en appelant le point d'extrémité de session du fournisseur d'identités et rediriger vers une URL de post-déconnexion autorisée. Si vous définissez la spécification de déploiement d'API dans un fichier JSON et que vous voulez ce comportement, incluez une politique d'échec de validation de type OAUTH2.
Notez que les politiques d'échec de validation de type OAuth 2.0 prennent actuellement en charge uniquement le flux d'autorisation OpenID Connect et uniquement la génération de jeton JWT (voir Notes sur OAuth 2.0 et OpenID Connect). Dans le cas du flux d'autorisation OpenID Connect, deux jetons nommés id_token (toujours encodés par JWT) et access_token (peuvent être encodés par JWT) sont retournés. La passerelle d'API enregistre les valeurs de jeton dans les variables de contexte request.auth[id_token] et request.auth[access_token], ainsi que les revendications personnalisées dans les variables de contexte request.auth[id_token_claims][<claim-name>] et request.auth[access_token_claims][<claim-name>] respectivement (voir Ajout de variables de contexte aux politiques et aux définitions d'élément dorsal HTTP). À la réception du nouveau jeton JWT id_token, la passerelle d'API extrait les détails de la demande et reprend le traitement de la demande à l'aide du jeton.

L'emplacement à partir duquel la passerelle d'API obtient un jeton dépend à la fois du type de politique de validation (l'un des points d'extrémité d'introspection OAuth 2.0, JWKS distant ou clés statiques) et du type de politique d'échec de validation (l'un des suivants : Par défaut (HTTP 401 Non autorisé), Réponse personnalisée ou OAuth 2.0), comme suit :

Si vous spécifiez à la fois une politique de validation de type OAuth 2.0 point d'extrémité d'introspection et une politique d'échec de validation de type OAuth 2.0, la passerelle d'API tente initialement d'obtenir le jeton à partir de l'un ou l'autre des éléments suivants :
- Si vous avez sélectionné l'option Utiliser les témoins pour la session dans la politique d'échec de validation, à partir d'un témoin de session.
- Sinon, à partir de l'en-tête X-APIGW-TOKEN dans la demande.
Si la passerelle d'API ne peut pas obtenir un jeton à partir de l'emplacement initial, la passerelle d'API obtient le jeton à partir de l'en-tête de demande ou du paramètre d'interrogation que vous spécifiez dans la politique d'authentification de jeton.
Si la validation du jeton réussit par la suite et que vous avez sélectionné l'option Utiliser les témoins pour la session, la passerelle d'API stocke le jeton généré en tant que chaîne non lisible dans un témoin de session. Si le client d'API effectue une demande ultérieure, le jeton est obtenu à partir du témoin de session. Pour empêcher les attaques CSRF, lorsque le jeton généré est stocké dans un témoin de session, la passerelle d'API retourne également un jeton CSRF dans un en-tête de réponse X-CSRF-TOKEN (voir Notes sur la protection contre la falsification de demande intersites (CSRF)).
Si vous ne spécifiez pas à la fois une politique de validation de type OAuth 2.0 introspection endpoint et une politique d'échec de validation de type OAuth 2.0, la passerelle d'API obtient le jeton à partir de l'en-tête de demande ou du paramètre d'interrogation que vous spécifiez dans la politique d'authentification de jeton.

Notes sur les jetons Web JSON (JWT)

Les jetons que vous utilisez pour contrôler l'accès aux API sont généralement des jetons Web JSON (JWT). Un jeton Web JSON (JWT) est un jeton d'accès basé sur JSON envoyé dans une demande HTTP à partir d'un client d'API vers une ressource. Les JWT sont émis par des fournisseurs d'identités. Le service de passerelle d'API prend en charge l'utilisation de tout fournisseur d'identités conforme à OAuth2, comme OCI IAM avec domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta. Si un JWT est requis pour accéder à une ressource, la ressource valide le JWT avec un serveur d'autorisation à l'aide d'une clé de vérification publique correspondante, soit en appelant un point d'extrémité de validation sur le serveur d'autorisation, soit en utilisant une clé de vérification locale fournie par le serveur d'autorisation.

Un jeton Web JSON (JWT) est composé des éléments suivants :

Un en-tête identifiant le type de jeton et l'algorithme cryptographique utilisé pour générer la signature.
Des données utiles, contenant des revendications à propos de l'identité de l'utilisateur final et les propriétés du jeton Web JSON (JWT) lui-même. Une revendication est une paire clé-valeur, où la clé est le nom de la revendication. Il est recommandé (mais non requis) que les données utiles contiennent certaines revendications réservées portant des noms particuliers, comme le délai d'expiration (exp), le public (aud), l'émetteur (iss) et Pas avant (nbf). Les données utiles peuvent également contenir des revendications personnalisées avec des noms définis par l'utilisateur.
Une signature, pour valider l'authenticité du jeton Web JSON (JWT) (dérivé par l'encodage en base64 de l'en-tête et des données utiles).

Lorsque vous utilisez des JWT pour contrôler l'accès aux API, vous pouvez spécifier que les revendications réservées dans les données utiles de la JWT doivent avoir des valeurs particulières avant que la passerelle d'API ne considère la JWT comme valide. Par défaut, les passerelles d'API valident les jetons Web JSON (JWT) à l'aide de revendications d'expiration (exp), de public (aud) et d'émetteur (iss), ainsi qu'avec la revendication Pas avant (nbf) si elle est présente. Vous pouvez également spécifier des valeurs acceptables pour les revendications personnalisées. Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).

Lorsqu'un jeton JWT a été validé, la passerelle d'API extrait les réclamations des données utiles du jeton JWT en tant que paires clé-valeur et les enregistre en tant qu'enregistrements dans la table de contexte request.auth pour utilisation par le déploiement d'API. Par exemple, en tant que variables de contexte à utiliser dans une définition d'élément dorsal HTTP (voir Ajout de variables de contexte aux politiques et aux définitions d'élément dorsal HTTP). Si les données utiles du jeton Web JSON (JWT) contiennent la revendication scope, vous pouvez utiliser les valeurs de la revendication dans les politiques de demande d'autorisation pour des routes individuelles afin de spécifier les opérations qu'un utilisateur final est autorisé à effectuer.

Notes sur OAuth 2.0 et OpenID Connect

Le protocole OAuth 2.0 permet l'extraction sécurisée des ressources sécurisées tout en protégeant les données d'identification du client. OAuth 2.0 est un protocole flexible et sécurisé qui repose sur SSL (Secure Sockets Layer) pour garantir que les données entre les serveurs Web et les navigateurs restent privées. Bien que OAuth 2.0 soit différent de JWT et utilisé à des fins différentes, OAuth 2.0 et JWT sont compatibles. Comme le protocole OAuth2 ne spécifie pas le format des jetons, les JWT peuvent être intégrés à l'utilisation de OAuth2. Pour plus d'informations sur OAuth 2.0, consultez la documentation sur OAuth 2.0.

OpenID Connect est une couche d'identité simple au-dessus du protocole OAuth 2.0. L'utilisation d'OpenID Connect permet aux passerelles d'API de vérifier l'identité d'un client d'API en fonction de l'authentification effectuée par un serveur d'autorisation. OpenID Connect permet également aux passerelles d'API d'obtenir des informations de profil de base sur le client d'API. Pour plus d'informations sur OpenID Connect, consultez la documentation sur OpenID Connect.

Notes sur la protection contre la falsification de demandes intersites (CSRF)

Un attaquant peut monter une attaque CSRF en exploitant l'existence d'un cookie de navigateur pour amener un utilisateur à soumettre une commande involontaire à une application Web, telle qu'une passerelle d'API. Si l'application détermine que l'utilisateur a déjà été authentifié avec succès en raison de l'existence du cookie du navigateur, l'application exécute la commande avec des conséquences potentiellement dommageables.

Lorsque vous définissez une politique de validation de type OAuth 2.0 point d'extrémité d'introspection et une politique d'échec de validation de type OAuth 2.0, vous spécifiez comment une passerelle d'API stocke un nouveau jeton JWT qu'elle a obtenu à l'aide du flux d'autorisation OpenID Connect :

Sélectionnez l'option Utiliser les témoins pour la session si vous voulez stocker le nouveau jeton JWT dans un témoin de session. Pour éviter les attaques CSRF potentielles, lorsque la passerelle d'API stocke le jeton dans un cookie de session, elle retourne également un jeton CSRF dans un en-tête de réponse X-CSRF-TOKEN. Les demandes de mutation subséquentes à la passerelle d'API (telles que les demandes POST, PUT et DELETE, mais pas les demandes GET) doivent inclure le jeton CSRF dans un en-tête de demande X-CSRF-TOKEN, en plus du jeton JWT dans le témoin de session qui est inclus automatiquement.
Notez que la passerelle d'API stocke également le jeton CSRF dans la variable de contexte request.auth[apigw_csrf_token]. Si le client d'API ne peut pas lire l'en-tête de réponse initial X-CSRF-TOKEN pour une raison quelconque, vous pouvez inclure la variable de contexte request.auth[apigw_csrf_token] dans une politique de réponse de transformation d'en-tête pour ajouter un en-tête de réponse contenant le jeton CSRF à chaque réponse retournée au client d'API. Cette approche garantit que le client d'API peut extraire avec succès le jeton CSRF de l'en-tête de réponse pour l'inclure dans les en-têtes de demande de mutation X-CSRF-TOKEN suivants qu'il envoie à la passerelle d'API. Voici un exemple de politique de réponse de transformation d'en-tête appropriée :
```
"responsePolicies": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "MY-CSRF-TOKEN",
                "values": ["${request.auth[apigw_csrf_token]}"],
                "ifExists": "OVERWRITE"              }
            ]
          }
        }
      }
```
Pour plus d'informations sur les politiques de réponse de transformation d'en-tête, voir Ajout de politiques de réponse de transformation d'en-tête.
Ne sélectionnez pas l'option Utiliser les témoins pour la session si vous ne voulez pas stocker le nouveau jeton JWT dans un témoin de session. Au lieu de cela, la passerelle d'API retourne un jeton non lisible par l'homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes suivantes à la passerelle d'API doivent inclure le même jeton dans un en-tête de demande X-APIGW-TOKEN.

Pour plus d'informations sur CSRF, recherchez en ligne.

Notes sur l'utilisation des politiques de demande JWT_AUTHENTICATION

Dans les versions antérieures, il se peut que vous ayez créé des politiques de demande d'authentification de type JWT_AUTHENTICATION pour utiliser des JWT pour l'authentification.

Si vous créez de nouvelles politiques de demande d'authentification pour utiliser des JWT, nous vous recommandons maintenant de créer des politiques de demande d'authentification de type TOKEN_AUTHENTICATION à la place (voir Utilisation de la console pour ajouter des politiques de demande d'authentification et d'autorisation de jeton et Modification d'un fichier JSON pour ajouter des politiques de demande d'authentification et d'autorisation de jeton). Nous vous recommandons également de migrer les politiques de demande JWT_AUTHENTICATION existantes vers les politiques TOKEN_AUTHENTICATION.

Notez que les politiques de demande JWT_AUTHENTICATION existantes sont toujours prises en charge. Notez également que, bien que vous puissiez créer de nouvelles politiques de demande JWT_AUTHENTICATION (comme décrit dans les instructions initiales de la section Utilisation d'une politique de demande d'authentification JWT_AUTHENTICATION (non recommandée)), nous vous recommandons de créer des politiques de demande d'authentification de type TOKEN_AUTHENTICATION à la place.

Préalables pour l'authentification par jeton

Pour pouvoir activer l'authentification et l'autorisation pour les déploiements d'API à l'aide des jetons Web JSON (JWT) :

Un fournisseur d'identités conforme à OAuth2 (par exemple, OCI IAM avec domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0) doit déjà avoir été configuré pour émettre des JWT pour les utilisateurs autorisés à accéder au déploiement d'API.
Si vous voulez utiliser des revendications personnalisées dans les politiques d'autorisation, le fournisseur d'identités doit être configuré pour les ajouter aux jetons Web JSON (JWT) qu'il délivre.

Pour plus d'informations, voir la documentation sur les fournisseurs d'identités (par exemple, IAM OCI avec domaines d'identité, Oracle Identity Cloud Service (IDCS) et Auth0).

Pour valider une JWT à l'aide d'une clé de vérification publique correspondante fournie par le fournisseur d'identités émetteur :

l'algorithme de signature utilisé pour générer la signature du jeton Web JSON (JWT) doit être RS256, RS384 ou RS512
la clé de vérification publique doit avoir une longueur minimale de 2 048 bits et ne doit pas dépasser 4 096 bits

Pour valider des jetons à l'aide du point d'extrémité d'introspection d'un serveur d'autorisations :

Vous devez avoir déjà créé et enregistré une application client auprès du serveur d'autorisations pour obtenir les données d'identification du client (ID client et clé secrète client). Pour plus d'informations, voir la documentation sur le serveur d'autorisations (par exemple, la documentation sur OCI IAM avec domaines d'identité, la documentation sur Oracle Identity Cloud Service (IDCS) et la documentation sur Auth0).
Vous devez avoir déjà stocké la clé secrète client que vous avez obtenue du serveur d'autorisations en tant que clé secrète dans une chambre forte du service de chambre forte (voir Création d'une clé secrète dans une chambre forte), et vous devez connaître l'OCID et le numéro de version de la clé secrète.
Vous devez déjà avoir configuré une politique pour accorder aux passerelles d'API d'un groupe dynamique l'autorisation d'accéder à la clé secrète de la chambre forte contenant la clé secrète client (voir Créer une politique pour accorder aux passerelles d'API l'accès aux données d'identification stockées en tant que clés secrètes dans le service de chambre forte).

Utilisation de la console pour ajouter des politiques de demande d'autorisation et d'authentification par jeton

Pour ajouter des politiques de demande d'authentification et d'autorisation à une spécification de déploiement d'API à l'aide de la console :

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.
Sélectionnez Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour spécifier que vous voulez utiliser un seul serveur d'authentification pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d'authentification. Sinon, si vous voulez utiliser plusieurs serveurs d'authentification, sélectionnez Authentification multiple et suivez les instructions sous 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 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.
Sélectionnez OAuth 2.0 / OpenID Connect dans la liste d'options Type d'authentification et spécifiez les données suivantes :
- Emplacement du jeton : Indique si les jetons sont contenus dans un en-tête de demande ou un paramètre d'interrogation.
- Détails du jeton d'authentification : Selon que les jetons sont contenus dans un en-tête de demande ou un paramètre d'interrogation, spécifiez :
  - Nom d'en-tête de jeton : et Schéma d'authentification : Si des jetons sont contenus dans un en-tête de demande, entrez le nom de l'en-tête (par exemple Authorization) et le modèle d'authentification HTTP (seulement Bearer est actuellement pris en charge).
  - Nom de paramètre de jeton : Si des jetons sont contenus dans un paramètre d'interrogation, entrez le nom du paramètre d'interrogation.
Spécifier comment la passerelle d'API doit valider les jetons :
1. Si vous voulez que la passerelle d'API valide à la fois les jetons JWT et les jetons non JWT avec un point d'extrémité d'introspection du serveur d'autorisation OAuth 2.0 à l'aide des données d'identification de client (y compris une clé secrète client extraite d'une chambre forte dans le service de chambre forte), sélectionnez OAuth 2.0 point d'extrémité d'introspection dans la liste Type et spécifiez :
  - ID client : ID client à envoyer au point d'extrémité de l'introspection. Vous obtenez un ID client en créant et en enregistrant une application client auprès du serveur d'autorisations. Par exemple : 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Voir Préalables à l'authentification par jeton.
  - Chambre forte dans <compartment-name> : Nom d'une chambre forte dans le service de chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection. Vous obtenez une clé secrète client en créant et en enregistrant une application client auprès du serveur d'autorisations. Voir Préalables à l'authentification par jeton.
  - Clé secrète de chambre forte dans <compartment name> : Nom d'une clé secrète de chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection.
  - Numéro de version de la clé secrète de la chambre forte : Version de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité de l'introspection.
  - URL de détection : URL bien connue du serveur d'autorisation à partir duquel la passerelle d'API doit obtenir les points d'extrémité de métadonnées d'autorisation. Par exemple, https://my-idp/oauth2/default/.well-known/openid-configuration.
    Notez que l'URL doit être routable à partir du sous-réseau contenant la passerelle d'API sur laquelle l'API est déployée.
  - Durée de mémoire cache maximale en heures : Nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache la réponse du point d'extrémité d'introspection.
  - Variation d'horloge maximale en secondes : (Facultatif) Différence de temps maximale entre les horloges système du serveur d'autorisation qui a émis un jeton et la passerelle d'API. La valeur que vous entrez ici est prise en compte lorsque la passerelle d'API valide un JWT pour déterminer s'il est toujours valide, en utilisant la revendication non antérieure (nbf) (le cas échéant) et la revendication d'expiration (exp) dans le JWT. La valeur minimale (et par défaut) est 0, la valeur maximale est 120.
  - Désactiver la vérification SSL : Indique s'il est possible de désactiver la vérification SSL lors de la communication avec le serveur d'autorisations. Par défaut, cette option n'est pas sélectionnée. Oracle recommande de ne pas sélectionner cette option, car elle peut compromettre la validation du jeton. Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
2. Si vous voulez que la passerelle d'API valide les JWT en extrayant les clés de vérification publiques du fournisseur d'identités lors de l'exécution, sélectionnez JWKS distant dans la liste Type et spécifiez :
  - URI JWKS : URI à partir duquel extraire le jeu de clés Web JSON (JWKS) à utiliser pour vérifier la signature sur les JWT. Par exemple https://www.somejwksprovider.com/oauth2/v3/certs. Pour plus d'informations sur l'URI à spécifier, voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
    
    Notez ce qui suit :
    - L'URI doit être routable à partir du sous-réseau contenant la passerelle d'API sur laquelle l'API est déployée.
    - Si la passerelle d'API ne parvient pas à extraire le jeu de clés Web JSON (JWKS), toutes les demandes au déploiement d'API retournent un code de réponse HTTP 500. Pour plus d'informations sur l'erreur, consultez le journal d'exécution de la passerelle d'API (voir Ajout de la journalisation aux déploiements d'API).
    - Certains paramètres de clé doivent être présents dans le jeu de clés Web JSON (JWKS) pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)).
    - Le JWKS peut contenir jusqu'à dix clés.
  - Durée de mémoire cache maximale en heures : Nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache JWKS après l'avoir extraite.
  - Désactiver la vérification SSL : Si la vérification SSL doit être désactivée ou non lors de la communication avec le fournisseur d'identités. Par défaut, cette option n'est pas sélectionnée. Oracle recommande de ne pas sélectionner cette option, car elle peut compromettre la validation des jetons Web JSON (JWT). Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
3. Si vous voulez que la passerelle d'API valide les JWT avec des clés de vérification publiques déjà émises par un fournisseur d'identités (en activant la passerelle d'API pour vérifier les JWT localement sans avoir à communiquer avec le fournisseur d'identités), sélectionnez Clés statiques dans la liste Type et spécifiez jusqu'à dix clés statiques :
  - ID clé : Identificateur de la clé statique utilisée pour signer le jeton Web JSON (JWT). La valeur doit correspondre à la revendication kid dans l'en-tête du jeton Web JSON (JWT). Par exemple master_key.
  - Format de clé : Format de la clé statique, comme clé Web JSON ou clé publique codée en PEM.
    - Clé Web JSON : Si la clé statique est une clé Web JSON, collez la clé dans ce champ.
      
      Par exemple :
```
{
  "kty": "RSA",
  "n": "0vx7agoebGc...KnqDKgw",
  "e": "AQAB",
  "alg": "RS256",
  "use": "sig"
}
```
      Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)). Notez également que RSA est actuellement le seul type de clé pris en charge (kty).
    - Clé publique encodée en PEM : Si la clé statique est une clé publique encodée en PEM, collez la clé dans ce champ. Par exemple :
```
-----BEGIN PUBLIC KEY-----
XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH
-----END PUBLIC KEY-----
```
      Notez que les marqueurs -----BEGIN PUBLIC KEY----- et -----END PUBLIC KEY----- sont obligatoires.
  - Autre clé : Sélectionnez cette option pour ajouter des clés supplémentaires (jusqu'à un maximum de dix).
(Facultatif) Spécifiez des détails supplémentaires pour la validation du jeton JWT :
1. Dans la section Émetteurs, spécifiez les valeurs autorisées dans la revendication d'émetteur (iss) d'un jeton Web JSON (JWT) utilisé pour accéder au déploiement d'API :
  - Émetteurs autorisés : Spécifiez l'URL (ou une chaîne de texte) d'un fournisseur d'identités autorisé dans la revendication d'émetteur (iss) d'un jeton Web JSON (JWT) à utiliser pour accéder au déploiement d'API. Par exemple, pour activer un JWT émis par OCI IAM avec des domaines d'identité à utiliser pour accéder au déploiement d'API, entrez https://identity.oraclecloud.com/. Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - Un autre émetteur : Sélectionnez cette option pour ajouter des fournisseurs d'identités supplémentaires (jusqu'à un maximum de cinq).
2. Dans la section Publics, spécifiez les valeurs autorisées dans la revendication de public (aud) d'un jeton Web JSON (JWT) utilisé pour accéder au déploiement d'API :
  - Publics autorisés : Indiquez une valeur autorisée dans la revendication de public (aud) d'un jeton Web JSON (JWT) pour identifier le destinataire prévu du jeton. Par exemple, le public peut être, mais n'a pas besoin d'être, le nom d'hôte de la passerelle d'API. Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - Un autre public : Sélectionnez cette option pour ajouter des publics supplémentaires (jusqu'à un maximum de cinq).
3. Validation des réclamations : (Facultatif) En plus des valeurs des réclamations d'audience aud et d'émetteur iss que vous avez déjà spécifiées, vous pouvez spécifier des noms et des valeurs pour une ou plusieurs réclamations supplémentaires à valider dans un JWT. Notez que les noms et valeurs de clé que vous entrez sont simplement traités comme des chaînes et doivent correspondre exactement avec les noms et les valeurs du jeton Web JSON (JWT). La correspondance de modèle et d'autres types de données ne sont pas pris en charge.
  - La réclamation est requise : Spécifiez si la réclamation dans le champ Clé de réclamation doit être incluse dans le JWT.
  - Clé de réclamation : (Facultatif) Spécifiez le nom d'une réclamation qui peut ou doit être incluse dans un JWT. Si la revendication doit être incluse dans le jeton Web JSON (JWT), sélectionnez Obligatoire. Le nom de revendication que vous spécifiez peut être un nom de revendication réservée tel que la revendication de sujet (sub) ou un nom de revendication personnalisée délivré par un fournisseur d'identités particulier.
  - Valeurs de revendication : (Facultatif) Spécifiez une valeur acceptable pour la revendication dans le champ Clé de revendication. Sélectionnez le signe plus (+) pour entrer une autre valeur acceptable. Si vous spécifiez une ou plusieurs valeurs acceptables pour la revendication, la passerelle d'API valide que la revendication comporte l'une des valeurs que vous spécifiez.
  Notez que vous pouvez spécifier une réclamation dans un JWT sans spécifier de valeur pour celle-ci. Pour ce faire, entrez le nom de la réclamation dans le champ Clé de réclamation, laissez le champ Valeurs de réclamation vide et réglez La réclamation est requise, le cas échéant.
Spécifiez comment la passerelle d'API doit traiter une réponse d'authentification en échec (retournée après une tentative infructueuse de validation d'un jeton manquant ou non valide) en configurant une politique d'échec de validation :
1. Si vous voulez que la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse (réponse par défaut à un jeton manquant ou non valide), sélectionnez Par défaut (HTTP 401 Non autorisé).
2. Si vous voulez que la passerelle d'API utilise un flux d'autorisation OpenID Connect pour obtenir un nouveau jeton d'accès JWT, sélectionnez OAuth 2.0. Notez que cette option n'est disponible que si vous avez sélectionné OAuth 2.0 point d'extrémité d'introspection dans la liste Type de validation précédemment. Spécifiez les données suivantes :
  - Portées : Une ou plusieurs portées d'accès à inclure dans une réclamation scope envoyée au serveur d'autorisations. Pour utiliser le flux d'autorisation OpenID Connect, vous devez inclure openid dans l'une des portées. Par exemple, openid, email:read, profile.
  - Type de réponse : Type de réponse requis du flux d'autorisation. Entrez code comme type de réponse.
  - Chemin de redirection de secours : (facultatif) Chemin relatif dans le déploiement d'API courant vers lequel rediriger les clients d'API si la demande initiale était une demande PUT ou POST. Par exemple, /home
    Si la demande initiale était une demande GET, le traitement de la demande reprend avec un nouveau jeton d'accès JWT, de sorte qu'un chemin de secours n'est pas utilisé.
  - Chemin de déconnexion : (facultatif) Chemin relatif vers un élément dorsal de déconnexion dans le déploiement d'API courant. Le chemin que vous spécifiez doit correspondre au chemin d'acheminement défini pour l'élément dorsal de déconnexion. Par exemple, /revoke
    Un client d'API peut appeler l'élément dorsal de déconnexion pour révoquer des jetons. Un appel à l'élément dorsal de déconnexion peut inclure une URL après déconnexion en tant que paramètre d'interrogation nommé postLogoutUrl. Voir Ajout de la déconnexion en tant qu'élément dorsal du service de passerelle d'API.
  - Expiration de la réponse en heures : (facultatif) Durée de mise en mémoire cache du jeton JWT généré par le flux d'autorisation. La valeur par défaut est 1 heure.
  - Utilisez les données d'identification de client de point d'extrémité d'introspection OAuth2 : Spécifiez s'il faut utiliser les mêmes détails de client que ceux que vous avez précédemment spécifiés pour le point d'extrémité d'introspection OAuth 2.0 pour obtenir un nouveau jeton d'accès JWT (ce qui est généralement le cas). Si vous ne voulez pas utiliser les détails que vous avez précédemment spécifiés, entrez des détails de client différents à utiliser pour obtenir un nouveau jeton d'accès JWT du serveur d'autorisations, comme suit :
    - ID client : ID client à envoyer au point d'extrémité de l'introspection. Par exemple, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - Chambre forte dans <compartment-name> : Nom d'une chambre forte dans le service de chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection.
    - Clé secrète de chambre forte dans <compartment name> : Nom de la clé secrète de chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection.
    - Numéro de version de la clé secrète de la chambre forte : Version de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité de l'introspection.
  Vous pouvez éventuellement choisir de stocker dans les témoins les jetons et les valeurs obtenus lors des flux d'autorisation OpenID, en sélectionnant Afficher les options avancées et en sélectionnant :
  - Utiliser des témoins pour la session : (facultatif) Spécifiez comment stocker les jetons JWT nouvellement générés en tant que chaînes non lisibles par l'utilisateur à la fin d'un flux d'autorisation OpenID Connect :
    - Sélectionnez cette option si vous souhaitez stocker le nouveau jeton JWT dans un témoin de session. Pour éviter les attaques CSRF potentielles, lorsque la passerelle d'API stocke le jeton dans un cookie de session, elle retourne également un jeton CSRF dans un en-tête de réponse X-CSRF-TOKEN. Les demandes suivantes à la passerelle d'API (à l'exception des demandes GET) doivent inclure le jeton CSRF dans un en-tête de demande X-CSRF-TOKEN, en plus du jeton JWT dans le témoin de session qui est inclus automatiquement.
    - Ne sélectionnez pas cette option si vous ne souhaitez pas stocker le nouveau jeton JWT dans un cookie de session. Au lieu de cela, la passerelle d'API retourne un jeton non lisible par l'homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes suivantes à la passerelle d'API doivent inclure le même jeton dans un en-tête de demande X-APIGW-TOKEN.
    Voir Notes sur la protection contre la falsification de demandes intersites (CSRF)
  - Utiliser des témoins pour les étapes intermédiaires : (facultatif) Spécifiez comment stocker les valeurs des étapes intermédiaires du flux d'autorisation (par exemple, les paramètres de demande). Sélectionnez cette option pour stocker les valeurs dans les témoins du navigateur. Désélectionnez cette option pour stocker les valeurs avec la passerelle d'API.
  - Utiliser PKCE : (facultatif) Spécifiez s'il faut utiliser PKCE (clé de vérification pour l'échange de code) pour plus de sécurité. PKCE est une extension de sécurité OAuth 2.0 pour empêcher les attaques par injection de code d'autorisation et de CSRF (Cross-Site Request Forgery). PKCE ne remplace pas une clé secrète client, et PKCE est recommandé même si une clé secrète client est utilisée. Pour plus d'informations sur PKCE, consultez la documentation sur OAuth 2.0.
3. Si vous voulez personnaliser la réponse en cas d'échec de la tentative de validation d'un jeton manquant ou non valide, sélectionnez Réponse personnalisée et spécifiez un code de statut (et un corps de message facultatif) pour retourner au client d'API :
  - Code de statut HTTP : Entrez un autre code de statut HTTP. Par exemple : 500.
  - 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).
  - Facultativement, modifiez les en-têtes de la réponse retournée par la passerelle d'API au client d'API en spécifiant une politique de réponse de transformation d'en-tête. Pour plus d'informations sur les politiques de transformation d'en-tête, voir Ajout de politiques de réponse de transformation d'en-tête.
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la section Route 1, spécifiez la première route du déploiement d'API qui mappe un chemin et une ou plusieurs méthodes à un service dorsal :
- Chemin : Chemin des appels d'API utilisant les méthodes indiquées au service dorsal. Notez que le chemin de routage que vous spécifiez :
  - Est relatif au préfixe du chemin de déploiement.
  - Doit être précédé d'une barre oblique (/) et peut être simplement cette seule barre oblique.
  - Peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes) et peut se terminer par une barre oblique.
  - Peut inclure des caractères alphanumériques en majuscules et en minuscules.
  - peut inclure les caractères spéciaux $ - _ . + ! * ' ( ) , % ; : @ & =
  - Peut inclure des paramètres et des caractères génériques (voir Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : Une ou plusieurs méthodes acceptées par le service dorsal, séparées par des virgules. Par exemple, GET, PUT.
- Ajouter un seul serveur dorsal ou Ajouter plusieurs serveurs dorsaux : Indique s'il faut acheminer toutes les demandes vers le même serveur dorsal ou acheminer les demandes vers différents serveurs dorsaux en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous voulez utiliser un seul élément dorsal. Sélectionnez donc Ajouter un seul élément dorsal. Sinon, si vous voulez utiliser des éléments dorsaux différents, sélectionnez Ajouter plusieurs éléments dorsaux et suivez les instructions sous Utilisation de la console pour ajouter une sélection d'élément dorsal dynamique à une spécification de déploiement d'API.
- Type dorsal : Type du service dorsal, parmi l'un des suivants :
  - HTTP : Pour un élément dorsal HTTP, vous devez également spécifier une URL, les détails de temporisation et déterminer s'il faut désactiver ou non la vérification SSL (voir Ajout d'une URL HTTP ou HTTPS comme élément dorsal du service de passerelle d'API).
  - Oracle Functions : Pour un élément dorsal du service des fonctions pour OCI, vous devez également spécifier l'application et la fonction (voir Ajout d'une fonction du service des fonctions pour OCI en tant qu'élément dorsal du service de passerelle d'API).
  - Réponse standard : Pour un élément dorsal de réponse standard, vous devez également spécifier le code de statut HTTP, le contenu du corps de la réponse et un ou plusieurs champs d'en-tête HTTP (voir Ajout de réponses standard comme élément dorsal du service de passerelle d'API).
  - Déconnexion : Pour un élément dorsal de déconnexion, vous devez également spécifier une liste d'URL autorisées vers lesquelles une demande peut être redirigée pour révoquer des jetons, et éventuellement des données à transmettre à l'URL de déconnexion (voir Ajout de la déconnexion en tant qu'élément dorsal du service de passerelle d'API).
Pour spécifier une politique d'autorisation qui s'applique à une route individuelle, sélectionnez Afficher les politiques de demande de routage, sélectionnez le bouton Ajouter à côté du champ Autorisation, puis spécifiez les données suivantes :
- Type d'autorisation : Comment accorder l'accès à la route. Spécifiez les données suivantes :
  - Au choix : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si le jeton Web JSON (JWT) comprend une revendication scope incluant au moins une des étendues d'accès que vous spécifiez dans le champ Étendue autorisée. Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
  - Anonyme : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés par la fonction d'autorisation à l'aide du jeton Web JSON (JWT). Dans ce cas, vous devez avoir sélectionné l'option Activer l'accès anonyme de la politique d'authentification.
  - Authentification uniquement : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés à l'aide du jeton Web JSON (JWT). Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
- Étendue autorisée : Si vous avez sélectionné Au choix comme Type d'autorisation, indiquez une liste délimitée par des virgules, contenant une ou plusieurs chaînes correspondant aux étendues d'accès du jeton Web JSON (JWT). L'accès sera accordé uniquement aux utilisateurs finaux qui ont été authentifiés si le jeton Web JSON (JWT) comprend une revendication scope incluant l'une des étendues d'accès que vous spécifiez. Par exemple, read:hello.
Note

Si vous n'incluez pas de politique d'autorisation pour une route particulière, l'accès est accordé comme si une telle politique existait et le type d'autorisation est réglé à Authentification uniquement. Autrement dit, quel que soit le paramètre de l'option Activer l'accès anonyme de la politique d'authentification :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès de la revendication scope du jeton Web JSON (JWT).
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Sélectionnez Appliquer les modifications, puis sélectionnez Suivant pour vérifier les détails que vous avez entrés 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 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 des politiques de demande d'autorisation et d'authentification par jeton

Pour ajouter des politiques de demande d'authentification et d'autorisation à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter les fonctionnalités d'authentification et d'autorisation ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Au minimum, la spécification de déploiement d'API inclura une section routes contenant les éléments suivants :
- Un chemin. Par exemple /hello.
- Une ou plusieurs méthodes. Par exemple GET
- La définition d'un élément dorsal. Par exemple, une URL ou l'OCID d'une fonction du service des fonctions pour OCI.
Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Insérez une section requestPolicies avant la section routes (si elle n'existe pas déjà) pour créer une politique de demande authentication qui s'applique à toutes les routes de la spécification de déploiement d'API. Par exemple :


{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}

Ajoutez la politique de demande authentication comme suit
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
      "tokenAuthScheme": "<authentication-scheme>",
      "isAnonymousAccessAllowed": <true|false>,
      "maxClockSkewInSeconds": <seconds-difference>,
      "validationPolicy": {<validation-policy-config>},
    }
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
où :
- "authentication": {"type": "TOKEN_AUTHENTICATION"... indique que vous voulez utiliser des jetons pour l'authentification.
- <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indique si le jeton est contenu dans un en-tête de demande (et, si oui, le nom de l'en-tête) ou un paramètre d'interrogation (et, si oui, le nom du paramètre d'interrogation). Notez que vous pouvez spécifier "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mais pas les deux. Par exemple, "tokenHeader": "Authorization"
- <tokenAuthScheme> est le nom du modèle d'authentification à utiliser si le jeton est contenu dans un en-tête de demande. Par exemple "Bearer".
- "isAnonymousAccessAllowed": <true|false> indique facultativement si des utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes de la spécification de déploiement d'API. Si vous voulez que des utilisateurs finaux anonymes ne puissent jamais accéder aux routes, réglez cette propriété à false. Si vous n'incluez pas cette propriété dans la politique authentication, la valeur par défaut false est utilisée. Notez que si vous n'incluez pas cette propriété et que vous la réglez à true, vous devez également spécifier explicitement toutes les routes auxquelles l'accès anonyme est autorisé en réglant la propriété type à "ANONYMOUS" dans la politique authorization de chaque route.
- maxClockSkewInSeconds: <seconds-difference> spécifie facultativement la différence de temps maximale entre les horloges système du fournisseur d'identités qui a délivré un jeton Web JSON (JWT) et la passerelle d'API. La valeur que vous spécifiez est prise en compte lorsque la passerelle d'API valide le JWT pour déterminer s'il est toujours valide, en utilisant la revendication non antérieure (nbf) (le cas échéant) et la revendication d'expiration (exp) dans le JWT. La valeur minimale (et par défaut) est 0, la valeur maximale est 120.
- "validationPolicy": {<validation-policy-config>} spécifie une politique de validation pour valider les jetons, comme décrit dans les étapes suivantes.
Si vous voulez que la passerelle d'API valide à la fois les jetons JWT et les jetons non JWT avec un point d'extrémité d'introspection du serveur d'autorisation OAuth 2.0 à l'aide des données d'identification de client (y compris une clé secrète client extraite d'une chambre forte dans le service de chambre forte), ajoutez la politique de validation suivante à la section validationPolicy vide :
```
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",          
        "clientDetails": {
          "type": "CUSTOM",
          "clientId": "<client-id>",
          "clientSecretId": "<secret-ocid>",
          "clientSecretVersionNumber": <secret-version-number>
        },          
        "sourceUriDetails": {
          "type": "DISCOVERY_URI",
          "uri": "<well-known-uri>"
        },
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
où :
- "validationPolicy": {"type": "REMOTE_DISCOVERY"...} indique que vous voulez valider les jetons avec le point d'extrémité d'introspection d'un serveur d'autorisation OAuth 2.0 à l'aide des données d'identification de client (y compris une clé secrète client extraite d'une chambre forte dans le service de chambre forte).
- clientDetails": {"type": "CUSTOM"...} spécifie les détails de la clé secrète client à extraire d'une chambre forte dans le service de chambre forte :
  - "clientId": "<client-id>" indique l'ID client à envoyer au point d'extrémité d'introspection. Vous obtenez un ID client en créant et en enregistrant une application client auprès du serveur d'autorisations. Par exemple, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Voir Préalables à l'authentification par jeton.
  - "clientSecretId": "<secret-ocid>" indique l'OCID de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité de l'introspection. Par exemple, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
  - "clientSecretVersionNumber": <secret-version-number> indique la version de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection. Par exemple : 1
- "uri": "<well-known-uri>" indique l'URL bien connue d'un serveur d'autorisation à partir duquel la passerelle d'API doit obtenir des points d'extrémité de métadonnées d'autorisation. Par exemple, https://my-idp/oauth2/default/.well-known/openid-configuration. Notez que l'URL doit être routable à partir du sous-réseau contenant la passerelle d'API sur laquelle l'API est déployée.
- "isSslVerifyDisabled": <true|false> indique si la vérification SSL doit être désactivée lors de la communication avec le serveur d'autorisations. Oracle recommande de ne pas régler cette option à true, car elle peut compromettre la validation JWT. Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- "maxCacheDurationInHours": <cache-time> indique le nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache la réponse du point d'extrémité d'introspection.
- "additionalValidationPolicy": {"issuers": ...} spécifie des détails supplémentaires pour la validation du jeton :
  - <issuer-url> est l'URL (ou une chaîne de texte) d'un serveur d'autorisation autorisé dans la revendication de l'émetteur (iss) d'un JWT à utiliser pour accéder au déploiement d'API. Par exemple, pour activer un JWT émis par le service IAM OCI avec des domaines d'identité à utiliser pour accéder au déploiement d'API, spécifiez https://identity.oraclecloud.com/. Vous pouvez spécifier un ou plusieurs serveurs d'autorisation (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - <intended-audience> est une valeur autorisée dans la revendication de public (aud) d'un jeton Web JSON (JWT) pour identifier le destinataire prévu du jeton. Par exemple, le public peut être, mais n'a pas besoin d'être, le nom d'hôte de la passerelle d'API. Vous pouvez spécifier un ou plusieurs publics (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - "verifyClaims": {...} spécifie éventuellement des noms et des valeurs de revendication supplémentaires pour une ou plusieurs revendications supplémentaires à valider dans un JWT (jusqu'à un maximum de dix) :
    - "key": "<claim-name>" est le nom d'une revendication qui peut ou doit être incluse dans un jeton Web JSON (JWT). Le nom de revendication que vous spécifiez peut être un nom de revendication réservée tel que la revendication de sujet (sub) ou un nom de revendication personnalisée délivré par un serveur d'autorisations particulier.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (facultatif) indique une ou plusieurs valeurs acceptables pour la revendication.
    - "isRequired": <true|false> indique si la revendication doit être incluse dans le jeton Web JSON (JWT).
    Notez que les noms et valeurs de clé que vous entrez sont simplement traités comme des chaînes et doivent correspondre exactement avec les noms et les valeurs du jeton Web JSON (JWT). La correspondance de modèle et d'autres types de données ne sont pas pris en charge.
Par exemple, la politique authentication suivante configure la passerelle d'API pour valider un jeton dans l'en-tête de la demande d'autorisation à l'aide des données d'identification de client (y compris une clé secrète client extraite d'une chambre forte dans le service de chambre forte) transmises à un point d'extrémité d'introspection OAuth 2.0 :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        "clientDetails": {
          "type": "CUSTOM",
          "clientId": "5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1",
          "clientSecretId": "ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q",
          "clientSecretVersionNumber": 1
        },          
        "sourceUriDetails": {
          "type": "DISCOVERY_URI",
          "uri": "https://my-idp/oauth2/default/.well-known/openid-configuration"
        },
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Si vous voulez que la passerelle d'API valide les JWT en extrayant les clés de vérification publiques du fournisseur d'identités lors de l'exécution, ajoutez la politique de validation suivante à la section validationPolicy vide :
```
      "validationPolicy": {
        "type": "REMOTE_JWKS",
        "uri": "<uri-for-jwks>",
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
où :
- "validationPolicy": {"type": "REMOTE_JWKS"... indique que vous voulez configurer la passerelle d'API pour qu'elle extraie jusqu'à dix clés de vérification publiques du fournisseur d'identités au moment de l'exécution.
- "uri": "<uri-for-jwks>" spécifie l'URI à partir duquel extraire le jeu de clés Web JSON (JWKS) à utiliser pour vérifier la signature des jetons Web JSON (JWT). Pour plus d'informations sur l'URI à spécifier, voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS). Notez ce qui suit :
  - L'URI doit être routable à partir du sous-réseau contenant la passerelle d'API sur laquelle l'API est déployée.
  - Si la passerelle d'API ne parvient pas à extraire le jeu de clés Web JSON (JWKS), toutes les demandes au déploiement d'API retournent un code de réponse HTTP 500. Pour plus d'informations sur l'erreur, consultez le journal d'exécution de la passerelle d'API (voir Ajout de la journalisation aux déploiements d'API).
  - Certains paramètres de clé doivent être présents dans le jeu de clés Web JSON (JWKS) pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)).
  - Le JWKS peut contenir jusqu'à dix clés.
- "isSslVerifyDisabled": <true|false> indique si la vérification SSL doit être désactivée lors de la communication avec le fournisseur d'identités. Oracle recommande de ne pas régler cette option à true, car elle peut compromettre la validation JWT. Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- "maxCacheDurationInHours": <cache-time> indique le nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache JWKS après l'extraction.
- "additionalValidationPolicy": {"issuers": ...} spécifie des détails supplémentaires pour la validation du jeton :
  - <issuer-url> est l'URL (ou une chaîne de texte) d'un fournisseur d'identités autorisé dans la revendication de l'émetteur (iss) d'un JWT à utiliser pour accéder au déploiement d'API. Par exemple, pour activer un JWT émis par OCI IAM avec des domaines d'identité à utiliser pour accéder au déploiement d'API, entrez https://identity.oraclecloud.com/. Vous pouvez spécifier un ou plusieurs fournisseurs d'identités (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - <intended-audience> est une valeur autorisée dans la revendication de public (aud) d'un jeton Web JSON (JWT) pour identifier le destinataire prévu du jeton. Par exemple, le public peut être, mais n'a pas besoin d'être, le nom d'hôte de la passerelle d'API. Vous pouvez spécifier un ou plusieurs publics (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - verifyClaims spécifie facultativement des noms et des valeurs pour une ou plusieurs revendications supplémentaires à valider dans un jeton Web JSON (JWT) (dix au maximum).
    - "key": "<claim-name>" est le nom d'une revendication qui peut ou doit être incluse dans un jeton Web JSON (JWT). Le nom de revendication que vous spécifiez peut être un nom de revendication réservée tel que la revendication de sujet (sub) ou un nom de revendication personnalisée délivré par un fournisseur d'identités particulier.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (facultatif) indique une ou plusieurs valeurs acceptables pour la revendication.
    - "isRequired": <true|false> indique si la revendication doit être incluse dans le jeton Web JSON (JWT).
    Notez que les noms et valeurs de clé que vous entrez sont simplement traités comme des chaînes et doivent correspondre exactement avec les noms et les valeurs du jeton Web JSON (JWT). La correspondance de modèle et d'autres types de données ne sont pas pris en charge.
Par exemple, la politique authentication suivante configure la passerelle d'API pour valider JWT dans l'en-tête de la demande d'autorisation en extrayant les clés de vérification publiques du fournisseur d'identités lors de l'exécution :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "REMOTE_JWKS",
        "uri": "https://my-tenant-id.identity.oraclecloud.com/admin/v1/SigningCert/jwk",
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Si vous voulez que la passerelle d'API valide les JWT avec des clés de vérification publiques déjà émises par un fournisseur d'identités (en activant la passerelle d'API pour vérifier les JWT localement sans avoir à communiquer avec le fournisseur d'identités), ajoutez la politique de validation suivante à la section validationPolicy vide :
```
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [{<key-config>}],
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
où :
- "validationPolicy": {"type": "STATIC_KEYS"... indique que vous voulez configurer la passerelle d'API avec jusqu'à dix clés de vérification publiques déjà émises par un fournisseur d'identités (en activant la passerelle d'API pour vérifier les JWT localement sans avoir à communiquer avec le fournisseur d'identités).
- "keys": [{<key-config>}] spécifie l'identificateur de la clé statique utilisée pour signer le JWT. Les détails à fournir dépendent du format de la clé déjà émise par le fournisseur d'identités (peu importe le format, vous pouvez spécifier jusqu'à dix clés) :
  - Si la clé statique est une clé Web JSON, spécifiez "format": "JSON_WEB_KEY", spécifiez l'identificateur de la clé statique utilisée pour signer le jeton Web JSON (JWT) comme valeur du paramètre "kid" et fournissez les valeurs des autres paramètres pour vérifier la signature du jeton Web JSON (JWT).
    
    Par exemple :
```
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
```
    Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)). Notez également que RSA est actuellement le seul type de clé pris en charge (kty).
  - Si la clé statique est une clé publique encodée en PEM, spécifiez "format": "PEM", spécifiez l'identificateur de la clé statique utilisée pour signer le jeton Web JSON (JWT) comme valeur "kid" et fournissez la clé comme valeur "key".
    
    Par exemple :
```
        "keys": [
          {
            "format": "PEM",
            "kid": "master_key"
            "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
          }
        ]
```
    Notez que les marqueurs -----BEGIN PUBLIC KEY----- et -----END PUBLIC KEY----- sont obligatoires.
- "isSslVerifyDisabled": <true|false> indique si la vérification SSL doit être désactivée lors de la communication avec le fournisseur d'identités. Oracle recommande de ne pas régler cette option à true, car elle peut compromettre la validation JWT. Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- "maxCacheDurationInHours": <cache-time> indique le nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache JWKS après l'extraction.
- "additionalValidationPolicy": {"issuers": ...} spécifie des détails supplémentaires pour la validation du jeton :
  - <issuer-url> est l'URL (ou une chaîne de texte) d'un fournisseur d'identités autorisé dans la revendication de l'émetteur (iss) d'un JWT à utiliser pour accéder au déploiement d'API. Par exemple, pour activer un JWT émis par OCI IAM avec des domaines d'identité à utiliser pour accéder au déploiement d'API, entrez https://identity.oraclecloud.com/. Vous pouvez spécifier un ou plusieurs fournisseurs d'identités (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - <intended-audience> est une valeur autorisée dans la revendication de public (aud) d'un jeton Web JSON (JWT) pour identifier le destinataire prévu du jeton. Par exemple, le public peut être, mais n'a pas besoin d'être, le nom d'hôte de la passerelle d'API. Vous pouvez spécifier un ou plusieurs publics (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - verifyClaims spécifie facultativement des noms et des valeurs pour une ou plusieurs revendications supplémentaires à valider dans un jeton Web JSON (JWT) (dix au maximum).
    - "key": "<claim-name>" est le nom d'une revendication qui peut ou doit être incluse dans un jeton Web JSON (JWT). Le nom de revendication que vous spécifiez peut être un nom de revendication réservée tel que la revendication de sujet (sub) ou un nom de revendication personnalisée délivré par un fournisseur d'identités particulier.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (facultatif) indique une ou plusieurs valeurs acceptables pour la revendication.
    - "isRequired": <true|false> indique si la revendication doit être incluse dans le jeton Web JSON (JWT).
    Notez que les noms et valeurs de clé que vous entrez sont simplement traités comme des chaînes et doivent correspondre exactement avec les noms et les valeurs du jeton Web JSON (JWT). La correspondance de modèle et d'autres types de données ne sont pas pris en charge.
Par exemple, la politique authentication suivante configure la passerelle d'API avec une clé de vérification publique déjà émise par un fournisseur d'identités pour valider la JWT dans l'en-tête de la demande d'autorisation :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
(Facultatif) Vous pouvez spécifier comment vous voulez que la passerelle d'API traite une réponse d'authentification en échec (retournée après une tentative infructueuse de validation d'un jeton manquant ou non valide) en configurant une politique d'échec de validation :
1. Si vous voulez que la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse (réponse par défaut à un jeton manquant ou non valide), ne définissez pas de politique d'échec de validation.
2. Si vous voulez que la passerelle d'API utilise un flux d'autorisation OpenID Connect pour obtenir un nouveau jeton d'accès JWT, définissez une politique d'échec de validation de type OAUTH2. Notez que cette option n'est disponible que si vous avez spécifié une valeur validationPolicy de type REMOTE_DISCOVERY précédemment. Spécifiez les données suivantes :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        ...
      },
      "validationFailurePolicy": {
        "type": "OAUTH2",
        "scopes": ["<scope>", "<scope"],
        "clientDetails": {
          "type": "<VALIDATION_BLOCK|CUSTOM>",
          "clientId": "<client-id>",
          "clientSecretId": "<secret-ocid>",
          "clientSecretVersionNumber": <secret-version-number>
          },
        "sourceUriDetails": {
          "type": "VALIDATION_BLOCK"
          },
        "maxExpiryDurationInHours": <number-of-hours>,
        "useCookiesForSession": <true|false>,
        "useCookiesForIntermediateSteps": <true|false>,
        "usePkce": <true|false>,
        "responseType": "code",
        "fallbackRedirectPath": "<redirect-path>",
        "logoutPath": "<logout-path>"
      }
    }
  },
  "routes": [
    ...
  ]
}
```
  où :
  - "scopes": ["<scope>", "<scope"] spécifie une ou plusieurs portées d'accès à inclure dans une revendication scope envoyée au serveur d'autorisation. Pour utiliser le flux d'autorisation OpenID Connect, vous devez inclure openid dans l'une des portées. Par exemple, "scopes": ["openid", "email:read", "profile"]
  - clientDetails": {...} spécifie les détails du client à utiliser pour obtenir un nouveau jeton d'accès JWT auprès du serveur d'autorisations, comme suit :
    - "type": "<VALIDATION_BLOCK|CUSTOM>" indique s'il faut utiliser les mêmes détails de client ou des détails différents de ceux spécifiés dans la version précédente validationPolicy. Si vous voulez utiliser les mêmes détails de client qu'auparavant (ce qui est généralement le cas), spécifiez "type": "VALIDATION_BLOCK" et ne fournissez pas de détails supplémentaires. Si vous voulez utiliser des détails de client différents, spécifiez "type": "CUSTOM" et définissez des valeurs pour "clientId", "clientSecretId" et "clientSecretVersionNumber".
    - "clientId": "<client-id>" indique l'ID client à envoyer au point d'extrémité d'introspection. Utilisé uniquement si "type": "CUSTOM". Par exemple, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - "clientSecretId": "<secret-ocid>" indique l'OCID de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité de l'introspection. Utilisé uniquement si "type": "CUSTOM". Par exemple, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
    - "clientSecretVersionNumber": <secret-version-number> indique la version de la clé secrète de la chambre forte qui contient la clé secrète client à envoyer au point d'extrémité d'introspection. Utilisé uniquement si "type": "CUSTOM". Par exemple : 1
  - "sourceUriDetails": {"type": "VALIDATION_BLOCK"} indique que vous voulez utiliser la même URL que celle spécifiée dans l'instance validationPolicy précédente, ainsi que l'URL bien connue d'un serveur d'autorisation à partir duquel la passerelle d'API doit obtenir des points d'extrémité de métadonnées d'autorisation.
  - "maxExpiryDurationInHours": <number-of-hours> indique la durée de mise en mémoire cache du jeton JWT généré par le flux d'autorisation. La valeur par défaut est 1.
  - "useCookiesForSession": <true|false> indique comment stocker les jetons JWT nouvellement générés en tant que chaînes non lisibles par un humain à la fin d'un flux d'autorisation OpenID Connect :
    - Réglez cette option à true si vous voulez stocker le nouveau jeton JWT dans un témoin de session. Pour éviter les attaques CSRF potentielles, lorsque la passerelle d'API stocke le jeton dans un cookie de session, elle retourne également un jeton CSRF dans un en-tête de réponse X-CSRF-TOKEN. Les demandes suivantes (à l'exception des demandes GET) doivent inclure le jeton CSRF dans un en-tête de demande X-CSRF-TOKEN, en plus du jeton JWT dans le témoin de session qui est inclus automatiquement.
    - Réglez cette option à false si vous ne voulez pas stocker le nouveau jeton JWT dans un témoin de session. Au lieu de cela, la passerelle d'API retourne un jeton non lisible par l'homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes suivantes à la passerelle d'API doivent inclure le même jeton dans un en-tête de demande X-APIGW-TOKEN.
    Voir Notes sur la protection contre la falsification de demandes intersites (CSRF)
  - "useCookiesForIntermediateSteps": <true|false> indique comment stocker les valeurs d'étape intermédiaires du flux d'autorisation (par exemple, les paramètres de demande). Réglez cette option à true pour stocker les valeurs dans les témoins du navigateur. Réglez cette option à false pour stocker les valeurs avec la passerelle d'API.
  - "usePkce": <true|false> indique s'il faut utiliser PKCE (clé de vérification pour l'échange de code) pour une sécurité supplémentaire. PKCE est une extension de sécurité OAuth 2.0 pour empêcher les attaques par injection de code d'autorisation et de CSRF (Cross-Site Request Forgery). PKCE ne remplace pas une clé secrète client, et PKCE est recommandé même si une clé secrète client est utilisée. Pour plus d'informations sur PKCE, consultez la documentation sur OAuth 2.0.
  - "responseType": "code" spécifie le type de réponse requis du flux d'autorisation. Indiquez code comme type de réponse.
  - "fallbackRedirectPath": "/home" spécifie facultativement un chemin relatif dans le déploiement d'API courant vers lequel rediriger les clients d'API si la demande initiale était une demande PUT ou POST. Par exemple, /home.
    Si la demande initiale était une demande GET, le traitement de la demande reprend avec un nouveau jeton d'accès JWT, de sorte qu'un chemin de secours n'est pas utilisé.
  - "logoutPath": "<revoke-path>"indique éventuellement un chemin relatif vers un élément dorsal de déconnexion dans le déploiement d'API courant. Le chemin que vous spécifiez doit correspondre au chemin d'acheminement défini pour l'élément dorsal de déconnexion. Par exemple, "logoutPath": "/revoke".
    Un client d'API peut appeler l'élément dorsal de déconnexion pour révoquer des jetons. Un appel à l'élément dorsal de déconnexion peut inclure une URL après déconnexion en tant que paramètre d'interrogation nommé postLogoutUrl. Voir Ajout de la déconnexion en tant qu'élément dorsal du service de passerelle d'API.
  Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        ...
      },
      "validationFailurePolicy": {
        "type": "OAUTH2",
        "scopes": ["openid", "email:read", "profile"],
        "clientDetails": {
          "type": "VALIDATION_BLOCK"
          },
        "sourceUriDetails": {
          "type": "VALIDATION_BLOCK"
        },
        "maxExpiryDurationInHours": 2,
        "useCookiesForSession": true,
        "useCookiesForIntermediateSteps": true,
        "usePkce": true,
        "responseType": "code",
        "fallbackRedirectPath": "/home",
        "logoutPath": "/revoke"
      }
    }
  },
  "routes": [
    ...
  ]
}
```
3. Si vous voulez personnaliser la réponse à une tentative infructueuse de validation d'un jeton manquant ou non valide, définissez une politique d'échec de validation de type MODIFY_RESPONSE et spécifiez un code de statut (et un corps de message facultatif) pour retourner au client d'API, comme suit :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        ...
      },
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "<alternative-response-code>",
        "responseMessage": "<custom-message-body>",
        "responseTransformations": {
          "headerTransformations": {
            <valid-header-transformation-response-policy>
          }
        }
      }
    }
  },
  "routes": [
    ...
  ]
}
```
  où :
  - responseCode : Spécifie un autre code de statut HTTP. Par exemple, 500.
  - responseMessage : (Facultatif) Spécifie 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).
  - responseTransformations : (Facultativement) modifie les en-têtes de la réponse que la passerelle d'API retourne au client d'API en spécifiant une politique de réponse de transformation d'en-tête. Pour plus d'informations sur les politiques de transformation d'en-tête, voir Ajout de politiques de réponse de transformation d'en-tête.
  Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        ...
      },
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "500",
        "responseMessage": "Unfortunately, authentication failed.",
      }
    }
  },
  "routes": [
    ...
  ]
}
```
Ajoutez une politique de demande authorization pour chaque route de la spécification de déploiement d'API :
1. Insérez une section requestPolicies après la section backend de la première route, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Ajoutez la politique authorization suivante à la nouvelle section requestPolicies :
```
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
```
  où :
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indique comment accorder l'accès à la route :
    - "AUTHENTICATION_ONLY" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANY_OF" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la revendication scope du jeton Web JSON (JWT) inclut l'une des étendues d'accès que vous spécifiez dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANONYMOUS" : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez explicitement régler la propriété "isAnonymousAccessAllowed" à true dans la politique authentication de la spécification de déploiement d'API.
  - "allowedScope": ["<scope>" ] est une liste délimitée par des virgules, contenant une ou plusieurs chaînes correspondant aux étendues d'accès incluses dans la revendication scope du jeton Web JSON (JWT). Dans ce cas, vous devez régler la propriété type à "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est réglée à "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Notez également que si vous spécifiez plus d'une étendue, l'accès à la route est accordé si l'une des étendues que vous spécifiez est incluse dans la réclamation scope du jeton Web JSON (JWT).
  Par exemple, la politique de demande suivante définit une route /hello qui autorise uniquement les utilisateurs finaux authentifiés avec l'étendue read:hello à y accéder :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "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 politique de demande authorization pour toutes les routes restantes de la spécification de déploiement d'API.
Note

Si vous n'incluez pas de politique authorization pour une route particulière, l'accès est accordé comme si une telle politique existe et la propriété type est réglée à "AUTHENTICATION_ONLY". Autrement dit, quelle que soit la définition de la propriété isAnonymousAccessAllowed dans la politique authentication de la spécification de déploiement d'API :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès de la revendication scope du jeton Web JSON (JWT).
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
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.
(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).

Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS)

Le fournisseur d'identités qui a délivré le jeton Web JSON (JWT) détermine les valeurs autorisées que vous devez spécifier pour les revendications d'émetteur (iss) et de public (aud) du jeton Web JSON (JWT). Le fournisseur d'identités ayant délivré le jeton Web JSON (JWT) détermine également l'URI à partir duquel extraire le jeu de clés Web JSON (JWKS) pour vérifier la signature du jeton Web JSON (JWT).

Notez que, quel que soit le fournisseur d'identités, un JWKS peut contenir un maximum de dix clés.

Utilisez le tableau suivant pour savoir quoi spécifier pour les JWT émis par le service IAM pour OCI avec domaines d'identité, Oracle Identity Cloud Service (IDCS), Okta et les fournisseurs d'identités Auth0.


Fournisseur d'identités	Revendication d'émetteur (`iss`)	Revendication de public (`aud`)	Format de l'URI à partir duquel extraire le jeu de clés Web JSON (JWKS)
OCI IAM avec domaines d'identité	https://identity.oraclecloud.com	Spécifique au client. Voir Gestion des applications dans la documentation sur le service IAM pour OCI avec domaines d'identité.	https://<tenant-base-url>/admin/v1/SigningCert/jwk
IDCS	https://identity.oraclecloud.com/	Spécifique au client. Voir Validation des jetons d'accès dans la documentation sur le service Oracle Identity Cloud.	https://<tenant-base-url>/admin/v1/SigningCert/jwk Pour obtenir le jeu de clés Web JSON (JWKS) sans vous connecter au service Oracle Identity Cloud, voir Modifier les paramètres par défaut dans la documentation sur le service Oracle Identity Cloud.
Okta	https://<your-okta-tenant-name>.com	Spécifique au client. Public configuré pour le serveur d'autorisation dans Okta Developer Console. Voir Validation supplémentaire pour les jetons d'accès dans la documentation sur Okta.	https://<your-okta-tenant-name>.com/oauth2/<auth-server-id> /v1/keys Voir la documentation sur Okta.
Auth0	https://<your-account-name>.auth0.com/	Spécifique au client. Voir Public dans la documentation sur Auth0.	https://<your-account-name>.auth0.com/.well-known/jwks.json

Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)

Pour vérifier la signature d'un jeton Web JSON (JWT), les passerelles d'API nécessitent les paramètres de clé suivants dans le jeu de clés Web JSON (JWKS) retourné à partir d'un URI ou dans la clé statique Web JSON que vous spécifiez.


Paramètre de clé	Notes
`kid`	Identificateur de la clé utilisée pour signer le jeton Web JSON (JWT). La valeur doit correspondre à la revendication `kid` dans l'en-tête du jeton Web JSON (JWT). Par exemple `master_key`.
`kty`	Type de clé utilisée pour signer le jeton Web JSON (JWT). Notez que RSA est actuellement le seul type de clé pris en charge.
`use` ou `key_ops`	Si le paramètre `use` est présent, il doit être réglé à `sig`. Si le paramètre `key-ops` est présent, `verify` doit être l'une des valeurs valides.
`n`	Modulo de la clé publique.
`e`	Exposant de la clé publique.
`alg`	L'algorithme de signature (s'il est présent) doit être réglé à RS256, RS384 ou RS512.

Utilisation d'une politique de demande d'authentification JWT_AUTHENTICATION (n'est plus recommandée)

Note

Dans les versions antérieures, il se peut que vous ayez créé des politiques de demande d'authentification de type JWT_AUTHENTICATION pour utiliser des JWT pour l'authentification.

Notez que les politiques de demande JWT_AUTHENTICATION existantes sont toujours prises en charge. Notez également que, même si vous pouvez créer de nouvelles politiques de demande JWT_AUTHENTICATION en définissant la spécification de déploiement d'API dans un fichier JSON (comme décrit dans les instructions initiales de cette section), nous vous recommandons de créer des politiques de demande d'authentification de type TOKEN_AUTHENTICATION à la place.

Lors de l'utilisation d'une politique de demande d'authentification de type JWT_AUTHENTICATION, avant qu'un utilisateur final puisse accéder à un déploiement d'API qui utilise des JWT pour l'authentification et l'autorisation, il doit obtenir un JWT auprès d'un fournisseur d'identités.

Lors de l'appel d'une API déployée sur une passerelle d'API, le client d'API fournit le jeton Web JSON (JWT) comme paramètre d'interrogation ou dans l'en-tête de la demande. La passerelle d'API valide le jeton Web JSON (JWT) à l'aide d'une clé de vérification publique correspondante fournie par le fournisseur d'identités émetteur. À l'aide de la politique de demande d'authentification JWT_AUTHENTICATION du déploiement d'API, vous pouvez configurer la façon dont la passerelle d'API valide les JWT :

Vous pouvez configurer la passerelle d'API pour extraire les clés de vérification publiques auprès du fournisseur d'identités au moment de l'exécution. Dans ce cas, le fournisseur d'identités agit comme serveur d'autorisation.
Vous pouvez configurer la passerelle d'API à l'avance avec des clés de vérification publiques déjà délivrées par un fournisseur d'identités (appelées 'clés statiques'), ce qui permet à la passerelle d'API de vérifier les jetons Web JSON (JWT) localement au moment de l'exécution sans avoir à communiquer avec le fournisseur d'identités. Il en résulte une validation plus rapide des jetons.

Pour ajouter une nouvelle politique de demande d'authentification et d'autorisation JWT_AUTHENTICATION à une spécification de déploiement d'API dans un fichier JSON :

Ajoutez une politique de demande authentication qui s'applique à toutes les routes 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 politique authentication suivante à la nouvelle section requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": <true|false>,
      "issuers": ["<issuer-url>", "<issuer-url>"],
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
      "tokenAuthScheme": "<authentication-scheme>",
      "audiences": ["<intended-audience>"],
      "publicKeys": {
        "type": <"REMOTE_JWKS"|"STATIC_KEYS">,
        <public-key-config>
      },
      "verifyClaims": [
        {"key": "<claim-name>",
         "values": ["<acceptable-value>", "<acceptable-value>"],
         "isRequired": <true|false>
        }
      ],
      "maxClockSkewInSeconds": <seconds-difference>
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - "isAnonymousAccessAllowed": <true|false> indique facultativement si des utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes de la spécification de déploiement d'API. Si vous voulez que des utilisateurs finaux anonymes ne puissent jamais accéder aux routes, réglez cette propriété à false. Si vous n'incluez pas cette propriété dans la politique authentication, la valeur par défaut false est utilisée. Notez que si vous n'incluez pas cette propriété et que vous la réglez à true, vous devez également spécifier explicitement toutes les routes auxquelles l'accès anonyme est autorisé en réglant la propriété type à "ANONYMOUS" dans la politique authorization de chaque route.
  - <issuer-url> est l'URL (ou une chaîne de texte) d'un fournisseur d'identités autorisé dans la revendication d'émetteur (iss) d'un jeton Web JSON (JWT) à utiliser pour accéder au déploiement d'API. Par exemple, pour activer un JWT émis par OCI IAM avec des domaines d'identité à utiliser pour accéder au déploiement d'API, entrez https://identity.oraclecloud.com/. Vous pouvez spécifier un ou plusieurs fournisseurs d'identités (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indique si c'est un en-tête de demande qui contient le JWT (et, si oui, le nom de l'en-tête) ou un paramètre d'interrogation qui contient le JWT (et, si oui, le nom du paramètre d'interrogation). Notez que vous pouvez spécifier "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mais pas les deux.
  - <tokenAuthScheme> est le nom du schéma d'authentification à utiliser si le jeton Web JSON (JWT) est contenu dans un en-tête de demande. Par exemple "Bearer".
  - <intended-audience> est une valeur autorisée dans la revendication de public (aud) d'un jeton Web JSON (JWT) pour identifier le destinataire prévu du jeton. Par exemple, le public peut être, mais n'a pas besoin d'être, le nom d'hôte de la passerelle d'API. Vous pouvez spécifier un ou plusieurs publics (cinq au maximum). Voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS).
  - "type": <"REMOTE_JWKS"|"STATIC_KEYS"> indique la manière dont vous voulez que la passerelle d'API valide les jetons Web JSON (JWT) à l'aide de clés de vérification publiques. Spécifiez REMOTE_JWKS pour configurer la passerelle d'API afin d'extraire jusqu'à dix clés de vérification publiques du fournisseur d'identités au moment de l'exécution. Spécifiez STATIC_KEYS pour configurer la passerelle d'API avec jusqu'à dix clés de vérification publiques déjà émises par un fournisseur d'identités (en activant la passerelle d'API pour vérifier les JWT localement sans avoir à communiquer avec le fournisseur d'identités).
  - <public-key-config> fournit les détails de la validation du jeton Web JSON (JWT), selon que vous avez spécifié "REMOTE_JWKS" ou "STATIC_KEYS" en tant que valeur "type", comme suit :
    - Si vous avez spécifié "type": "REMOTE_JWKS" pour configurer la passerelle d'API afin de valider les jetons Web JSON (JWT) en extrayant les clés de vérification publiques du fournisseur d'identités au moment de l'exécution, fournissez les détails suivants :
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "<uri-for-jwks>", "maxCacheDurationInHours": <cache-time>, "isSslVerifyDisabled": <true|false> }
      où :
      - "uri": "<uri-for-jwks>" spécifie l'URI à partir duquel extraire le jeu de clés Web JSON (JWKS) à utiliser pour vérifier la signature des jetons Web JSON (JWT). Pour plus d'informations sur l'URI à spécifier, voir Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS). Notez ce qui suit :
        
        L'URI doit être routable à partir du sous-réseau contenant la passerelle d'API sur laquelle l'API est déployée.
        
        Si la passerelle d'API ne parvient pas à extraire le jeu de clés Web JSON (JWKS), toutes les demandes au déploiement d'API retournent un code de réponse HTTP 500. Pour plus d'informations sur l'erreur, consultez le journal d'exécution de la passerelle d'API (voir Ajout de la journalisation aux déploiements d'API).
        
        Certains paramètres de clé doivent être présents dans le jeu de clés Web JSON (JWKS) pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)).
        
        Le JWKS peut contenir jusqu'à dix clés.
      - "maxCacheDurationInHours": <cache-time> indique le nombre d'heures (entre 1 et 24) pendant lesquelles la passerelle d'API doit mettre en mémoire cache JWKS après l'extraction.
      - "isSslVerifyDisabled": <true|false> indique si la vérification SSL doit être désactivée lors de la communication avec le fournisseur d'identités. Oracle recommande de ne pas régler cette option à true, car elle peut compromettre la validation des jetons Web JSON (JWT). Le service de passerelle d'API apprécie les certificats émis par plusieurs autorités de certification pour le service IAM pour OCI avec des domaines d'identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
      Par exemple :
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "https://www.somejwksprovider.com/oauth2/v3/certs", "maxCacheDurationInHours": 3, "isSslVerifyDisabled": false }
    - Si vous avez spécifié "type": "STATIC_KEYS", les détails à fournir dépendent du format de la clé déjà délivrée par le fournisseur d'identités (peu importe le format, vous pouvez spécifier jusqu'à dix clés) :
      - Si la clé statique est une clé Web JSON, spécifiez "format": "JSON_WEB_KEY", spécifiez l'identificateur de la clé statique utilisée pour signer le jeton Web JSON (JWT) comme valeur du paramètre "kid" et fournissez les valeurs des autres paramètres pour vérifier la signature du jeton Web JSON (JWT).
        
        Par exemple :
        
        "publicKeys": { "type": "STATIC_KEYS", "keys": [ { "format": "JSON_WEB_KEY", "kid": "master_key", "kty": "RSA", "n": "0vx7agoebGc...KnqDKgw", "e": "AQAB", "alg": "RS256", "use": "sig" } ]
        
        Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du jeton Web JSON (JWT) (voir Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)). Notez également que RSA est actuellement le seul type de clé pris en charge (kty).
      - Si la clé statique est une clé publique encodée en PEM, spécifiez "format": "PEM", spécifiez l'identificateur de la clé statique utilisée pour signer le jeton Web JSON (JWT) comme valeur "kid" et fournissez la clé comme valeur "key".
        
        Par exemple :
        
        "publicKeys": { "type": "STATIC_KEYS", "keys": [ { "format": "PEM", "kid": "master_key" "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY----- } ]
        
        Notez que les marqueurs -----BEGIN PUBLIC KEY----- et -----END PUBLIC KEY----- sont obligatoires.
  - verifyClaims spécifie facultativement des noms et des valeurs pour une ou plusieurs revendications supplémentaires à valider dans un jeton Web JSON (JWT) (dix au maximum).
    - "key": "<claim-name>" est le nom d'une revendication qui peut ou doit être incluse dans un jeton Web JSON (JWT). Le nom de revendication que vous spécifiez peut être un nom de revendication réservée tel que la revendication de sujet (sub) ou un nom de revendication personnalisée délivré par un fournisseur d'identités particulier.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (facultatif) indique une ou plusieurs valeurs acceptables pour la revendication.
    - "isRequired": <true|false> indique si la revendication doit être incluse dans le jeton Web JSON (JWT).
    Notez que les noms et valeurs de clé que vous entrez sont simplement traités comme des chaînes et doivent correspondre exactement avec les noms et les valeurs du jeton Web JSON (JWT). La correspondance de modèle et d'autres types de données ne sont pas pris en charge.
  - maxClockSkewInSeconds: <seconds-difference> spécifie facultativement la différence de temps maximale entre les horloges système du fournisseur d'identités qui a délivré un jeton Web JSON (JWT) et la passerelle d'API. La valeur que vous spécifiez est prise en compte lorsque la passerelle d'API valide le jeton Web JSON (JWT) pour déterminer s'il est toujours valide, à l'aide de la revendication Pas avant (nbf) (si elle est présente) et de la revendication d'expiration (exp) dans le jeton Web JSON (JWT). La valeur minimale (et par défaut) est 0, la valeur maximale est 120.
  Par exemple, la politique authentication suivante configure la passerelle d'API avec une clé de vérification publique déjà émise par un fournisseur d'identités pour valider la JWT dans l'en-tête de la demande d'autorisation :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Ajoutez une politique de demande authorization pour chaque route de la spécification de déploiement d'API :

Insérez une section requestPolicies après la section backend de la première route, si elle n'existe pas déjà. Par exemple :

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}

Ajoutez la politique authorization suivante à la section requestPolicies :

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "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 à la route :
- "AUTHENTICATION_ONLY" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
- "ANY_OF" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la revendication scope du jeton Web JSON (JWT) inclut l'une des étendues d'accès que vous spécifiez dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
- "ANONYMOUS" : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez explicitement régler la propriété "isAnonymousAccessAllowed" à true dans la politique authentication de la spécification de déploiement d'API.
"allowedScope": ["<scope>" ] est une liste délimitée par des virgules, contenant une ou plusieurs chaînes correspondant aux étendues d'accès incluses dans la revendication scope du jeton Web JSON (JWT). Dans ce cas, vous devez régler la propriété type à "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est réglée à "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Notez également que si vous spécifiez plus d'une étendue, l'accès à la route est accordé si l'une des étendues que vous spécifiez est incluse dans la réclamation scope du jeton Web JSON (JWT).

Par exemple, la politique de demande suivante définit une route /hello qui autorise uniquement les utilisateurs finaux authentifiés avec l'étendue read:hello à y accéder :

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "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" ]
        }
      }
    }
  ]
}

Ajoutez une politique de demande authorization pour toutes les routes restantes de la spécification de déploiement d'API.

Note

Si vous n'incluez pas de politique authorization pour une route particulière, l'accès est accordé comme si une telle politique existe et la propriété type est réglée à "AUTHENTICATION_ONLY". Autrement dit, quelle que soit la définition de la propriété isAnonymousAccessAllowed dans la politique authentication de la spécification de déploiement d'API :

Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
Tous les utilisateurs authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès de la revendication scope du jeton Web JSON (JWT).
Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.

Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
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.
(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).

Exemple : Migration d'une politique de demande JWT_AUTHENTICATION vers une politique de demande TOKEN_AUTHENTICATION

Cette section présente un exemple de politique de demande JWT_AUTHENTICATION existante migrée vers une politique TOKEN_AUTHENTICATION.

Une façon d'aborder la migration consiste à créer une politique de demande TOKEN_AUTHENTICATION vide, puis à l'alimenter avec des valeurs de la politique de demande JWT_AUTHENTICATION

Avant la migration :

La politique de demande JWT_AUTHENTICATION initiale, avant la migration :

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "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" ]
        }
      }
    }
  ]
}

Après la migration :

La nouvelle politique de demande TOKEN_AUTHENTICATION alimentée avec les valeurs de la politique de demande JWT_AUTHENTICATION initiale :

{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "additionalValidationPolicy": {
          "audiences": [
            "api.dev.io"
          ],
          "verifyClaims": [
            {
              "key": "is_admin",
              "values": [
                "service:app",
                "read:hello"
              ],
              "isRequired": true
            }
          ],
          "issuers": [
            "https://identity.oraclecloud.com/"
          ]
        }
      }
    }
  },
  "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"
          ]
        }
      }
    }
  ]
}

Documentation sur Oracle Cloud Infrastructure

Validation des jetons pour ajouter l'authentification et l'autorisation aux déploiements d'API

Que se passe-t-il lors de l'authentification par jeton?

Notes sur les jetons Web JSON (JWT)

Notes sur OAuth 2.0 et OpenID Connect

Notes sur la protection contre la falsification de demandes intersites (CSRF)

Notes sur l'utilisation des politiques de demande JWT_AUTHENTICATION

Préalables pour l'authentification par jeton

Utilisation de la console pour ajouter des politiques de demande d'autorisation et d'authentification par jeton

Modification d'un fichier JSON pour ajouter des politiques de demande d'autorisation et d'authentification par jeton

Détails du fournisseur d'identités à utiliser pour les revendications iss et aud ainsi que pour l'URI du jeu de clés Web JSON (JWKS)

Paramètres de clé requis pour vérifier les signatures des jetons Web JSON (JWT)

Utilisation d'une politique de demande d'authentification JWT_AUTHENTICATION (n'est plus recommandée)

Exemple : Migration d'une politique de demande JWT_AUTHENTICATION vers une politique de demande TOKEN_AUTHENTICATION

Avant la migration :

Après la migration :