Cas d'utilisation et flux de travail de l'authentification OAuth

Autorisation Types de subventions

• Code d'autorisation.

  Il s'agit du type de subvention utilisé pour obtenir des jetons d'accès (et éventuellement des jetons de rafraîchissement) et il est optimisé pour les clients confidentiels. Pour les clients publics, le type de subvention Code d' autorisation peut être davantage sécurisé par le mécanisme PKCE. Pour plus de détails, voir Sécuriser les appels de jetons d'accès avec PKCE.

  Remarque : webMethods API Gateway l'application de la directive sur l'authentification des clients confidentiels prend en charge l'authentification des clients confidentiels à l'aide des en-têtes Authorization. Les clients confidentiels doivent s'authentifier à l'aide de leurs données d'identification, de l'identifiant du client et de la combinaison du secret du client.

  Quelques points à prendre en compte lors de l'utilisation du type de subvention Code d'autorisation :

  • Si la propriété watt.server.oauth.token.endpoint.auth=session (valeur par défaut) et que le client confidentiel a déjà une session lorsqu'il s'agit du point de terminaison du jeton, l'accès au point de terminaison est accordé même s'il n'y a pas d'informations d'identification dans l'en-tête.
  • Si la propriété watt.server.oauth.token.endpoint.auth=credentials ou si le client n'a pas déjà une session, le client confidentiel doit fournir le client_secret dans l'en-tête Authorization.
  • webMethods API Gateway ne prend pas en charge le secret du client dans le corps de la demande d'octroi du code d'autorisation.

    Pour plus de détails sur les propriétés mentionnées, voir webMethods Integration Server Administrator's Guide

• Implicite.

  Il s'agit du type de subvention utilisé pour obtenir des jetons d'accès et il est optimisé pour les clients publics. Il ne permet pas l'émission de jetons de rafraîchissement.

• Références du client.

  Il s'agit du type de subvention utilisé pour obtenir des jetons d'accès pour l'authentification du client uniquement.

• Mot de passe du propriétaire de la ressource.

  Il s'agit du type de subvention utilisé pour obtenir des jetons d'accès lorsque le propriétaire de la ressource a une relation de confiance avec le client et que les clients sont capables d'obtenir les informations d'identification du propriétaire de la ressource.

  Pour plus de détails sur les propriétés mentionnées, voir webMethods Integration Server Administrator's Guide.

Les clients

• Confidentiel.

  Un client confidentiel est une application capable de garder le mot de passe d'un client confidentiel. Ce mot de passe client est attribué à l'application client par le serveur d'autorisation. Ce mot de passe est utilisé pour identifier le client auprès du serveur d'autorisation, afin d'éviter les fraudes. Un exemple de client confidentiel pourrait être une application web, où personne d'autre que l'administrateur ne peut accéder au serveur et voir le mot de passe du client.

• Public.

  Un client public est une application qui n'est pas en mesure de préserver la confidentialité du mot de passe du client. Par exemple, une application pour téléphone portable ou une application de bureau dans laquelle le mot de passe du client est intégré. Une telle application pourrait être piratée et révéler le mot de passe. Il en va de même pour une application JavaScript fonctionnant dans le navigateur de l'utilisateur. L'utilisateur pourrait utiliser un débogueur JavaScript pour accéder à l'application et voir le mot de passe du client.

webMethods API Gateway en tant que serveur de ressources

webMethods API Gateway peut être utilisé comme serveur d'autorisation et comme serveur de ressources.

Lorsque webMethods API Gateway agit en tant que serveur de ressources, il héberge les ressources protégées et accepte et répond aux demandes des applications clientes qui incluent un jeton d'accès. L'application cliente envoie le jeton d'accès dans le champ d'en-tête de la demande d'autorisation en utilisant le schéma d'authentification Bearer. Le serveur de ressources valide le jeton d'accès localement ou à distance s'il ne peut le faire localement. Si le jeton est valide et que l'application cliente dispose des privilèges nécessaires pour accéder aux ressources protégées, le serveur de ressources exécute la demande. Si le jeton d'accès n'est pas valide, la demande est rejetée.

