Partager via


À propos des informations d’identification des API et du gestionnaire d’informations d’identification

S'APPLIQUE À : Tous les niveaux de Gestion des API

Pour vous aider à gérer l’accès aux API back-end, votre instance Gestion des API inclut un gestionnaire d’informations d’identification. Utilisez le gestionnaire d’informations d’identification pour gérer, stocker et contrôler l’accès aux informations d’identification des API à partir de votre instance Gestion des API.

Remarque

  • Actuellement, vous pouvez utiliser le gestionnaire d’informations d’identification pour configurer et gérer les connexions (anciennement appelées autorisations) pour les API OAuth 2.0 back-end.
  • Aucun changement cassant n’est introduit avec le gestionnaire d’informations d’identification. Les fournisseurs d’informations d’identification et les connexions OAuth 2.0 utilisent les API d’autorisation et le fournisseur de ressources existants de Gestion des API.

Remarque

Cette fonctionnalité n’est actuellement pas disponible dans les espaces de travail.

Connexions managées pour les API OAuth 2.0

Grâce au gestionnaire d’informations d’identification, vous pouvez simplifier considérablement le processus d’authentification et d’autorisation des utilisateurs, des groupes et des principaux de service sur un ou plusieurs services back-end ou SaaS qui utilisent OAuth 2.0. À l’aide du gestionnaire d’informations d’identification de Gestion des API, vous pouvez facilement configurer OAuth 2.0, consentir, acquérir des jetons, mettre en cache des jetons dans un magasin d’informations d’identification et actualiser les jetons sans écrire une seule ligne de code. Utilisez des stratégies d’accès pour déléguer l’authentification à votre instance Gestion des API, aux principaux de service, aux utilisateurs ou aux groupes. Pour plus d’informations sur OAuth 2.0, consultez l’article Plateforme d’identités Microsoft et flux de code d’autorisation OAuth 2.0.

Cette fonctionnalité permet d’exposer des API avec ou sans clé d’abonnement, à l’aide d’autorisations OAuth 2.0 pour les services principaux et de réduire les coûts de développement en accélérant, en implémentant et en conservant des fonctionnalités de sécurité avec des intégrations de service.

Diagramme du gestionnaire d’informations d’identification Gestion des API et des fournisseurs d’identité SaaS pris en charge.

Exemples de cas d’utilisation

À l’aide des connexions OAuth managées dans Gestion des API, les clients peuvent se connecter facilement à des fournisseurs SaaS ou à des services back-end qui utilisent OAuth 2.0. Voici quelques exemples :

  • Connectez-vous facilement à un back-end SaaS en attachant le jeton d’autorisation stocké et les demandes de proxy.

  • Demandes de proxy vers une application web Azure App Service ou un back-end Azure Functions en attachant le jeton d’autorisation, qui peut ensuite envoyer des demandes à un back-end SaaS appliquant la logique de transformation.

  • Rediriger via proxy les requêtes vers les back-ends de fédération GraphQL en associant plusieurs jetons d’accès afin de procéder facilement à la fédération.

  • Exposer un point de terminaison pour récupérer un jeton, acquérir un jeton mis en cache et appeler un back-end SaaS pour le compte de l’utilisateur à partir de n’importe quel environnement de calcul ; par exemple, une application console ou un démon Kubernetes. Combiner votre kit SDK SaaS favori dans une langue prise en charge.

  • Des scénarios sans assistance Azure Functions lors de la connexion à plusieurs back-ends SaaS.

  • Durable Functions se rapproche de Logic Apps avec la connectivité SaaS.

  • À l’aide des connexions OAuth 2.0, chaque API dans le service Gestion des API peut agir en tant que connecteur personnalisé Logic Apps.

Comment fonctionne le gestionnaire d’informations d’identification ?

Les informations d’identification de jeton dans le gestionnaire d’informations d’identification se composent de deux parties : gestion et exécution.

  • La partie de gestion du gestionnaire d’informations d’identification prend en charge la configuration et la configuration d’un fournisseur d’informations d’identification pour les jetons OAuth 2.0, en activant le flux de consentement pour le fournisseur d’identité et en configurant une ou plusieurs connexions au fournisseur d’informations d’identification pour l’accès aux informations d’identification. Pour plus d’informations, consultez la section Gestion des connexions.

  • La partie exécution utilise la stratégie get-authorization-context pour extraire et stocker les jetons d’accès et d’actualisation de la connexion. Lorsqu’un appel entre dans Gestion des API et que la get-authorization-context stratégie est exécutée, il vérifie d’abord si le jeton d’autorisation existant est valide. Si le jeton d’autorisation a expiré, le service Gestion des API utilise un flux OAuth 2.0 pour actualiser les jetons stockés à partir du fournisseur d’identité. Ensuite, le jeton d’accès est utilisé pour autoriser l’accès au service principal. Pour plus d’informations, consultez la section Exécution des connexions.

Quand utiliser le gestionnaire d’informations d’identification ?

Voici trois scénarios d’utilisation du gestionnaire d’informations d’identification.

Scénario de configuration

Après la configuration du fournisseur d’informations d’identification et d’une connexion, le gestionnaire d’API peut tester la connexion. Le gestionnaire d’API configure une API OAuth back-end de test pour utiliser la stratégie get-authorization-context à l’aide de l’identité managée de l’instance. Le gestionnaire d’API peut ensuite tester la connexion en appelant l’API de test.

