Plate-forme api jeton jwt

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 de valider elle-même les jetons inclus dans une demande (comme décrit dans cette rubrique). Vous pouvez également faire en sorte que la passerelle d’API transmette un jeton d’accès à plusieurs arguments ou à argument unique inclus dans une demande à une fonction d’habilitation déployée sur OCI Functions à des fins de validation (comme décrit dans la section Transmission de jetons à des fonctions d’autorisation pour ajouter une authentification et une autorisation aux déploiements d’API).

Pour que la passerelle d’API valide elle-même le jeton inclus dans une demande, vous devez créer une stratégie 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 stratégie TOKEN_AUTHENTICATION, vous activez le déploiement d’une API pour utiliser des jetons pour l’authentification et l’autorisation en incluant deux types différents de stratégie de demande dans la spécification de déploiement d’API :

Une stratégie de demande d’authentification pour l’ensemble du déploiement d’API qui spécifie l’utilisation des jetons, y compris la façon de les valider et si les utilisateurs finaux non authentifiés peuvent accéder aux itinéraires dans le déploiement d’API.
Une stratégie de demande d’autorisation pour chaque itinéraire qui spécifie les opérations qu’un utilisateur final est autorisé à effectuer, éventuellement en fonction des valeurs spécifiées pour la revendication d’un JWT.

Vous pouvez ajouter des stratégies de demande d’authentification et d’autorisation à une spécification de déploiement d’API en procédant comme suit :

l’aide de la console.
Modification d’un fichier JSON.

Remarque

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

Valider les jetons JWT et les jetons non JWT.
Validez les jetons à l’aide d’un fournisseur d’identité pour obtenir un point de terminaison d’introspection.
Spécifiez des stratégies d’échec de validation, y compris la génération d’un nouveau jeton JWT en cas de jeton JWT non valide ou manquant dans la demande d’origine.

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 stratégie d’authentification par 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 que la stratégie de validation de la stratégie d’authentification de jeton est l’un des types suivants :

Point de terminaison d’introspection OAuth 2.0 : spécifiez ce type de stratégie de validation si vous souhaitez que la passerelle d’API valide un jeton JWT ou non-JWT avec le point de terminaison d’introspection d’un fournisseur d’identité. Vous devez spécifier l’URL de découverte du fournisseur d’identité à partir duquel obtenir le point de terminaison d’introspection. Dans ce cas, la passerelle d’API transmet les informations d’identification du client (l’ID du client, ainsi que la clé secrète du client récupérée du service Vault) au fournisseur d’identité 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 vous souhaitez que la passerelle d’API mette en cache la réponse à partir du point de terminaison Introspection, pendant 1 heure (par défaut) et 24 heures. Si vous définissez la spécification de déploiement de l’API dans un fichier JSON et que vous souhaitez ce comportement, incluez une stratégie de validation de type .
JWKS distants : spécifiez ce type de stratégie de validation si vous souhaitez que la passerelle API utilise des clés de vérification publiques récupérées auprès d’un fournisseur d’identité au moment de l’exécution pour vérifier un JWT. Dans ce cas, la passerelle d’API contacte le fournisseur d’identité pour vérifier le JWT. Le fournisseur d’identité fait office de serveur d’autorisation. Si vous définissez la spécification de déploiement de l’API dans un fichier JSON et que vous souhaitez ce comportement, incluez une stratégie de validation de type .
Clés statiques : spécifiez ce type de stratégie de validation si vous souhaitez que la passerelle API utilise des clés de vérification publiques déjà émises par un fournisseur d’identité (appelées « clés statiques ») pour vérifier un JWT. Dans ce Dans ce cas, la passerelle d’API peut vérifier le JWT localement au moment de l’exécution sans avoir à contacter le fournisseur d’identité. Le résultat est 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 souhaitez ce comportement, incluez une stratégie de validation de type

Si la validation réussit, la passerelle d’API achemine la demande vers le point de terminaison d’API approprié.

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

Par défaut (HTTP 401 non autorisé) : spécifiez ce type de stratégie d’échec de validation si vous souhaitez que la passerelle API renvoie une réponse HTTP-401 au client API. Il s’agit de la réponse par défaut. Si vous définissez la spécification de déploiement de l’API dans un fichier JSON et que vous souhaitez Ce comportement n’inclut tout simplement pas de politique d’échec de validation.
Réponse personnalisée : spécifiez ce type de stratégie d’échec de validation si vous souhaitez que la passerelle d’API renvoie 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 de l’API dans un fichier JSON et que vous souhaitez ce comportement, incluez une politique d’échec de validation de type .
OAuth 2.0 : spécifiez ce type de stratégie d’échec de validation si vous souhaitez que la passerelle d’API obtienne un nouveau jeton JWT valide du fournisseur d’identité pour les requêtes GET (après avoir stocké en toute sécurité les paramètres de requête de requête d’origine). Pour les requêtes PUT et POST, vous pouvez spécifier un chemin d’accès relatif dans le déploiement d’API actuel vers lequel rediriger les clients API. Si vous définissez la spécification de déploiement de l’API dans un fichier JSON et que vous souhaitez comportement, inclure une politique d’échec de validation de type .
Notez que les stratégies d’échec de validation de type OAuth 2.0 ne prennent actuellement en charge que le flux d’autorisation OpenID Connect et uniquement la génération de jetons JWT (voir Notes sur OAuth 2.0 et OpenID Connect). Dans le cas du flux d’autorisation OpenID Connect, deux jetons nommés (toujours encodés en JWT) et (pouvant être encodés en JWT) sont renvoyés. La passerelle d’API enregistre les valeurs de jeton dans les variables de contexte et les variables de contexte, ainsi que les revendications personnalisées dans les variables de contexte respectivement (voir Ajout de variables de contexte aux stratégies et Définitions de back-end HTTP). À la réception du nouveau jeton JWT, la passerelle d’API récupère 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 de terminaison d’introspection OAuth 2.0 , à distance, à distance, JWKS ou clés statiques ) et le type de stratégie d’échec de validation (par défaut (HTTP 401 non autorisé), Réponse personnalisée ou OAuth 2.0 ), comme suit :

Si vous spécifiez à la fois une stratégie de validation de type OAuth 2.0 point de terminaison d’introspection et une stratégie 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
- 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 de requête que vous spécifiez dans la stratégie d’authentification de jeton.

Si la validation du jeton réussit par la suite et vous avez sélectionné les Notes sur la protection contre la falsification de requête intersite (CSRF).
Si vous ne spécifiez pas à la fois une stratégie de validation de type OAuth 2.0 et une stratégie 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 de requête que vous spécifiez dans la stratégie d’authentification de jeton.

Remarques 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 JWT est un jeton d’accès basé sur JSON envoyé dans une requête HTTP d’un client API à une ressource. Les JWT sont délivrés par des fournisseurs d’identité. API Gateway prend en charge l’utilisation de tout fournisseur d’identité conforme à OAuth2, tel qu’OCI IAM avec domaines d’identité, Oracle Identity Cloud Service (IDCS), Auth0 et Okta. Si un JWT est nécessaire pour accéder à une ressource, la ressource valide le JWT auprès d’un serveur d’autorisation à l’aide d’une clé de vérification publique correspondante, soit en appelant un point de terminaison de validation sur le serveur d’autorisation, soit à l’aide d’une clé de vérification locale fournie par le serveur d’autorisation.

Un JWT comprend :

Un en-tête, qui identifie le type de jeton et l’algorithme cryptographique utilisé pour générer la signature.
Charge utile, contenant des revendications sur l’identité de l’utilisateur final et les propriétés du JWT lui-même. Une revendication est une paire clé-valeur, où la clé est le nom de la revendication. Il est recommandé (mais pas obligatoire) qu’une charge utile contienne certaines revendications réservées avec des noms particuliers, tels que le délai d’expiration (), l’audience (), l’émetteur (), et non avant (). Une charge utile peut également contenir des revendications personnalisées avec des noms définis par l’utilisateur.
Une signature, pour valider l’authenticité du JWT (dérivé de l’encodage base64 de l’en-tête et de la charge utile).

