Ajout de la déconnexion en tant que back-end de passerelle d'API
Découvrez comment définir un back-end de déconnexion avec API Gateway.
Les API doivent généralement permettre aux clients d'API de se déconnecter correctement en révoquant les jetons d'accès et éventuellement d'appeler d'autres URL pour effectuer des tâches supplémentaires après la déconnexion. API Gateway vous permet de définir des back-ends de déconnexion afin de fournir cette fonctionnalité lors de l'utilisation d'une stratégie d'authentification par jeton OAuth 2.0 pour un déploiement d'API. Les demandes au back-end de déconnexion peuvent éventuellement inclure une URL de post-déconnexion en tant que valeur d'un paramètre de requête nommé postLogoutUrl
.
Lors de la définition d'une stratégie d'authentification par jeton OAuth 2.0, vous pouvez éventuellement indiquer un chemin vers le back-end de déconnexion (chemin de déconnexion) pour révoquer les jetons d'accès en cas d'échec de l'authentification. Reportez-vous à Validation de jetons pour ajouter l'authentification et l'autorisation aux déploiements d'API.
La définition du back-end de déconnexion inclut éventuellement les éléments suivants :
- Liste des URL de post-déconnexion autorisées vers lesquelles une demande peut être redirigée pour révoquer des jetons d'accès. Si le paramètre de requête
postLogoutUrl
est inclus dans la demande, sa valeur doit être l'une de ces URL. Les URL de la liste peuvent être des chemins absolus ou relatifs, et les URL peuvent inclure des variables de contexte. Si vous indiquez un chemin relatif (c'est-à-dire vers un autre routage dans le déploiement d'API), le déploiement d'API et le routage doivent autoriser l'accès anonyme. Notez également que si vous n'incluez pas explicitement une ou plusieurs URL dans la liste, toute URL post-déconnexion est autorisée. - Données à transmettre aux URL de déconnexion lorsque la demande est redirigée, en tant que valeur du paramètre de requête
state
. Les données peuvent uniquement inclure des variables de contexte (et non des valeurs statiques).
Lors de la réception d'une demande au chemin de déconnexion d'un client API, la passerelle API vérifie que le client API est authentifié pour appeler le back-end de déconnexion, vérifie que toute URL de déconnexion incluse dans la demande est autorisée et supprime toutes les informations stockées sur la session du client API (par exemple, dans les cookies). En supposant que l'URL de post-déconnexion est autorisée, ce qui se passe ensuite dépend de l'authentification du client d'API et de la réponse précédemment mise en cache à partir de l'URL de repérage indiquée dans la stratégie d'authentification de jeton OAuth 2.0 fournie ou non une adresse de fin de session :
- Si le client d'API n'est pas authentifié, la passerelle d'API redirige la demande de déconnexion vers l'URL de post-déconnexion.
- Si le client d'API est authentifié, mais que la stratégie d'authentification par jeton OAuth 2.0 n'a pas fourni d'adresse de fin de session, la passerelle d'API redirige la demande de déconnexion vers l'URL de post-déconnexion et transmet toutes les informations d'état indiquées dans la définition de back-end de déconnexion.
- Si le client d'API est authentifié et que la stratégie d'authentification par jeton OAuth 2.0 a fourni une adresse de fin de session, la passerelle d'API redirige la demande de déconnexion vers cette adresse de fin de session et transmet l'URL de post-déconnexion, ainsi que toutes les informations d'état indiquées dans la définition de back-end de déconnexion. Dans ce cas, il incombe au fournisseur d'identités de rediriger la demande vers l'URL après déconnexion.
Vous pouvez ajouter un back-end de déconnexion à une spécification de déploiement d'API en :
- utilisant la console,
- modifiant un fichier JSON.
Utilisation de la console pour ajouter des back-ends de déconnexion à une spécification de déploiement d'API
Pour ajouter des back-ends de déconnexion à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :
-
Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.
Pour plus d'informations, reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et à Mise à jour d'une passerelle d'API.
-
Sur la page Authentification, indiquez les options d'authentification.
Pour plus d'informations sur les options d'authentification, reportez-vous à Ajout de l'authentification et de l'autorisation aux déploiements d'API.
-
Sur la page Routages, créez un routage et spécifiez les éléments suivants :
-
Chemin : chemin pour les appels d'API utilisant les méthodes répertoriées vers le service back-end. Le chemin d'accès que vous spécifiez doit remplir les conditions suivantes :
- Il doit être relatif au préfixe de chemin de déploiement (reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API).
- Il doit être précédé d'une barre oblique (/). Il peut également consister en une unique barre oblique.
- Il peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes), ainsi que se terminer par une barre oblique.
- Il peut inclure des caractères alphanumériques en majuscules et minuscules.
- Il peut inclure les caractères spéciaux
$ - _ . + ! * ' ( ) , % ; : @ & =
. - Il peut inclure des paramètres et des caractères génériques (reportez-vous à Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : méthodes acceptées par le service back-end. Dans le cas des back-ends de déconnexion, seul
GET
est accepté. - Type de back-end : type du service back-end (
Logout
). - URI après déconnexion autorisés : (facultatif) liste des URL autorisées vers lesquelles une demande de déconnexion peut être redirigée pour révoquer des jetons. Les URL de la liste peuvent être des chemins absolus ou relatifs, et les URL peuvent inclure des variables de contexte. Par exemple,
["https://${request.header[tenant-id].page.html}", "https://fixed-path.page.html",
."/logout_html"
]Tenez compte des points suivants :
- Une URL post-déconnexion peut être incluse dans une demande au back-end de déconnexion en tant que valeur d'un paramètre de requête nommé
postLogoutUrl
. - Si vous indiquez un chemin relatif (c'est-à-dire vers un autre routage dans le déploiement d'API), le déploiement d'API et le routage doivent autoriser l'accès anonyme.
- Si vous n'incluez pas explicitement une ou plusieurs URL dans la liste, toute URL post-déconnexion est autorisée.
- Une URL post-déconnexion peut être incluse dans une demande au back-end de déconnexion en tant que valeur d'un paramètre de requête nommé
- Etat de post-déconnexion : (facultatif) données à transmettre lorsqu'une demande de déconnexion est redirigée vers une adresse de session de fin et/ou une URL de post-déconnexion. Les données peuvent uniquement inclure des variables de contexte (et non des valeurs statiques). Par exemple,
request.query[region]
Les données sont transmises en tant que valeur du paramètre de requête
state
.
-
- (Facultatif) Sélectionnez Autre routage pour saisir les détails d'autres routages.
- Sélectionnez Suivant afin de vérifier les détails saisis pour le déploiement d'API.
- Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
- (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).
Modification d'un fichier JSON pour ajouter des back-ends de déconnexion à une spécification de déploiement d'API
Pour ajouter des back-ends de déconnexion à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :
-
A l'aide de l'éditeur JSON de votre choix, modifiez la spécification de déploiement d'API existante à laquelle ajouter un back-end de déconnexion ou créez une spécification de déploiement d'API (reportez-vous à Création d'une spécification de déploiement d'API).
Par exemple, la spécification de déploiement d'API de base suivante définit une fonction simple sans serveur Hello World dans Oracle Functions en tant que back-end unique :
{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
Dans la section
routes
, incluez une nouvelle section pour un back-end de déconnexion :{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } }, { "path": "<logout-route-path>", "methods": ["<method-list>"], "backend": { "type": "OAUTH2_LOGOUT", "allowedPostLogoutUris": ["<url>", "<url"], "postLogoutState": "<logout-data>" } } ] }
où :
-
<logout-route-path>
indique un chemin pour les appels utilisant les méthodes répertoriées vers le back-end de déconnexion. Le chemin d'accès que vous spécifiez doit remplir les conditions suivantes :- Il doit être relatif au préfixe de chemin de déploiement (reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API).
- Il doit être précédé d'une barre oblique (/). Il peut également consister en une unique barre oblique.
- Il peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes), ainsi que se terminer par une barre oblique.
- Il peut inclure des caractères alphanumériques en majuscules et minuscules.
- Il peut inclure les caractères spéciaux
$ - _ . + ! * ' ( ) , % ; : @ & =
. -
Il peut inclure des paramètres et des caractères génériques (reportez-vous à Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
<method-list>
indique les méthodes acceptées par le back-end de déconnexion, séparées par des virgules. Dans le cas des back-ends de déconnexion, seulGET
est accepté."type": "OAUTH2_LOGOUT"
indique que le back-end est un back-end de déconnexion.-
"allowedPostLogoutUris": ["<url>", "<url>"]
(facultatif) indique la liste des URL autorisées vers lesquelles une demande de déconnexion peut être redirigée pour révoquer des jetons. Les URL de la liste peuvent être des chemins absolus ou relatifs, et les URL peuvent inclure des variables de contexte. Par exemple,["https://${request.header[tenant-id].page.html}", "https://fixed-path.page.html",
."/logout_html"
]Tenez compte des points suivants :
- Une URL post-déconnexion peut être incluse dans une demande au back-end de déconnexion en tant que valeur d'un paramètre de requête nommé
postLogoutUrl
. - Si vous indiquez un chemin relatif (c'est-à-dire vers un autre routage dans le déploiement d'API), le déploiement d'API et le routage doivent autoriser l'accès anonyme.
- Si vous n'incluez pas explicitement une ou plusieurs URL dans la liste, toute URL post-déconnexion est autorisée.
- Une URL post-déconnexion peut être incluse dans une demande au back-end de déconnexion en tant que valeur d'un paramètre de requête nommé
-
"postLogoutState": "<logout-data>"
(facultatif) indique les données à transmettre lorsqu'une demande de déconnexion est redirigée vers une adresse de fin de session et/ou une URL de post-déconnexion. Les données peuvent uniquement inclure des variables de contexte (et non des valeurs statiques). Par exemple,request.query[region]
Les données sont transmises en tant que valeur du paramètre de requête
state
.
Dans cet exemple, une demande au back-end
/logout
peut inclure l'une des URL indiquées pourallowedPostLogoutUris
en tant que valeur du paramètre de requêtepostLogoutUrl
. Lorsque l'URL après déconnexion est appelée, la valeur de la variable de contexterequest.query[region]
est transmise à l'URL. Dans cet exemple, l'une des valeursallowedPostLogoutUris
("/logout_html"
) est un chemin relatif vers le back-end de réponse par défaut/logout_html
dans le même déploiement d'API. Comme il s'agit d'un chemin relatif vers un autre routage dans le même déploiement d'API, le back-end/logout_html
doit inclure une stratégie d'autorisation de typeANONYMOUS
, comme illustré ici.{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } }, { "path": "/logout", "methods": ["GET"], "backend": { "type": "OAUTH2_LOGOUT", "allowedPostLogoutUris": ["https://${request.header[tenant-id].page.html}", "/logout_html"], "postLogoutState": "request.query[region]" } }, { "path": "/logout_html", "methods": ["GET"], "backend": { "type": "STOCK_RESPONSE_BACKEND", "body": "Token could not be revoked." }, "requestPolicies": { "authorization": { "type": "ANONYMOUS" } } } ] }
-
- Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.
-
Utilisez la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API en :
- spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Télécharger une API existante,
- spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.
Pour plus d'informations, reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et à Mise à jour d'une passerelle d'API.
- (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).