Partager via

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

  • Article

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

Actuellement, cette fonctionnalité n’est 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, configurez facilement OAuth 2.0, consentez, obtenez des jetons, mettez des jetons en cache dans un magasin d’informations d’identification et actualisez des 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 aux API d’être exposées avec ou sans clé d’abonnement, d’utiliser des autorisations OAuth 2.0 pour les services back-end, et de réduire les coûts de développement liés à l’accélération, à l’implémentation et à la maintenance des fonctionnalités de sécurité avec les 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 :

  • Se connecter facilement à un back-end SaaS en associant le jeton d’autorisation stocké et en redirigeant via proxy les requêtes

  • Rediriger via proxy les requêtes vers une application web Azure App Service ou un back-end Azure Functions en associant le jeton d’autorisation, qui peut envoyer plus tard des requêtes à un back-end SaaS appliquant une 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 de jeton récupéré, obtenir un jeton mis en cache et appeler un back-end SaaS pour le compte de l’utilisateur depuis n’importe quel 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 gestion du gestionnaire d’informations d’identification prend en charge la configuration d’un fournisseur d’informations d’identification pour les jetons OAuth 2.0. Elle permet d’établir le flux de consentement pour le fournisseur d’identité et de configurer 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 arrive dans Gestion des API et que la stratégie get-authorization-context 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 back-end. 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 connexion de ce type, 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 les API SaaS back-end qui nécessitent un contexte utilisateur, vous pouvez activer l’accès à une connexion pour le compte d’une identité d’utilisateur ou de groupe Microsoft Entra. Dans ce cas, un utilisateur configuré doit se connecter et donner son consentement une seule fois ; après cela, l’instance Gestion des API va créer et gérer sa connexion. 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 de 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ée. 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 : quand la stratégie get-authorization-context est exécutée au moment de l’exécution, le service 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é ?

Au moment de l’exécution, le service Gestion des API ne peut pas extraire 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 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 dédiés classique et v2, le jeton d’accès est mis en cache par l’instance Gestion des API jusqu’à 3 minutes avant l’expiration du jeton. Si le délai d’expiration du jeton d’accès est inférieur à 3 minutes, la durée de mise en cache se poursuit jusqu’à l’expiration du jeton d’accès.

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

Contenu connexe