Lorsque vous utilisez des JWT pour contrôler l’accès aux API, vous pouvez spécifier que les revendications réservées dans la charge utile du JWT doivent avoir des valeurs particulières avant que la passerelle d’API considère le JWT comme valide. Par défaut, les passerelles d’API valident les JWT à l’aide des revendications d’expiration (), d’audience () et d’émetteur (), ainsi que de la revendication pas avant () si elle est présente. Vous pouvez également spécifier des valeurs acceptables pour les revendications personnalisées. Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.

Lorsqu’un JWT a été validé, la passerelle d’API extrait les revendications de la charge utile du JWT sous forme de paires clé-valeur et les enregistre en tant qu’enregistrements dans la table de contexte pour être utilisée par le déploiement de l’API. Par exemple, en tant que variables de contexte à utiliser dans une définition de back-end HTTP (voir Ajout de variables de contexte aux stratégies et Définitions de back-end HTTP). Si la charge utile du JWT contient la revendication, vous pouvez Utilisez les valeurs de la revendication dans les stratégies de demande d’autorisation pour les itinéraires individuels afin de spécifier les opérations qu’un utilisateur final est autorisé à effectuer.

Remarques sur OAuth 2.0 et OpenID Connect

Le protocole OAuth 2.0 permet de récupérer en toute sécurité des ressources sécurisées tout en protégeant les informations d’identification des clients. OAuth 2.0 est un protocole flexible et sécurisé qui s’appuie sur SSL (Secure Sockets Layer) pour garantir la confidentialité des données entre les serveurs Web et les navigateurs. Bien qu’OAuth 2.0 soit différent de JWT et utilisé à des fins différentes, OAuth 2.0 et JWT sont compatibles. Étant donné que le protocole OAuth2 ne spécifie pas le format des jetons, les JWT peuvent être incorporés dans l’utilisation d’OAuth2. Pour plus d’informations sur OAuth 2.0, consultez la documentation OAuth 2.0.

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

Remarques sur la protection CSRF (Cross-Site Request Forgery)

Lorsque vous définissez une stratégie de validation de point de terminaison d’introspection de type OAuth 2.0 et une stratégie 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’icône

Notez que la passerelle d’API stocke également le jeton CSRF dans la variable de contexte. Si, pour une raison quelconque, le client API n’est pas en mesure de lire l’en-tête de réponse X-CSRF-TOKEN initial, vous pouvez inclure la variable de contexte dans une stratégie 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 renvoyée au client API. Cette approche garantit que le client d’API peut extraire 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 ultérieurs qu’il envoie à la passerelle d’API. Voici un exemple de stratégie de réponse de transformation d’en-tête appropriée :

Pour plus d’informations sur les stratégies de réponse de transformation d’en-tête, consultez Ajout de stratégies de réponse de transformation d’en-tête.
Au lieu de cela, la passerelle d’API renvoie un jeton non lisible par l’homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes ultérieures adressées à 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 le CSRF, effectuez une recherche en ligne.

Remarques sur l’utilisation des stratégies de demande de JWT_AUTHENTICATION

Dans les précédents , vous avez peut-être créé des stratégies de demande d’authentification de type JWT_AUTHENTICATION pour utiliser les JWT pour l’authentification.

Si vous créez de nouvelles stratégies de demande d’authentification pour utiliser les JWT, nous vous recommandons désormais de créer des stratégies de demande d’authentification de type TOKEN_AUTHENTICATION (consultez Utilisation de la console pour ajouter des stratégies d’authentification par jeton et de demande d’autorisation et Modification d’un fichier JSON pour ajouter des stratégies d’authentification par jeton et de demande d’autorisation). Nous vous recommandons également de migrer les stratégies de demande de JWT_AUTHENTICATION existantes vers TOKEN_AUTHENTICATION stratégies.

Notez que les stratégies de demande de JWT_AUTHENTICATION existantes sont toujours prises en charge. Notez également que, bien que vous puissiez créer de nouvelles stratégies de demande de JWT_AUTHENTICATION (comme décrit dans les instructions d’origine de la section Utilisation d’une JWT_AUTHENTICATION Stratégie de demande d’authentification (n’est plus recommandée)), nous vous recommandons de créer une authentification Demander des stratégies de type TOKEN_AUTHENTICATION à la place.

Conditions préalables à l’authentification par jeton

Avant de pouvoir activer l’authentification et l’autorisation pour les déploiements d’API à l’aide de JWT :

Un fournisseur d’identité 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 souhaitez utiliser des revendications personnalisées dans les stratégies d’autorisation, le fournisseur d’identité doit être configuré pour ajouter les revendications personnalisées aux JWT qu’il émet.

Pour plus d’informations, reportez-vous à la documentation du fournisseur d’identité (par exemple, la documentation OCI IAM avec Identity Domains, la documentation Oracle Identity Cloud Service (IDCS), la documentation Auth0).

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

l’algorithme de signature utilisé pour générer la signature du JWT doit être l’un des RS256, RS384 ou RS512
La clé de vérification publique doit avoir une longueur minimale de 2048 bits et ne doit pas dépasser 4096 bits

Pour valider des jetons à l’aide du point de terminaison d’introspection d’un serveur d’autorisation :

Utilisation de la console pour ajouter des stratégies d’authentification et de demande d’autorisation de jeton

Pour ajouter des stratégies 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, puis entrez les détails sur la page Informations de base.

Pour plus d’informations, consultez Déploiement d’une API sur une passerelle d’API en créant un déploiement d’API et Mise à jour d’une passerelle API ou d’un déploiement d’API.
Cliquez sur Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour spécifier que vous souhaitez utiliser un serveur d’authentification unique pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d’authentification. Sinon, si vous souhaitez utiliser plusieurs serveurs d’authentification, sélectionnez Multi-authentification et suivez les instructions de la section Utilisation de la console pour ajouter plusieurs serveurs d’authentification au même déploiement d’API.
Cochez ou décochez 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 dans le déploiement de l’API.

Par défaut, cette option n’est pas sélectionnée. Si vous ne voulez jamais Pour pouvoir accéder aux routes, ne sélectionnez pas cette option. Notez que si vous sélectionnez cette option, vous devez également spécifier explicitement chaque itinéraire auquel l’accès anonyme est autorisé en sélectionnant Anonyme comme type d’autorisation dans la politique d’autorisation de chaque itinéraire.
Sélectionnez OAuth 2.0 / OpenID Connect dans la liste d’options Type d’authentification et spécifiez :
- Emplacement du jeton : si les jetons sont contenus dans un en-tête de demande ou un paramètre de requête.
- Détails du jeton d’authentification : selon que les jetons sont contenus dans un en-tête de demande ou un paramètre de requête, spécifiez :
  - Nom de l’en-tête de jeton : et Schéma d’authentification : si des jetons sont contenus dans une demande , entrez le nom de l’en-tête (par exemple) et le schéma d’authentification HTTP (seul est actuellement pris en charge).
  - Nom du paramètre de jeton : si des jetons sont contenus dans un paramètre de requête, entrez le nom du paramètre de requête.