webMethods API Gateway en tant que serveur d'autorisation

Lorsque webMethods API Gateway agit en tant que serveur d'autorisation, il reçoit des demandes d'autorisation de la part d'applications clientes. Le serveur d'autorisation gère les interactions entre l'application cliente, le serveur de ressources et le propriétaire de la ressource pour l'approbation de la demande. En tant que serveur d'autorisation, API Gateway délivre des jetons aux applications clientes au nom du propriétaire d'une ressource, jetons qui serviront à authentifier les appels API ultérieurs au serveur de ressources. Le serveur de ressources héberge les ressources protégées et peut accepter ou répondre aux demandes de ressources protégées à l'aide de jetons d'accès. Si l'application cliente est autorisée à accéder aux ressources protégées, le serveur de ressources exécute la demande. Le serveur d'autorisation conserve les informations relatives aux jetons d'accès qu'il délivre, y compris les informations relatives à l'utilisateur. Lorsqu'un client présente un jeton d'accès au serveur de ressources, ce dernier envoie le jeton au serveur d'autorisation pour s'assurer que le jeton est valide et que le service demandé entre dans le champ d'application pour lequel le jeton d'accès a été délivré. Un champ d'application est la définition des ressources auxquelles l'application cliente peut accéder au nom du propriétaire d'une ressource. Si l'application cliente n'a pas les privilèges nécessaires pour accéder aux ressources, le serveur de ressources rejette la demande.

Utilisation de webMethods API Gateway avec un serveur d'autorisation externe

Lorsque webMethods API Gateway est le serveur de ressources, vous devez spécifier un serveur d'autorisation. Au lieu d'utiliser webMethods API Gateway comme serveur d'autorisation, vous pouvez utiliser un serveur tiers comme serveur d'autorisation. Cela permet webMethods API Gateway de valider les jetons d'accès émis par des serveurs tiers et de créer dynamiquement des clients dans le serveur tiers.

Pour utiliser un serveur d'autorisation externe, vous devez configurer votre serveur d'autorisation tiers. Cela inclut, sans s'y limiter, les points suivants.

• Pour introspecter le jeton, vous devez disposer d'un URI JWKS ou créer un compte client que vous utiliserez pour appeler le point final d'introspection du serveur d'autorisation webMethods API Gateway pour appeler le point de terminaison d'introspection du serveur d'autorisation. Notez les valeurs client_id et client_secret. Vous fournissez ces informations lors de la définition de l'alias du serveur d'autorisation externe pour le serveur de ressources webMethods API Gateway serveur de ressources. Notez l'adresse URL pour le point d'aboutissement de l'introspection. Vous fournissez ces informations lors de la définition de l'alias du serveur d'autorisation externe dans le webMethods API Gateway serveur de ressources. La validation du jeton JWT du serveur d'autorisation externe s'effectue de la manière suivante :

  Introspection locale

  Introspection à distance

  La validation du jeton JWT s'effectue au sein de la passerelle dans les méthodes suivantes : Utilisation de l'URI JWKS. La signature du serveur d'autorisation externe est vérifiée en utilisant le certificat public dans l'URI JWKS. webMethods API Gateway le cache du serveur d'autorisation externe a pour clé kid claim et pour valeur le certificat correspondant à kid claim. Le cache est alimenté à chaque redémarrage de webMethods API Gateway en invoquant l'URI JWKS. Lors de la validation du jeton à l'aide de l'introspection locale, la valeur kid du JWT entrant est récupérée, le certificat correspondant est extrait du cache et la validation de la signature a lieu. Utilisation de RSA. La signature du serveur d'autorisation externe dans le JWT est vérifiée par le truststore défini dans la configuration d'introspection locale. Utilisation de HMAC. Si le serveur d'autorisation utilise l'algorithme HMAC, cela signifie que la validation de la signature du JWT est effectuée à l'aide d'une clé partagée entre le serveur d'autorisation et le webMethods API Gateway. Vous devez spécifier le secret partagé HMAC lors de la création de la stratégie de l'application. Le secret partagé HMAC dans l'application est utilisé pour valider la signature du serveur d'autorisation présente dans le JWT.

  La validation du jeton JWT est effectuée par le serveur d'autorisation. Par conséquent, la mise en cache des jetons n'est pas possible dans le cadre de l'introspection à distance. Il possède un point final d'introspection, qui est utilisé pour valider le jeton. En outre, l'identifiant et le secret du client sont utilisés pour protéger le point final, de sorte que les utilisateurs anonymes ne puissent pas accéder à la ressource. Pour invoquer un point de terminaison, vous avez besoin d'un utilisateur; l'utilisateur de la passerelle est celui que vous pouvez utiliser pour invoquer le point de terminaison.

