Connexions OAuth 2.0 dans le gestionnaire d’informations d’identification – Détails et flux de processus

S’APPLIQUE À : tous les niveaux de Gestion des API

Cet article fournit des informations détaillées sur les flux de processus pour la gestion des connexions OAuth 2.0 à l’aide du gestionnaire d’informations d’identification dans Gestion des API Azure. Les flux de processus sont divisés en deux parties : gestion et exécution.

Pour plus d’informations sur le gestionnaire d’informations d’identification dans Gestion des API, consultez l’article À propos des informations d’identification des API et du gestionnaire d’informations d’identification dans Gestion des API.

Gestion des connexions

La partie gestion des connexions dans le gestionnaire d’informations d’identification prend en charge l’installation et 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 et de configurer une ou plusieurs connexions au fournisseur d’informations d’identification pour l’accès aux informations d’identification.

L’image suivante résume le flux de processus de création d’une connexion dans le service Gestion des API qui utilise le type d’autorisation par code d’autorisation.

Étape	Description
1	Le client envoie une requête de création d’un fournisseur d’informations d’identification
2	Le fournisseur d’informations d’identification est créé, et une réponse est retournée
3	Le client envoie une requête de création d’une connexion
4	La connexion est créée, et une réponse est retournée avec des informations indiquant que la connexion n’est pas « connectée »
5	Le client envoie une demande de récupération d’une URL de connexion pour démarrer le consentement OAuth 2.0 au niveau du fournisseur d’informations d’identification. La requête inclut une URL de redirection ultérieure à utiliser à la dernière étape
6	La réponse est retournée avec une URL de connexion qui doit être utilisée pour démarrer le flux de consentement.
7	Le client ouvre un navigateur avec l’URL de connexion fournie à l’étape précédente. Le navigateur est redirigé vers le flux de consentement OAuth 2.0 du fournisseur d’informations d’identification
8	Une fois le consentement approuvé, le navigateur est redirigé à l’aide d’un code d’autorisation vers l’URL de redirection configurée sur le fournisseur d’informations d’identification
9	Le service Gestion des API utilise le code d’autorisation pour extraire les jetons d’accès et d’actualisation
10	Le service Gestion des API reçoit et chiffre les jetons
11	Le service Gestion des API redirige vers l’URL fournie à l’étape 5

Fournisseur d’informations d’identification

Lors de la configuration de votre fournisseur d’informations d’identification, vous pouvez choisir entre différents fournisseurs OAuth et types d’autorisation (code d’autorisation ou informations d’identification du client). Chaque fournisseur nécessite des configurations spécifiques. Points importants à prendre en compte :

• Une configuration de fournisseur d’informations d’identification ne peut avoir qu’un seul type d’autorisation.
• Une configuration de fournisseur d’informations d’identification peut avoir plusieurs connexions.

Remarque

Avec le fournisseur OAuth 2.0 générique, d’autres fournisseurs d’identité prenant en charge les normes du flux OAuth 2.0 peuvent être utilisés.

Quand vous configurez un fournisseur d’informations d’identification, en arrière-plan, le gestionnaire d’informations d’identification crée un magasin d’informations d’identification qui sert à pour mettre en cache les jetons d’accès et les jetons d’actualisation OAuth 2.0 du fournisseur.

Connexion à un fournisseur d’informations d’identification

Pour accéder aux jetons et les utiliser pour un fournisseur, les applications clientes ont besoin d’une connexion au fournisseur d’informations d’identification. Une connexion donnée est autorisée par des stratégies d’accès en fonction des identités Microsoft Entra ID. Vous pouvez configurer plusieurs connexions pour un fournisseur.

Le processus de configuration d’une connexion varie en fonction de l’octroi configuré et est spécifique de la configuration du fournisseur d’informations d’identification. Par exemple, si vous voulez configurer Microsoft Entra ID pour utiliser les deux types d’autorisation, deux configurations de fournisseur d’informations d’identification sont nécessaires. Le tableau suivant récapitule les deux types d’autorisation.

Type d’autorisation	Description
Code d’autorisation.	Lié à un contexte utilisateur, ce qui signifie qu’un utilisateur doit donner son consentement à la connexion. Tant que le jeton d’actualisation est valide, Gestion des API peut récupérer de nouveaux jetons d’accès et d’actualisation. Si le jeton d’actualisation devient non valide, l’utilisateur doit être autorisé de nouveau. Tous les fournisseurs d’informations d’identification prennent en charge le code d’autorisation. En savoir plus
Informations d'identification du client	N’est pas lié à un utilisateur et est souvent utilisé dans les scénarios d’application à application. Aucun consentement n’est requis pour le type d’autorisation d’informations d’identification du client, et la connexion reste valide. En savoir plus