Spécifiez la façon dont vous souhaitez que la passerelle d’API valide les jetons :
1. si vous souhaitez que la passerelle d’API valide à la fois les jetons JWT et les jetons non-JWT avec le point de terminaison d’introspection d’un serveur d’autorisation OAuth 2.0 à l’aide des informations d’identification du client (y compris une clé secrète client récupérée à partir d’un coffre dans le service Vault), sélectionnez Point de terminaison d’introspection OAuth 2.0 dans la liste Type et spécifiez :
  - ID client : ID client à envoyer au point de terminaison d’introspection. Vous obtenez un ID client en créant et en inscrivant une application cliente auprès de le serveur d’autorisation. Par exemple. Reportez-vous à la section Conditions préalables à l’authentification par jeton.
  - Coffre-fort dans <nom-compartiment> : nom d’un coffre-fort dans le service Vault qui contient la clé secrète client à envoyer au point de terminaison d’introspection. Vous obtenez une clé secrète client en créant et en inscrivant une application cliente auprès du serveur d’autorisation. Reportez-vous à la section Conditions préalables à l’authentification par jeton.
  - Clé secrète de coffre-fort dans <nom du compartiment > : nom d’une clé secrète de coffre-fort qui contient la clé secrète client à envoyer au point de terminaison d’introspection.
  - Numéro de version de la clé secrète du coffre-fort : version de la clé secrète du coffre-fort qui contient la clé secrète du client à envoyer au point de terminaison d’introspection.
  - URL de découverte : URL connue du serveur d’autorisation à partir duquel la passerelle API doit obtenir les métadonnées d’autorisation Terminaison. Par exemple.
    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 maximale du cache en heures : nombre d’heures (entre 1 et 24) pendant lesquelles la passerelle d’API doit mettre en cache la réponse à partir du point de terminaison d’introspection.
  - Asymétrie maximale de l’horloge 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 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, à l’aide de la revendication pas avant () (le cas échéant) et de la revendication d’expiration () dans le JWT. Le minimum (et par défaut) est , le maximum est .
  - Désactiver la vérification SSL : indique s’il faut désactiver la vérification SSL lors de la communication avec le serveur d’autorisation. Par 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. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
2. Si vous souhaitez que la passerelle d’API valide les JWT en récupérant les clés de vérification publiques du fournisseur d’identité au moment de l’exécution, sélectionnez JWKS distants dans la liste Type et spécifiez :
  - JWKS URI : URI à partir duquel récupérer 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, consultez Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI 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 à récupérer les JWK, toutes les requêtes adressées au déploiement d’API renvoient un code de réponse HTTP 500. Pour plus d’informations sur l’erreur, reportez-vous au journal d’exécution de la passerelle d’API (voir Ajout de la journalisation aux déploiements d’API).
    - Certains paramètres clés doivent être présents dans le JWKS pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT).
    - Le JWKS peut contenir jusqu’à dix clés.
  - Durée maximale du cache en heures : nombre d’heures (entre 1 et 24) pendant lesquelles la passerelle d’API doit mettre en cache le JWKS après l’avoir récupéré.
  - Désactiver la vérification SSL : Indique s’il faut désactiver la vérification SSL lors de la communication avec le fournisseur d’identité. Par 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 JWT. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
3. Si vous souhaitez que la passerelle d’API valide les JWT avec des clés de vérification publiques déjà émises par un fournisseur d’identité (ce qui permet à la passerelle d’API de vérifier les JWT localement sans avoir à contacter le fournisseur d’identité), sélectionnez Clés statiques dans la liste Type et spécifiez jusqu’à dix clés statiques :
  - ID de clé : Identificateur de la clé statique utilisée pour signer le JWT. La valeur doit correspondre à la revendication dans l’en-tête JWT. Par exemple.
  - Format de la clé : Le format de la clé statique, soit un Clé Web JSON ou clé publique encodée PEM.
    - Clé Web JSON : si la clé statique est une clé Web JSON, collez-la dans ce champ.
      
      Par exemple :
      
      Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT). Notez également que est actuellement le seul type de clé pris en charge ().
    - Clé publique encodée PEM : si la clé statique est une clé publique codée PEM, collez-la dans ce champ. Par exemple :
      
      Notez que les marqueurs et sont obligatoires.
  - Une autre touche : cliquez 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 le Émetteurs
  - : spécifiez l’URL (ou une chaîne de texte) d’un fournisseur d’identité autorisé dans la revendication d’émetteur () d’un JWT à utiliser pour accéder au déploiement de l’API. Par exemple, pour activer l’utilisation d’un JWT émis par OCI IAM avec des domaines d’identité pour accéder au déploiement de l’API, entrez . Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - Autre émetteur : cliquez pour ajouter des fournisseurs d’identité supplémentaires (jusqu’à un maximum de cinq).
2. Dans la section Audiences, spécifiez les valeurs autorisées dans la revendication audience () d’un JWT utilisé pour accéder au déploiement de l’API :
3. Revendications validation : (Facultatif) En plus des valeurs des revendications d’audience et d’émetteur que vous avez déjà spécifiées, vous pouvez spécifier des noms et des valeurs pour une ou plusieurs revendications supplémentaires à valider dans un JWT. Notez que tous les noms de clés et valeurs que vous entrez sont simplement traités comme des chaînes de caractères et doivent correspondre exactement aux noms et aux valeurs du JWT. La correspondance de modèles et d’autres types de données ne sont pas pris en charge.
  - La revendication est obligatoire : spécifiez si la revendication dans le champ Clé de revendication doit être incluse dans le JWT.
  - Clé de revendication : (Facultatif) Spécifiez le nom d’une revendication qui peut ou doit être incluse dans un JWT. Si la revendication doit être incluse dans le JWT, sélectionnez Obligatoire . Le nom de revendication que vous spécifiez peut être un nom de revendication réservé, tel que la revendication objet (), ou un nom de revendication personnalisé émis par un fournisseur d’identité particulier.
  - Valeurs de revendication : (Facultatif) Spécifiez une valeur acceptable pour la revendication dans le champ Clé de revendication. Cliquez sur le signe plus (+) pour saisir une autre valeur acceptable. Si vous spécifiez une ou plusieurs valeurs acceptables pour la revendication, la passerelle d’API vérifie que la revendication contient l’une des valeurs que vous spécifiez.
  Notez que vous pouvez spécifier une revendication dans un JWT sans spécifier de valeur pour celle-ci. Pour ce faire, entrez le nom de la revendication dans le champ Clé de revendication, laissez le champ Valeurs de la revendication vide et définissez La revendication est obligatoire le cas échéant.
Spécifiez la manière dont vous souhaitez que la passerelle d’API gère une réponse d’authentification ayant échoué (renvoyée après une tentative infructueuse de validation d’un jeton manquant ou non valide) en configurant une stratégie d’échec de validation :
1. Si vous souhaitez que l’API pour envoyer un code d’état HTTP 401 et l’en-tête de 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 souhaitez que la passerelle 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é le point de terminaison d’introspection OAuth 2.0 dans la liste Type de validation précédemment. Spécifier :
  - Étendues : Une ou plusieurs étendues d’accès à inclure dans une revendication envoyée au serveur d’autorisation. Pour utiliser le flux d’autorisation OpenID Connect, vous devez l’inclure dans l’une des étendues. Par exemple.
  - Type de réponse : type de réponse requis à partir du flux d’autorisation. Entrez comme type de réponse.
  - Chemin de redirection de secours : (facultatif) chemin d’accès relatif dans le déploiement d’API actuel vers lequel rediriger les clients d’API si la demande d’origine était une demande PUT ou une demande POST. Par exemple,
    si la demande d’origine é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 d’accès relatif à un back-end de déconnexion dans le déploiement d’API actuel. Le chemin d’accès que vous spécifiez doit correspondre au chemin d’itinéraire défini pour le serveur principal de déconnexion. Par exemple,
    un client API peut appeler le backend de déconnexion pour révoquer des jetons. Un appel au back-end de déconnexion peut inclure une URL post-déconnexion en tant que paramètre de requête nommé . Reportez-vous à la section Ajout de la déconnexion en tant que serveur principal d’API Gateway.
  - Expiration de la réponse en heures : (facultatif) Durée de mise en cache du jeton JWT généré par le flux d’autorisation. La valeur par défaut est de 1 heure.
  - Utiliser les informations d’identification du client du point de terminaison d’introspection OAuth2 : spécifiez si vous souhaitez utiliser les mêmes détails du client que ceux que vous avez précédemment spécifiés pour le point de terminaison d’introspection OAuth 2.0 afin d’obtenir un nouveau jeton d’accès JWT (ce qui est généralement le cas). Si vous ne souhaitez pas utiliser les détails que vous avez spécifiés précédemment, entrez différents détails du client à utiliser pour obtenir un nouveau jeton d’accès JWT à partir du serveur d’autorisation, comme suit :
    - ID client : ID client à envoyer au point de terminaison d’introspection. Par exemple,
    - Vault dans <nom-du-compartiment> : nom d’un coffre-fort dans le service Vault qui contient la clé secrète client à envoyer au point de terminaison d’introspection.
    - Secret de coffre-fort dans <nom du compartiment > : nom du secret de coffre-fort Contient la clé secrète client à envoyer au point de terminaison Introspection.
    - Numéro de version de la clé secrète du coffre-fort : version de la clé secrète du coffre-fort qui contient la clé secrète du client à envoyer au point de terminaison d’introspection.
  Afficher les options avancées et sélectionner :
  - (facultatif) Spécifiez comment stocker les jetons JWT nouvellement générés sous forme de chaînes non lisibles par l’homme à la fin d’un flux d’autorisation OpenID Connect :
    - Au lieu de cela, la passerelle API renvoie un jeton non lisible par l’homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes ultérieures adressées à 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 CSRF (Cross-Site Request Forgery)
  - (facultatif) Spécifier comment stocker Valeurs d’étape intermédiaire du flux d’autorisation (par exemple, paramètres de demande). Désélectionnez cette option pour stocker les valeurs avec la passerelle API.
  - Utiliser PKCE : (facultatif) Spécifiez si vous souhaitez utiliser PKCE (Proof Key for Code Exchange) pour plus de sécurité. PKCE est une extension de sécurité OAuth 2.0 permettant d’empêcher les attaques par injection de code d’autorisation CSRF (Cross-Site Request Forgery) et d’autorisation. 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 OAuth 2.0.