• Créez les champs d'application nécessaires.

• Configurer un alias vers le serveur d'autorisation.

Actuellement, webMethods API Gateway par défaut, peut être utilisé avec les serveurs d'autorisation tiers suivants, sans toutefois s'y limiter, qui sont conformes à la norme RFC 7662, OAuth 2.0 token introspection :

• Okta
• PingFederate

Vous pouvez également utiliser d'autres serveurs d'autorisation tiers tels que Google, keycloak, etc.

Autorisations pour les applications créées à partir du portail du développeur

Lorsque vous créez des applications via Developer Portal, vous devez spécifier le serveur d'autorisation requis à l'aide des paramètres watt.server.oauth.authServer.alias dans la section Administration de webMethods API Gateway.

Si webMethods API Gateway est le serveur d'autorisation, indiquez local comme valeur du paramètre watt.server.oauth.authServer.alias . Sinon, indiquez le nom du serveur d'autorisation correspondant. Pour plus d'informations sur les paramètres étendus, voir Configuration des paramètres étendus.

Cas d'utilisation 1 : Authentification OAuth avec webMethods API Gateway en tant que serveur de ressources et serveur d'autorisation

Ceci décrit le flux de travail de haut niveau pour le scénario où webMethods API Gateway est un serveur de ressources ainsi qu'un serveur d'autorisation.

1. Configurer webMethods API Gateway comme serveur d'autorisation interne. Veillez à configurer les champs d'application OAuth lors de la configuration du serveur d'autorisation. Pour une procédure complète sur la configuration de webMethods API Gateway en tant que serveur d'autorisation interne, voir Configuration d'un serveur d'autorisation interne.
2. Cartographier les champs d'application. Pour une procédure complète de mappage des champs d'application, voir Mappage des champs d'application OAuth ou OpenID.
3. Appliquer la politique d'identification et d'autorisation des applications à l'API. Veillez à sélectionner le jeton OAuth2. Pour plus d'informations sur la politique d'identification et d'autorisation, voir Identifier et autoriser.
4. Associer une application à l'API. Vous pouvez créer une nouvelle application ou utiliser une application existante. Assurez-vous que l'application associée contient la stratégie d'authentification OAuth. Lors de la création d'une stratégie, vous pouvez l'associer aux champs d'application disponibles pour l'utilisation de l'enregistrement dynamique des clients. Pour une procédure complète sur la création d'une application avec une stratégie, voir Création d'une application. pour plus d'informations sur la configuration du serveur d'autorisation pour les applications créées à partir du portail du développeur, voir Autorisations pour les applications créées à partir du portail du développeur.
5. Activer l'API. L'utilisateur qui invoque l'API utilise la méthode d'identification OAuth pour accéder à la ressource protégée.
6. Obtenez un jeton d'accès par le biais des URL suivantes :

   invoke/pub.apigateway.oauth2/authorize

   invoke/pub.apigateway.oauth2/getAccessToken

7. Utilisez le jeton d'accès pour appeler l'API.

Cas d'utilisation 2 : Authentification Oauth avec webMethods API Gateway comme serveur de ressources et un serveur d'autorisation externe

