Partager via

Connexions OAuth 2.0 dans le gestionnaire d'authentification - détails du processus et des flux

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

Cet article fournit des détails sur les flux de processus de 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 : la gestion et leruntime.

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

Gestion des connexions

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

L’image suivante récapitule le flux de processus pour la création d’une connexion dans Gestion des API qui utilise le type d’octroi de code d’autorisation.

Diagramme montrant le flux de processus pour la création d’informations d’identification.

Étape Descriptif
1 Le client envoie une demande pour créer un fournisseur d’informations d’identification.
2 Le fournisseur d'identifiants est créé et une réponse est renvoyée.
3 Le client envoie une demande pour créer une connexion.
4 La connexion est créée et une réponse est renvoyée avec les informations que la connexion n’est pas « connectée ».
5 Le client envoie une demande pour récupérer 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 post-redirection à 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é avec un code d’autorisation vers l’URL de redirection configurée sur le fournisseur d’informations d’identification.
9 Gestion des API utilise le code d’autorisation pour extraire les jetons d’accès et d’actualisation.
10 Gestion des API reçoit les jetons et les chiffre.
11 Gestion des API redirige vers l’URL fournie à l’étape 5.

Fournisseur de justificatifs d'identité

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

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

Note

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

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

Connexion à un fournisseur d’informations d’identification

Pour accéder et utiliser des jetons 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 les stratégies d’accès basées sur les identités d’ID Microsoft Entra. Vous pouvez configurer plusieurs connexions pour un fournisseur.

Le processus de configuration d’une connexion diffère en fonction de l’octroi configuré et est spécifique à la configuration du fournisseur d’informations d’identification. Par exemple, si vous souhaitez configurer Microsoft Entra ID pour utiliser les deux types d’octroi, vous avez besoin de deux configurations de fournisseur d’informations d’identification. Le tableau suivant récapitule les deux types d’octroi.

Type d’octroi Descriptif
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 réauthoriser. 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

Pour les connexions basées sur le type d’octroi de code d’autorisation, vous devez vous authentifier auprès du fournisseur et donner votre consentement à l’autorisation. Une fois la connexion et l’autorisation réussies 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 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 d’ID Microsoft Entra 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é Descriptif Avantages Considérations
Service Principal Identité dont les jetons peuvent être utilisés pour authentifier et accorder l’accès à des ressources Azure spécifiques lorsqu’une organisation utilise l’ID Microsoft Entra. En utilisant un principal de service, les organisations évitent de créer des utilisateurs fictifs pour gérer l’authentification lorsqu’ils doivent accéder à une ressource. Un principal de service est une identité Microsoft Entra qui représente une application Microsoft Entra inscrite. Autorise l’accès plus étroitement limité aux scénarios de connexion et de délégation d’utilisateurs. N’est pas lié à une instance de gestion des API spécifique. S’appuie sur l’ID Microsoft Entra pour l’application des autorisations. L’obtention du contexte d’autorisation nécessite un jeton d’ID Microsoft Entra.
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 de 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 à n’importe quelle connexion accordant des autorisations d’identité managée.
Utilisateurs ou groupes Utilisateurs ou groupes de votre locataire Microsoft Entra ID. Vous permet de limiter l’accès à des utilisateurs ou groupes d’utilisateurs spécifiques. Nécessite que les utilisateurs disposent d’un compte d’ID Microsoft Entra.

Durée d'exécution des connexions

La partie runtime nécessite qu’une API OAuth 2.0 back-end soit configurée avec la stratégie get-authorization-context . Lors 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 configuré par Gestion des API pour le fournisseur. Lorsqu’un appel entre dans Gestion des API et que la get-authorization-context stratégie est exécutée, elle vérifie d’abord si le jeton d’autorisation existant est valide. Si le jeton d’autorisation a expiré, Gestion des API utilise un flux OAuth 2.0 pour actualiser les jetons stockés du fournisseur d’informations d’identification. Ensuite, le jeton d’accès est utilisé pour autoriser l’accès au service principal.

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 de processus pour extraire et stocker des jetons d’autorisation et d’actualisation en fonction d’une connexion qui utilise le type d’octroi de code d’autorisation. Une fois les jetons récupérés, un appel est effectué à l’API back-end.

Diagramme montrant le flux de processus pour récupérer le jeton au moment de l’exécution.

Étape Descriptif
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, 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 à la fois un jeton d’accès et un jeton d’actualisation, qui sont 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 à Gestion des API.
7 La réponse est retournée au client.

Contenu connexe

  • Last updated on