3. Si vous souhaitez personnaliser la réponse à une tentative infructueuse de validation d’un jeton manquant ou non valide, sélectionnez Réponse personnalisée et spécifiez un code d’état (et un corps de message facultatif) à renvoyer au client API :
  - Code d’état HTTP : Entrez un autre code HTTP code d’état. Par exemple.
  - Corps du message : Entrez un corps de message. Par exemple, le corps du message peut inclure n’importe quelle variable de contexte (à l’exception de ).
  - Si vous le souhaitez, modifiez les en-têtes de la réponse que la passerelle d’API renvoie au client d’API en spécifiant une stratégie de réponse de transformation d’en-tête. Pour plus d’informations sur les stratégies de transformation d’en-tête, consultez Ajout de stratégies de réponse de transformation d’en-tête.
Cliquez sur Suivant pour entrer les détails des itinéraires individuels dans le déploiement de l’API sur la page Itinéraires.
Dans la section Route 1, spécifiez la première route du déploiement d’API qui mappe un chemin d’accès et une ou plusieurs méthodes à un service principal :
- Chemin d’accès pour les appels d’API à l’aide de l’attribut au service principal. Notez que le chemin d’accès à l’itinéraire 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 barre oblique unique
  - 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 majuscules et 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 d’itinéraire)