Ceci décrit le flux de travail de haut niveau pour le scénario où webMethods API Gateway est le serveur de ressources avec un serveur d'autorisation tiers. Cette option est généralement utilisée dans un environnement où il existe un serveur d'autorisation, qui est utilisé avec webMethods API Gateway comme serveur de ressources.

1. Configurez un fournisseur si vous utilisez l'enregistrement dynamique des clients. Sinon, vous pouvez passer à l'étape 2. Pour une procédure complète de configuration d'un fournisseur, voir Ajout d'un fournisseur.
2. Configurer un serveur d'autorisation externe. Veillez à configurer les champs d'application OAuth lors de la configuration du serveur d'autorisation. Pour une procédure complète de configuration d'un serveur d'autorisation externe, voir Ajout d'un serveur d'autorisation externe.
3. Cartographier les champs d'application. Pour une procédure complète sur le mappage des champs d'application, voir Mappage des champs d'application OAuth ou OpenID.
4. Appliquer la politique d'identification et d'autorisation des applications à l'API. Veillez à sélectionner le jeton OAuth2. Pour plus d'informations sur la politique d'identification et d'autorisation, voir Identifier et autoriser.
5. Associer une application à l'API. Vous pouvez créer une nouvelle application ou utiliser une application existante. Assurez-vous que l'application associée contient la stratégie d'authentification OAuth et l'identifiant du client. Lors de la création d'une stratégie, vous pouvez l'associer aux champs d'application disponibles pour l'utilisation de l'enregistrement dynamique des clients. Si le serveur d'autorisation prend en charge l'enregistrement dynamique des clients, vous pouvez sélectionner l'option Générer des informations d'identification. Si l'application est déjà créée dans le serveur d'autorisation, indiquez l'identifiant du client correspondant. Pour une procédure complète sur la création d'une application avec une stratégie, voir Création d'une application. Pour plus d'informations sur la configuration du serveur d'autorisation pour les applications créées à partir du portail du développeur, voir Autorisations pour les applications créées à partir du portail du développeur.
6. Activer l'API. L'utilisateur qui invoque l'API utilise la méthode d'identification OAuth pour accéder à la ressource protégée.
7. Obtenir le jeton d'accès auprès du serveur d'autorisation.
8. Utilisez le jeton d'accès pour appeler l'API.

Pour une procédure détaillée sur l'utilisation de l'authentification OAuth avec webMethods API Gateway en tant que serveur de ressources et OKTA en tant que serveur d'autorisation externe, voir Sécurisation des API à l'aide d'un fournisseur OAuth 2 tiers sur webMethods API Gateway

Processus d'autorisation OAuth

Le processus d'autorisation OAuth est le suivant :

1. L'utilisateur final se connecte, l'application client envoie la demande d'authentification au serveur d'autorisation pour obtenir un jeton d'accès.
2. Le serveur d'autorisation valide la demande et génère un jeton d'accès pour le client.
3. Le client utilise ce jeton d'accès pour envoyer des demandes à HTTP webMethods API Gateway.
4. webMethods API Gateway effectue ensuite les opérations suivantes :

   a. Identifie l'application à l'aide de l'ID du client. b. Valide le jeton localement ou à distance si cela n'est pas possible localement. c. Vérifie si la ressource demandée fait partie des champs d'application du jeton. d. Vérifie l'audience. Si tous les éléments ci-dessus sont validés, webMethods API Gateway permet d'accéder à la ressource protégée. Si le jeton d'accès a expiré, le serveur d'autorisation renvoie une réponse d'erreur spécifique. L'application cliente peut alors utiliser Refresh Token pour demander un nouveau jeton d'accès. Le serveur d'autorisation renvoie un nouveau jeton d'accès qui peut être utilisé pour accéder à la ressource protégée.

   Remarque : lorsqu'un événement de violation de la politique est enregistré en cas d'expiration des jetons Oauth2, l'application associée devient inconnue.