Consentement

Pour les connexions basées sur le type d’autorisation Code d’autorisation, vous devez vous authentifier auprès du fournisseur et consentir à l’autorisation. Une fois la connexion et l’autorisation correctement effectuées par le fournisseur d’informations d’identification, le fournisseur retourne des jetons d’accès et d’actualisation valides, qui sont chiffrés et enregistrés par le service Gestion des API.

Stratégie d’accès

Vous configurez une ou plusieurs stratégies d’accès pour chaque connexion. Les stratégies d’accès déterminent les identités Microsoft Entra ID qui peuvent accéder à vos informations d’identification au moment de l’exécution. Les connexions prennent actuellement en charge l’accès à l’aide de principaux de service, de l’identité, des utilisateurs et des groupes de votre instance Gestion des API.

Identité	Description	Avantages	Considérations
Principal du service	Identité dont les jetons peuvent être utilisés pour authentifier et accorder l’accès à des ressources Azure spécifiques, quand une organisation utilise Microsoft Entra ID. En utilisant un principal de service, les organisations évitent de créer des utilisateurs fictifs pour gérer l’authentification lorsqu’elles ont besoin d’accéder à une ressource. Un principal de service est une identité Microsoft Entra qui représente une application Microsoft Entra inscrite.	Autorise un accès plus étroitement délimité aux scénarios de délégation de connexions et d’utilisateurs. N’est pas lié à une instance Gestion des API particulière. Dépend de Microsoft Entra ID pour l’application des autorisations.	L’obtention du contexte d’autorisation nécessite un jeton Microsoft Entra ID.
Identité managée <Your API Management instance name>	Cette option correspond à une identité managée liée à votre instance Gestion des API.	Par défaut, l’accès est fourni à l’identité managée affectée par le système pour l’instance Gestion des API correspondante.	L’identité est liée à votre instance Gestion des API. Toute personne disposant d’un accès Contributeur à l’instance Gestion des API peut accéder à une connexion accordant des autorisations d’identité managée.
Utilisateurs ou groupes	Utilisateurs ou groupes de votre locataire Microsoft Entra ID.	Permet de limiter l’accès à des utilisateurs ou groupes d’utilisateurs spécifiques.	Nécessite que les utilisateurs disposent d’un compte Microsoft Entra ID.

Exécution de connexions

La partie exécution nécessite qu’une API OAuth 2.0 back-end soit configurée avec la stratégie get-authorization-context. Au moment de l’exécution, la stratégie récupère et stocke les jetons d’accès et d’actualisation à partir du magasin d’informations d’identification que le service Gestion des API a configuré pour le fournisseur. Quand 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’informations d’identification. Ensuite, le jeton d’accès est utilisé pour autoriser l’accès au service back-end.

Pendant l’exécution de la stratégie, l’accès aux jetons est également validé à l’aide de stratégies d’accès.

L’image suivante montre un exemple de flux du processus d’extraction et de stockage des jetons d’autorisation et d’actualisation, en fonction d’une connexion qui utilise le type d’autorisation Code d’autorisation. Une fois que les jetons ont été récupérés, un appel est effectué à l’API back-end.

Étape	Description
1	Le client envoie une requête à l’instance Gestion des API
2	La stratégie get-authorization-context vérifie si le jeton d’accès est valide pour la connexion actuelle
3	Si le jeton d’accès a expiré, mais que le jeton d’actualisation est valide, le service Gestion des API tente d’extraire de nouveaux jetons d’accès et d’actualisation à partir du fournisseur d’informations d’identification configuré
4	Le fournisseur d’informations d’identification retourne un jeton d’accès et un jeton d’actualisation, tous deux étant chiffrés et enregistrés dans Gestion des API
5	Une fois les jetons récupérés, le jeton d’accès est associé au moyen de la stratégie set-header en tant qu’en-tête d’autorisation, à la requête sortante pour l’API back-end
6	La réponse est retournée au service Gestion des API
7	La réponse est retournée au client

Contenu connexe

• Vue d’ensemble du gestionnaire d’informations d’identification
• Configurer des fournisseurs d’informations d’identification dans le gestionnaire d’informations d’identification
• Configurer et utiliser une autorisation pour l’API Microsoft Graph ou l’API GitHub
• Configurer plusieurs connexions d’autorisation pour un fournisseur
• Configurer une connexion pour l’accès délégué par l’utilisateur