- Méthodes : Une ou plusieurs méthodes acceptées par le service principal, séparées par des virgules. Par exemple.
- Ajouter un seul backend ou Ajouter plusieurs backends : Indique s’il faut acheminer toutes les requêtes vers le même backend, ou pour Acheminez les demandes vers différents back-ends en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous souhaitez utiliser un seul back-end, alors sélectionnez Ajouter un seul back-end . Sinon, si vous souhaitez utiliser différents back-ends, sélectionnez Ajouter plusieurs backends et suivez les instructions de la section Utilisation de la console pour ajouter une sélection de back-end dynamique à une spécification de déploiement d’API.
- Type de backend : type du service back-end, tel que :
  - HTTP : pour un back-end HTTP, vous devez également spécifier une URL, les détails du délai d’expiration et l’option de désactivation de la vérification SSL (voir Ajout d’une URL HTTP ou HTTPS en tant que back-end API Gateway).
  - Oracle Functions : pour un back-end OCI Functions, vous devez également spécifier l’application et la fonction (voir Ajout d’une fonction dans OCI fonctionne comme un back-end d’API Gateway.
  - Réponse Stock : pour un back-end de réponse standard, vous devez également spécifier le code d’état HTTP, le contenu dans le corps de la réponse et un ou plusieurs champs d’en-tête HTTP (voir Ajout de réponses Stock en tant que back-end API Gateway).
  - Déconnexion : pour un back-end 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 les jetons, et éventuellement les données à transmettre à l’URL de déconnexion (consultez Ajout de la déconnexion en tant que back-end API Gateway).
Pour spécifier une politique d’autorisation qui s’applique à un itinéraire individuel, cliquez sur Afficher les stratégies de demande d’itinéraire , cliquez sur le bouton Ajouter en regard d’Autorisation et spécifiez :
- Type d’autorisation : Comment accorder l’accès à l’itinéraire. Spécifiez :
  - N’importe lequel : n’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès, à condition que le JWT dispose d’une revendication qui inclut au moins l’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 stratégie d’authentification n’a aucun effet.
  - Anonyme : accordez l’accès à tous les utilisateurs finaux, même s’ils n’ont pas été authentifiés avec succès à l’aide du JWT. Dans ce cas, vous devez avoir sélectionné l’option Activer l’accès anonyme de la stratégie d’authentification.
  - Authentification uniquement : n’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès à l’aide du JWT. Dans ce cas, la commande Activer l’accès anonyme de la stratégie d’authentification n’a aucun effet.
- Étendue autorisée : si vous avez sélectionné N’importe lequel comme type d’autorisation , entrez une liste délimitée par des virgules d’une ou plusieurs chaînes correspondant aux étendues d’accès dans le JWT. L’accès n’est accordé aux utilisateurs finaux qui ont été authentifiés avec succès que si le JWT dispose d’une revendication qui inclut l’une des étendues d’accès que vous spécifiez. Par exemple,
Remarque

Si vous n’incluez pas de stratégie d’autorisation pour un itinéraire particulier, l’accès est accordé comme si une telle stratégie existait et le type d’autorisation est défini sur Authentification uniquement . En d’autres termes, quel que soit le paramètre de l’option Activer l’accès anonyme de la politique d’authentification :
- uniquement authentifié Les utilisateurs finaux peuvent accéder à l’itinéraire
- Tous les utilisateurs finaux authentifiés peuvent accéder à l’itinéraire indépendamment des étendues d’accès dans la revendication du JWT
- utilisateurs finaux anonymes ne peuvent pas accéder à l’itinéraire
Cliquez sur Appliquer les modifications , puis sur Suivant pour vérifier les détails que vous avez entrés pour le déploiement de l’API.
Cliquez sur Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement de l’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 stratégies d’authentification par jeton et de demande d’autorisation

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

À l’aide de votre éditeur JSON préféré, modifiez la spécification de déploiement d’API existante à laquelle vous souhaitez ajouter des fonctionnalités d’authentification et d’autorisation, ou créez une nouvelle 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 de l’API comprendra une section contenant :
- Un chemin d’accès. Par exemple,
- une ou plusieurs méthodes. Par exemple,
- une définition d’un back-end. Par exemple, une URL ou l’OCID d’une fonction dans OCI Functions.
Par exemple, la spécification de déploiement d’API de base suivante définit une fonction serverless Hello World simple dans OCI Functions en tant que back-end unique :
Insérez une section avant la section (si elle n’existe pas déjà) pour créer une stratégie de demande qui s’applique à tous les itinéraires dans la spécification de déploiement d’API. Par exemple:
Ajoutez la stratégie de demande comme suit

où :
- spécifie que vous souhaitez utiliser des jetons pour l’authentification.
- Indique s’il s’agit d’un en-tête de requête qui contient le jeton (et le cas échéant, le nom de l’en-tête) ou d’un paramètre de requête qui contient le jeton (et si c’est le cas, le nom du paramètre de requête). Notez que vous pouvez spécifier l’un ou l’autre ou , mais pas les deux. Par exemple,
- il s’agit du nom du schéma d’authentification à utiliser si le jeton est contenu dans un en-tête de demande. Par exemple.
- indique éventuellement si les utilisateurs finaux non authentifiés (c’est-à-dire anonymes) peuvent accéder aux routes dans la spécification de déploiement de l’API. Si vous ne souhaitez jamais que les utilisateurs finaux anonymes puissent accéder aux routes, attribuez la valeur à . Si vous n’incluez pas cette propriété dans la stratégie, la valeur par défaut est utilisée. Notez que si vous incluez cette propriété et que vous la définissez sur , vous devez également Spécifiez explicitement chaque itinéraire auquel l’accès anonyme est autorisé en définissant la propriété sur dans la stratégie de chaque itinéraire.
- spécifie éventuellement la différence de temps maximale entre les horloges système du fournisseur d’identité qui a émis un JWT et la passerelle 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, à l’aide de la revendication pas avant () (le cas échéant) et de la revendication d’expiration () dans le JWT. Le minimum (et par défaut) est , le maximum est .
- Spécifie une stratégie de validation pour valider les jetons, comme décrit dans les étapes suivantes.
Si vous souhaitez que la passerelle d’API valide à la fois les jetons JWT et les jetons non-JWT avec le point de terminaison d’introspection d’un serveur d’autorisation OAuth 2.0 à l’aide des informations d’identification du client (y compris une clé secrète client récupérée d’un coffre-fort dans le service Vault), ajoutez la stratégie de validation suivante à la liste section vide :
où :
- spécifie que vous souhaitez valider les jetons avec le point de terminaison d’introspection d’un serveur d’autorisation OAuth 2.0 à l’aide des informations d’identification du client (y compris une clé secrète client récupérée à partir d’un coffre dans le service Vault).
- spécifie les détails de la clé secrète client à récupérer à partir d’un coffre-fort dans le service Vault :
  - spécifie l’ID client à envoyer au point de terminaison d’introspection. Vous obtenez un ID client en créant et en inscrivant une application cliente auprès du serveur d’autorisation. Par exemple. Reportez-vous à la section Conditions préalables à l’authentification par jeton.
  - spécifie l’OCID de la clé secrète du coffre qui contient la clé secrète client à envoyer au point de terminaison Introspection. Par exemple,
  - spécifie la version de la clé secrète du coffre qui contient la clé secrète du client à envoyer au point de terminaison d’introspection. Par exemple,
- spécifie l’URL connue d’un serveur d’autorisation à partir duquel la passerelle d’API doit obtenir les points de terminaison des métadonnées d’autorisation. Par exemple. 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.
- indique s’il faut désactiver la vérification SSL lors de la communication avec le serveur d’autorisation. Oracle recommande de ne pas définir cette option sur car elle peut compromettre la validation JWT. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- spécifie le nombre d’heures (entre 1 et 24) pendant lesquelles la passerelle d’API doit mettre en cache la réponse à partir du point de terminaison d’introspection.
- spécifie des détails supplémentaires pour la validation du jeton :
  - est l’URL (ou une chaîne de texte) d’un serveur d’autorisation autorisé dans la revendication de l’émetteur () d’un JWT à utiliser pour accéder au déploiement de l’API. Par exemple, pour permettre l’utilisation d’un JWT émis par OCI IAM avec des domaines d’identité pour accéder au déploiement de l’API, spécifiez . Vous pouvez spécifier un ou plusieurs serveurs d’autorisation (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - est une valeur autorisée dans la revendication audience () d’un JWT pour identifier le destinataire prévu du jeton. Par exemple, l’audience peut être, mais pas nécessairement être, le nom d’hôte de la passerelle API. Vous pouvez spécifier une ou plusieurs audiences (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - 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) :
    - est le nom d’une revendication qui peut ou doit être incluse dans un JWT. Le nom de revendication que vous spécifiez peut être un nom de revendication réservé, tel que la revendication objet () ou un nom de revendication personnalisé émis par un serveur d’autorisation particulier.
    - (facultatif) indique une ou plusieurs valeurs acceptables pour l’allégation.
    - indique si la créance doit être incluse dans le JWT.
    Notez que tous les noms de clés et valeurs que vous entrez sont simplement traités comme des chaînes de caractères et doivent correspondre exactement aux noms et aux valeurs du JWT. La correspondance de modèle et d’autres types de données ne sont pas pris en charge
Par exemple, la stratégie suivante configure la passerelle d’API pour valider un jeton dans l’en-tête de demande d’autorisation à l’aide des informations d’identification du client (y compris une clé secrète client récupérée à partir d’un coffre-fort dans le service Vault) transmise à un point de terminaison d’introspection OAuth 2.0) :
Si vous souhaitez que la passerelle d’API valide les JWT en récupérant les clés de vérification publiques du fournisseur d’identité au moment de l’exécution, ajoutez l’attribut stratégie de validation suivante à la section vide :

où :
- spécifie que vous souhaitez configurer la passerelle d’API pour récupérer jusqu’à dix clés de vérification publiques du fournisseur d’identité au moment de l’exécution.
- spécifie l’URI à partir duquel récupérer le jeu de clés Web JSON (JWKS) à utiliser pour vérifier la signature sur les JWT. Pour plus d’informations sur l’URI à spécifier, consultez Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI 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 à récupérer les JWK, toutes les requêtes adressées au déploiement d’API renvoient un code de réponse HTTP 500. Pour plus d’informations sur l’erreur, reportez-vous au journal d’exécution de la passerelle d’API (voir Ajout de la journalisation aux déploiements d’API).
  - Certains paramètres clés doivent être présents dans le JWKS pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT).
  - Le JWKS peut contenir jusqu’à dix clés.
- indique s’il faut désactiver la vérification SSL lors de la communication avec le fournisseur d’identité. Oracle recommande de ne pas définir cette option sur car elle peut compromettre la validation JWT. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- spécifie le nombre d’heures (entre 1 et 24) pendant lesquelles la passerelle d’API doit mettre en cache le JWKS après l’avoir récupéré.
- spécifie des détails supplémentaires pour la validation du jeton :
  - est l’URL (ou une chaîne de texte) d’un fournisseur d’identité qui est autorisé dans la revendication d’émetteur () d’un JWT à utiliser pour accéder au déploiement de l’API. Par exemple, pour activer l’utilisation d’un JWT émis par OCI IAM avec des domaines d’identité pour accéder au déploiement de l’API, entrez . Vous pouvez spécifier un ou plusieurs fournisseurs d’identité (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - est une valeur autorisée dans la revendication audience () d’un JWT pour identifier le destinataire prévu du jeton. Par exemple, l’audience peut être, mais pas nécessairement être, le nom d’hôte de la passerelle API. Vous pouvez spécifier une ou plusieurs audiences (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - 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).
    - est le nom d’une créance qui peut ou doit être incluse dans un JWT. Le nom de revendication que vous spécifiez peut être un nom de revendication réservé, tel que la revendication objet (), ou un nom de revendication personnalisé émis par une identité particulière fournisseur.
    - (facultatif) indique une ou plusieurs valeurs acceptables pour l’allégation.
    - indique si la créance doit être incluse dans le JWT.
    Notez que tous les noms de clés et valeurs que vous entrez sont simplement traités comme des chaînes de caractères et doivent correspondre exactement aux noms et aux valeurs du JWT. La correspondance de modèle et d’autres types de données ne sont pas pris en charge
Par exemple, la stratégie suivante configure la passerelle d’API pour valider le JWT dans l’en-tête de demande d’autorisation en récupérant les clés de vérification publiques du fournisseur d’identité au moment de l’exécution :
Si vous souhaitez que la passerelle d’API valide les JWT avec des clés de vérification publiques déjà émises par un fournisseur d’identité (ce qui permet à la passerelle d’API de vérifier les JWT localement sans avoir à contacter le fournisseur d’identité), ajoutez la politique de validation suivante à la section vide :

where :
- spécifie que vous souhaitez configurer la passerelle d’API avec jusqu’à dix clés de vérification publiques déjà émises par un fournisseur d’identité (ce qui permet à la passerelle d’API de vérifier les JWT localement sans avoir à contacter le fournisseur d’identité).
- spécifiez 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é (quel que soit le format, vous pouvez spécifier jusqu’à dix clés) :
  - Si la clé statique est une clé Web JSON, spécifiez , spécifiez l’identificateur de la clé statique utilisée pour signer le JWT en tant que valeur du paramètre, et fournissez des valeurs pour les autres paramètres afin de vérifier la signature du JWT.
    
    Par exemple :
    
    Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT). Notez également qu’il s’agit actuellement de la Seul le type de clé pris en charge ().
  - Si la clé statique est une clé publique codée PEM, spécifiez , spécifiez l’identificateur de la clé statique utilisée pour signer le JWT en tant que valeur de , et indiquez la clé en tant que valeur de .
    
    Par exemple :
    
    Notez que les marqueurs et sont obligatoires.