Diagramme du scénario de configuration initial pour le gestionnaire d’informations d’identification.

Scénario sans assistance

Par défaut, quand une connexion est créée, une stratégie d’accès et une connexion sont préconfigurées pour l’identité managée de l’instance Gestion des API. Pour utiliser une telle connexion, différents utilisateurs peuvent se connecter à une application cliente telle qu’une application web statique, qui appelle ensuite une API back-end exposée via Gestion des API. Pour effectuer cet appel, les connexions sont appliquées à l’aide de la stratégie get-authorization-context. Étant donné que l’appel d’API utilise une connexion préconfigurée qui n’est pas liée au contexte utilisateur, les mêmes données sont retournées à tous les utilisateurs.

Diagramme du scénario d’identité managée pour le gestionnaire d’informations d’identification.

Scénario avec assistance (délégué à l’utilisateur)

Pour activer une expérience d’authentification simplifiée pour les utilisateurs d’applications clientes (telles que les applications web statiques) qui appellent des API SaaS back-end qui nécessitent un contexte utilisateur, vous pouvez activer l’accès à une connexion pour le compte d’un utilisateur ou d’une identité de groupe Microsoft Entra. Dans ce cas, un utilisateur configuré doit se connecter et fournir son consentement une seule fois, et l’instance Gestion des API crée et gère sa connexion après cela. Quand Gestion des API obtient un appel entrant à transférer vers un service externe, il attache le jeton d’accès de la connexion à la demande. Cette situation est idéale quand les requêtes et réponses d’API sont destinées à un individu (par exemple, récupération d’informations de profil spécifiques d’un utilisateur).

Diagramme du scénario délégué par l’utilisateur pour le gestionnaire d’informations d’identification.

Comment configurer le gestionnaire d’informations d’identification ?

Spécifications

  • L’identité affectée par le système managée doit être activée pour l’instance Gestion des API.

  • L’instance Gestion des API doit disposer d’une connectivité sortante vers Internet sur le port 443 (HTTPS).

Disponibilité

  • Tout niveau de service de Gestion des API

  • Pas de prise en charge dans la passerelle autohébergée

  • Pas de prise en charge dans les clouds souverains ni dans les régions suivantes : australiacentral, australiacentral2, indiacentral

Exemples étape par étape

Considérations relatives à la sécurité

Le jeton d’accès et d’autres secrets (par exemple, les clés secrètes clients) sont chiffrés avec un chiffrement d’enveloppe et stockés dans un stockage interne multilocataire. Les données sont chiffrées avec AES-128 à l’aide d’une clé unique par données. Ces clés sont chiffrées de manière asymétrique avec un certificat principal stocké dans Azure Key Vault, et elles font l’objet d’une rotation tous les mois.

limites

Ressource Limite
Nombre maximal de fournisseurs d’informations d’identification par instance de service 1 000
Nombre maximal de connexions par fournisseur d’informations d’identification 10 000
Nombre maximal de stratégies d’accès par connexion 100
Nombre maximal de demandes d’autorisation par minute par connexion 250

Forum Aux Questions (FAQ)

Quand les jetons d’accès sont-ils actualisés ?

Pour une connexion de type code d'autorisation, les jetons d'accès sont actualisés comme suit :

Lorsque la stratégie get-authorization-context est exécutée pendant l'exécution, la gestion des API vérifie si le jeton d'accès stocké est valide. Si le jeton a expiré ou est proche de l’expiration, Gestion des API utilise le jeton d’actualisation pour extraire un nouveau jeton d’accès et un nouveau jeton d’actualisation à partir du fournisseur d’identité configuré. Si le jeton d’actualisation a expiré, une erreur est générée et la connexion doit être réautorisée avant de pouvoir fonctionner.

Que se passe-t-il si la clé secrète client expire au niveau du fournisseur d’identité ?

Lors de l’exécution, gestion des API ne peut pas récupérer de nouveaux jetons et une erreur se produit.

  • Si la connexion est de type code d’autorisation, la clé secrète client doit être mise à jour au niveau du fournisseur d’informations d’identification.

  • Si la connexion est de type informations d’identification du client, la clé secrète client doit être mise à jour au niveau de la connexion.

Cette fonctionnalité est-elle prise en charge à l’aide de Gestion des API exécuté à l’intérieur d’un réseau virtuel ?

Oui, tant que la connectivité sortante sur le port 443 est activée sur l’étiquette de service AzureConnectors. Pour plus d'informations, consultez Référence de configuration de réseau virtuel.

Que se passe-t-il quand un fournisseur d’informations d’identification est supprimé ?

Toutes les connexions et stratégies d’accès sous-jacentes sont également supprimées.

Les jetons d’accès sont-ils mis en cache par Gestion des API ?

Dans les niveaux de service classique et v2, le jeton d’accès est mis en cache par l’instance Gestion des API jusqu’à trois minutes avant l’heure d’expiration du jeton. Si le jeton d’accès est à moins de trois minutes de l'expiration, le moment mis en cache sera jusqu'à l'expiration du jeton d'accès.

Les jetons d’accès ne sont pas mis en cache dans le niveau Consommation.