- indique s’il faut désactiver la vérification SSL lors de la communication avec le fournisseur d’identité. Oracle recommande de ne pas définir cette option sur car elle peut compromettre la validation JWT. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
- spécifie le nombre d’heures (entre 1 et 24) pendant lesquelles la passerelle d’API doit mettre en cache le JWKS après l’avoir récupéré.
- spécifie des détails supplémentaires pour la validation du jeton :
  - est l’URL (ou une chaîne de texte) un fournisseur d’identité qui est autorisé dans la revendication d’émetteur () d’un JWT à utiliser pour accéder au déploiement de l’API. Par exemple, pour activer l’utilisation d’un JWT émis par OCI IAM avec des domaines d’identité pour accéder au déploiement de l’API, entrez . Vous pouvez spécifier un ou plusieurs fournisseurs d’identité (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - est une valeur autorisée dans la revendication audience () d’un JWT pour identifier le destinataire prévu du jeton. Par exemple, l’audience peut être, mais pas nécessairement être, le nom d’hôte de la passerelle API. Vous pouvez spécifier une ou plusieurs audiences (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - 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).
    - est le nom d’une créance qui peuvent ou doivent être inclus dans un JWT. Le nom de revendication que vous spécifiez peut être un nom de revendication réservé, tel que la revendication objet (), ou un nom de revendication personnalisé émis par un fournisseur d’identité particulier.
    - (facultatif) indique une ou plusieurs valeurs acceptables pour l’allégation.
    - indique si la créance doit être incluse dans le JWT.
    Notez que tous les noms de clés et valeurs que vous entrez sont simplement traités comme des chaînes de caractères et doivent correspondre exactement aux noms et aux valeurs du JWT. La correspondance de modèle et d’autres types de données ne sont pas pris en charge
Par exemple, la stratégie suivante configure la passerelle d’API avec une clé de vérification publique déjà émise par un fournisseur d’identité pour valider le JWT dans l’en-tête de demande d’autorisation :
(Facultatif) Vous pouvez spécifier la façon dont vous souhaitez que la passerelle d’API gère une réponse d’authentification ayant échoué (renvoyée après une tentative infructueuse de validation d’un jeton manquant ou non valide) en configurant une stratégie d’échec de validation :
1. si vous souhaitez que la passerelle API envoie un code d’état HTTP 401 et l’en-tête de la réponse (la réponse par défaut à un jeton manquant ou non valide), ne définissez pas de stratégie d’échec de validation.
2. Si vous souhaitez que la passerelle API utilise un flux d’autorisation OpenID Connect pour obtenir un nouveau jeton d’accès JWT, définissez une stratégie d’échec de validation de type . Notez que cette option n’est disponible que si vous avez spécifié a de type plus tôt. Spécifiez :
  
  où :
  - spécifie une ou plusieurs étendues d’accès à inclure dans une revendication envoyée au serveur d’autorisation. Pour utiliser le flux d’autorisation OpenID Connect, vous devez l’inclure dans l’une des étendues. Par exemple,
  - spécifie les détails du client à utiliser pour obtenir un nouveau jeton d’accès JWT à partir du serveur d’autorisation, comme suit :
    - Spécifie s’il faut utiliser les mêmes détails client ou des détails différents de ceux spécifiés dans le précédent . Si vous souhaitez utiliser les mêmes informations client qu’auparavant (ce qui est généralement le cas), spécifiez et ne fournissez pas de détails supplémentaires. Si vous souhaitez utiliser des détails de client différents, spécifiez et définissez les valeurs de , , et .
    - spécifie l’ID client à envoyer au point de terminaison d’introspection. Utilisé uniquement si . Par exemple,
    - spécifie l’OCID de la clé secrète de coffre qui contient la clé secrète client à envoyer au point de terminaison d’introspection. Utilisé uniquement si . Par exemple,
    - spécifie la version de la clé secrète du coffre qui contient la clé secrète du client à envoyer au point de terminaison d’introspection. Utilisé uniquement si . Par exemple,
  - spécifie que vous souhaitez utiliser la même URL que celle spécifiée précédemment comme URL connue d’un serveur d’autorisation à partir duquel la passerelle d’API doit obtenir l’autorisation points de terminaison de métadonnées.
  - spécifie la durée de mise en cache du jeton JWT généré par le flux d’autorisation. La valeur par défaut est 1.
  - spécifie comment stocker les jetons JWT nouvellement générés sous forme de chaînes non lisibles par l’homme à la fin d’un flux d’autorisation OpenID Connect :
    - Définissez cette option sur
    - Définir cette option sur Au lieu de cela, la passerelle d’API renvoie un jeton non lisible par l’homme dans un en-tête de réponse X-APIGW-TOKEN. Les demandes ultérieures adressées à 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 CSRF (Cross-Site Request Forgery)
  - spécifie comment stocker les valeurs d’étape intermédiaire du flux d’autorisation (par exemple, les paramètres de demande). Définissez cette option sur Définir cette option pour stocker les valeurs avec la passerelle d’API.
  - spécifie s’il faut utiliser PKCE (Proof Key for Code Exchange) pour des sécurité. PKCE est une extension de sécurité OAuth 2.0 permettant d’empêcher les attaques par injection de code d’autorisation CSRF (Cross-Site Request Forgery) et d’autorisation. 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 OAuth 2.0.
  - Spécifie le type de réponse requise à partir du flux d’autorisation. Spécifiez comme type de réponse.
  - spécifie éventuellement un chemin d’accès relatif dans le déploiement d’API actuel vers lequel rediriger les clients d’API si la demande d’origine était une demande PUT ou une demande POST. Par exemple.
    Si la demande d’origine é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é.
  - spécifie éventuellement un chemin d’accès relatif à un back-end de déconnexion dans le déploiement actuel de l’API. Le chemin d’accès que vous spécifiez doit correspondre au chemin d’itinéraire défini pour le serveur principal de déconnexion. Pour exemple.
    Un client API peut appeler le back-end de déconnexion pour révoquer les jetons. Un appel au back-end de déconnexion peut inclure une URL post-déconnexion en tant que paramètre de requête nommé . Reportez-vous à la section Ajout de la déconnexion en tant que serveur principal d’API Gateway.
  Par exemple :
3. Si vous souhaitez personnaliser la réponse à une tentative infructueuse de validation d’un jeton manquant ou non valide, définissez une stratégie d’échec de validation de type , puis spécifiez un code d’état (et un corps de message facultatif) à renvoyer au client API, comme suit :
  où :
  - spécifie un autre code d’état HTTP. Par exemple.
  - : (facultatif) spécifie un corps de message. Par exemple, le corps du message peut inclure n’importe quelle variable de contexte (à l’exception de ).
  - : (facultatif) modifie les en-têtes de la réponse que la passerelle d’API renvoie au client d’API en spécifiant une stratégie de réponse de transformation d’en-tête. Pour en savoir plus pour plus d’informations sur les stratégies de transformation d’en-tête, consultez Ajout de stratégies de réponse de transformation d’en-tête.
  Par exemple :
Ajoutez une stratégie de demande pour chaque itinéraire dans la spécification de déploiement de
1. l’API : Insérez une section après la section de la première route, si elle n’existe pas déjà. Par exemple :
2. Ajoutez la stratégie suivante à la nouvelle section :
  
  où :
  - indique comment accorder l’accès à l’itinéraire :
    - : N’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès. Dans ce cas, la propriété de la stratégie de la spécification de déploiement de l’API n’a aucun effet.
    - : n’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès, à condition que la revendication du JWT inclue l’une des étendues d’accès que vous spécifiez dans la propriété. Dans ce cas, le dans la politique de la spécification de déploiement de l’API n’a aucun effet.
    - : Accordez l’accès à tous les utilisateurs finaux, même s’ils n’ont pas été authentifiés avec succès. Dans ce cas, vous devez définir explicitement la propriété sur dans la stratégie de la spécification de déploiement de l’API.
  - est une liste délimitée par des virgules d’une ou plusieurs chaînes qui correspondent à des étendues d’accès incluses dans la revendication du JWT. Dans ce cas, vous devez définir la propriété sur (la propriété est ignorée si la propriété est définie sur ou ). Notez également que si vous spécifiez plus d’une étendue, l’accès à l’itinéraire est accordé si l’une des étendues que vous spécifiez est incluse dans la revendication du JWT.
  Par exemple, la stratégie de demande suivante définit un itinéraire qui autorise uniquement les utilisateurs finaux authentifiés disposant de l’étendue à y accéder :
3. Ajoutez une stratégie de demande pour tous les itinéraires restants dans la spécification de déploiement de l’API.
Remarque

Si vous n’incluez pas de stratégie pour un itinéraire particulier, l’accès est accordé comme si une telle stratégie existait et la propriété est définie sur . En d’autres termes, quel que soit le paramètre de la propriété dans la stratégie de la spécification de déploiement d’API :
- seuls les utilisateurs finaux authentifiés peuvent accéder à l’itinéraire
- tous les utilisateurs finaux authentifiés peuvent accéder à l’itinéraire indépendamment des étendues d’accès dans la revendication JWT
- utilisateurs finaux anonymes ne peuvent pas accéder à l’itinéraire
Enregistrez le fichier JSON contenant la spécification de déploiement d’API.
Utilisez la spécification de déploiement d’API lorsque vous créez ou mettez à jour un déploiement d’API de la manière suivante :
- en spécifiant le fichier JSON dans la console lorsque vous sélectionnez l’option Charger une API existante
- en spécification du fichier JSON dans une requête adressée à l’API REST d’API Gateway
Pour plus d’informations, consultez Déploiement d’une API sur une passerelle d’API en créant un déploiement d’API et en mettant à jour une passerelle d’API ou un 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).

Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS

Le fournisseur d’identité qui a émis le JWT détermine les valeurs autorisées que vous devez spécifier pour les revendications de l’émetteur () et de l’audience () dans le JWT. Le fournisseur d’identité qui a émis le JWT détermine également l’URI à partir duquel récupérer le jeu de clés Web JSON (JWKS) pour vérifier la signature sur le JWT.

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

Utilisez le pour savoir ce qu’il faut spécifier pour les JWT émis par l’IAM OCI avec les fournisseurs d’identité Identity Domains, Oracle Identity Cloud Service (IDCS), Okta et Auth0.

Paramètres clés requis pour vérifier les signatures JWT

Pour vérifier la signature sur un JWT, les passerelles API nécessitent que les paramètres clés suivants soient présents dans le JWKS renvoyé à partir d’une URI ou dans la clé Web JSON statique que vous spécifiez.

les

Notes sur	paramètres de
clé L’identifiant de la clé utilisée pour signer le JWT. La valeur doit correspondre à la revendication dans l’en-tête JWT. Par exemple.
Type de clé utilisé pour signer le JWT. Notez que RSA est actuellement le seul type de clé pris en charge.
ou	Si le paramètre est présent, alors il doit être défini sur . Si le paramètre est présent, il doit s’agir de l’une des valeurs valides.
Module de clé publique.
L’exposant de clé publique.
L’algorithme de signature (le cas échéant) doit être défini sur RS256, RS384 ou RS512.

Utilisation d’une stratégie de demande d’authentification JWT_AUTHENTICATION (n’est plus recommandée)

Remarque

Dans les versions antérieures, vous avez peut-être créé des stratégies de demande d’authentification de type JWT_AUTHENTICATION pour utiliser les JWT pour l’authentification.

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

Notez que les stratégies de demande de JWT_AUTHENTICATION existantes sont toujours prises en charge. Notez également que, bien que vous puissiez créer de nouvelles stratégies de demande de JWT_AUTHENTICATION en définissant la spécification de déploiement d’API dans un fichier JSON (comme décrit dans les instructions d’origine de cette section), nous vous recommandons de créer des stratégies de demande d’authentification de type TOKEN_AUTHENTICATION à la place.

Lors de l’utilisation d’une stratégie 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é.

Lors de l’appel d’une API déployée sur une passerelle d’API, le client API fournit le JWT en tant que paramètre de requête ou dans l’en-tête de la demande. La passerelle API valide le JWT à l’aide d’une clé de vérification publique correspondante fournie par le fournisseur d’identité émetteur. À l’aide de la stratégie 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 récupérer les clés de vérification publiques du fournisseur d’identité au moment de l’exécution. Dans ce cas, le fournisseur d’identité agit en tant que serveur d’autorisation.
Vous pouvez configurer la passerelle API à l’avance avec des clés de vérification publiques déjà émises par un fournisseur d’identité (appelées « clés statiques »), ce qui permet à la passerelle API de vérifier les JWT localement au moment de l’exécution sans avoir à contacter le fournisseur d’identité. Le résultat est une validation plus rapide des jetons.

Pour ajouter une nouvelle stratégie de demande d’authentification et d’autorisation JWT_AUTHENTICATION à un Spécification de déploiement d’API dans un fichier JSON :

ajoutez une stratégie de demande qui s’applique à toutes les routes dans la spécification de déploiement
1. d’API : insérez une section avant la section, si elle n’existe pas déjà. Par exemple :
2. Ajoutez la stratégie suivante à la nouvelle section.
  
  where :
  - indique éventuellement si les utilisateurs finaux non authentifiés (c’est-à-dire anonymes) peuvent accéder aux routes dans la spécification de déploiement de l’API. Si vous ne souhaitez jamais que les utilisateurs finaux anonymes puissent accéder aux routes, attribuez la valeur à . Si vous n’incluez pas cette propriété dans la stratégie, la valeur par défaut est utilisée. Notez que si vous incluez cette propriété et que vous lui attribuez la valeur , vous devez également spécifier explicitement chaque itinéraire auquel l’accès anonyme est autorisé en définissant la propriété sur dans la stratégie de chaque itinéraire.
  - est l’URL (ou une chaîne de texte) d’une identité provider qui est autorisé dans la revendication de l’émetteur () d’un JWT à utiliser pour accéder au déploiement de l’API. Par exemple, pour activer l’utilisation d’un JWT émis par OCI IAM avec des domaines d’identité pour accéder au déploiement de l’API, entrez . Vous pouvez spécifier un ou plusieurs fournisseurs d’identité (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - indique s’il s’agit d’un en-tête de requête qui contient le JWT (et le cas échéant, le nom de l’en-tête) ou d’un paramètre de requête qui contient le JWT (et le cas échéant, le nom du paramètre de requête). Notez que vous pouvez spécifier l’un ou l’autre ou , mais pas les deux.
  - est le nom du schéma d’authentification à utiliser si le JWT est contenu dans un en-tête de demande. Par exemple.
  - est une valeur autorisée dans la revendication audience () d’un JWT pour identifier le destinataire prévu du jeton. Par exemple, l’audience pourrait être, mais n’a pas besoin d’être, l’API nom d’hôte de la passerelle. Vous pouvez spécifier une ou plusieurs audiences (jusqu’à un maximum de cinq). Reportez-vous à la section Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI JWKS.
  - indique comment vous souhaitez que la passerelle d’API valide les JWT à l’aide de clés de vérification publiques. Spécifiez de configurer la passerelle d’API pour récupérer jusqu’à dix clés de vérification publiques à partir du fournisseur d’identité au moment de l’exécution. Spécifiez de configurer la passerelle API avec jusqu’à dix clés de vérification publiques déjà émises par un fournisseur d’identité (ce qui permet à la passerelle API de vérifier les JWT localement sans avoir à contacter le fournisseur d’identité).
  - fournit les détails de la validation JWT, selon que vous l’avez spécifié ou sous la forme de la valeur suivante :
    - Si vous avez spécifié de configurer la passerelle API pour valider les JWT en récupérant les clés de vérification publiques auprès du fournisseur d’identité au moment de l’exécution, fournissez les détails suivants :
      
      where :
      - spécifie l’URI à partir duquel récupérer le jeu de clés Web JSON (JWKS) à utiliser pour vérifier la signature sur les JWT. Pour plus d’informations sur l’URI à spécifier, consultez Détails du fournisseur d’identité à utiliser pour les revendications iss et aud, ainsi que pour l’URI 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 à récupérer les JWK, toutes les requêtes adressées au déploiement d’API renvoient un code de réponse HTTP 500. Pour plus d’informations sur l’erreur, reportez-vous au journal d’exécution de la passerelle d’API (voir Ajout de la journalisation aux déploiements d’API).
        
        Certains paramètres clés doivent être présents dans le JWKS pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT).
        
        Le JWKS peut contenir jusqu’à dix clés.
      - Spécifie le nombre d’heures (entre 1 et 24) la passerelle API doit mettre en cache le JWKS après l’avoir récupéré.
      - indique s’il faut désactiver la vérification SSL lors de la communication avec le fournisseur d’identité. Oracle recommande de ne pas définir cette option sur car elle peut compromettre la validation JWT. API Gateway approuve les certificats de plusieurs autorités de certification émises pour OCI IAM avec Identity Domains, Oracle Identity Cloud Service (IDCS), Auth0 et Okta.
      Par exemple :
    - Si vous avez spécifié , les détails à fournir dépendent du format de la clé déjà émise par le fournisseur d’identité (quel que soit le format, vous pouvez spécifier jusqu’à dix clés) :
      - Si la clé statique est une clé Web JSON, spécifiez , spécifiez l’identificateur de la clé statique utilisée pour signer le JWT en tant que valeur du paramètre, et fournir des valeurs pour d’autres paramètres afin de vérifier la signature du JWT.
        
        par exemple:
        
        Notez que certains paramètres doivent être présents dans la clé statique pour vérifier la signature du JWT (voir Paramètres clés requis pour vérifier les signatures JWT). Notez également que est actuellement le seul type de clé pris en charge ().
      - Si la clé statique est une clé publique codée PEM, spécifiez , spécifiez l’identificateur de la clé statique utilisée pour signer le JWT en tant que valeur de , et indiquez la clé en tant que valeur de .
        
        Par exemple :
        
        Notez que les marqueurs et sont obligatoires.
  - 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).
    - est le nom d’une créance qui peut ou doit être incluse dans un JWT. Le nom de revendication que vous spécifiez peut être un nom de revendication réservé, tel que la revendication objet (), ou un nom de revendication personnalisé émis par un fournisseur d’identité particulier.
    - (facultatif) indique une ou plusieurs valeurs acceptables pour l’allégation.
    - indique si la créance doit être incluse dans le JWT.
    Notez que tous les noms de clés et valeurs que vous entrez sont simplement traités comme des chaînes de caractères et doivent correspondre exactement aux noms et aux valeurs du JWT. La correspondance de modèles et d’autres types de données ne sont pas pris en charge
  - ; spécifie éventuellement la différence de temps maximale entre les horloges système du fournisseur d’identité qui a émis un 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, à l’aide de la revendication pas avant () (le cas échéant) et de la revendication d’expiration () dans le JWT. Le minimum (et par défaut) est , le maximum est .
  Par exemple, la stratégie suivante configure la passerelle d’API avec une clé de vérification publique déjà émise par un fournisseur d’identité pour valider le JWT dans l’en-tête de la demande d’autorisation :
Ajouter une stratégie de demande pour chaque itinéraire dans la spécification de déploiement de
1. l’API : Insérez une section après la section de la première route, si elle n’existe pas déjà. Par exemple :
2. Ajoutez la stratégie suivante à la section :
  
  où :
  - indique comment accorder l’accès à l’itinéraire :
    - : N’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès. Dans ce cas, la propriété de la stratégie de la spécification de déploiement de l’API n’a aucun effet.
    - : n’accordez l’accès qu’aux utilisateurs finaux qui ont été authentifiés avec succès, à condition que la revendication du JWT inclue l’une des étendues d’accès que vous spécifiez dans la propriété. Dans ce cas, la propriété de la stratégie de la spécification de déploiement de l’API n’a aucun effet.
    - :subvention l’accès à tous les utilisateurs finaux, même s’ils n’ont pas été authentifiés avec succès. Dans ce cas, vous devez définir explicitement la propriété sur dans la stratégie de la spécification de déploiement de l’API.
  - est une liste délimitée par des virgules d’une ou plusieurs chaînes qui correspondent à des étendues d’accès incluses dans la revendication du JWT. Dans ce cas, vous devez définir la propriété sur (la propriété est ignorée si la propriété est définie sur ou ). Notez également que si vous spécifiez plus d’une étendue, l’accès à l’itinéraire est accordé si l’une des étendues que vous spécifiez est incluse dans la revendication du JWT.
  Par exemple, la stratégie de demande suivante définit un itinéraire qui autorise uniquement les utilisateurs finaux authentifiés disposant de l’étendue à y accéder :
3. Ajoutez une stratégie de demande pour tous les itinéraires restants dans la spécification de déploiement de l’API.
Remarque

Si vous n’incluez pas de stratégie Pour un itinéraire particulier, l’accès est accordé comme si une telle stratégie existait et la propriété est définie sur . En d’autres termes, quel que soit le paramètre de la propriété dans la stratégie de la spécification de déploiement d’API :
- seuls les utilisateurs finaux authentifiés peuvent accéder à l’itinéraire
- tous les utilisateurs finaux authentifiés peuvent accéder à l’itinéraire indépendamment des étendues d’accès dans la revendication JWT
- utilisateurs finaux anonymes ne peuvent pas accéder à l’itinéraire
Enregistrez le fichier JSON contenant la spécification de déploiement d’API.
Utilisez la spécification de déploiement d’API lorsque vous créez ou mettez à jour un déploiement d’API de la manière suivante :
- 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 adressée à l’API REST d’API API Gateway
pour Pour plus d’informations, consultez Déploiement d’une API sur une passerelle d’API en créant un déploiement d’API et en mettant à jour une passerelle d’API ou un 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).

Exemple : Migration d’une stratégie de demande JWT_AUTHENTICATION vers une stratégie de demande TOKEN_AUTHENTICATION

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

Une façon d’aborder la migration consiste à créer une stratégie de demande de TOKEN_AUTHENTICATION vide, puis à la remplir avec les valeurs de la stratégie de demande de JWT_AUTHENTICATION

Avant la migration :

la stratégie de demande de JWT_AUTHENTICATION d’origine, avant la migration :

après

la migration :

la nouvelle demande de TOKEN_AUTHENTICATION Stratégie renseignée avec les valeurs de la stratégie de demande de JWT_AUTHENTICATION d’origine :