Partager via

Authentification et autorisation des API dans le service Gestion des API Azure

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

Cet article est une introduction à un ensemble riche et flexible de fonctionnalités dans Gestion des API qui vous aident à sécuriser l’accès des utilisateurs aux API gérées.

L’authentification et l’autorisation des API dans le service Gestion des API impliquent la communication de bout en bout des applications clientes via la passerelle Gestion des API vers les API back-end. Dans de nombreux environnements de client, OAuth 2.0 est le protocole d’autorisation d’API préféré. Le service Gestion des API prend en charge l’autorisation OAuth 2.0 entre le client et la passerelle de gestion des API, entre la passerelle et l’API back-end, ou les deux indépendamment.

Schéma montrant les points d’interaction pour la sécurisation des API.

Le service Gestion des API prend en charge d’autres mécanismes d’authentification et d’autorisation côté client et côté service qui complètent OAuth 2.0 ou qui sont utiles lorsque l’autorisation OAuth 2.0 pour les API n’est pas possible. La façon dont vous choisissez parmi ces options dépend de la maturité de l’environnement d’API de votre organisation, de vos exigences de sécurité et de conformité, ainsi que de l’approche de votre organisation pour atténuer les menaces d’API courantes.

Important

La sécurisation de l’accès des utilisateurs aux API est l’une des nombreuses considérations relatives à la sécurisation de votre environnement Gestion des API. Pour plus d’informations, consultez Base de référence sur la sécurité Azure pour Gestion des API.

Remarque

D’autres composants Gestion des API ont des mécanismes distincts pour sécuriser et restreindre l’accès utilisateur :

  • Pour gérer l’instance Gestion des API avec le plan de contrôle Azure, Gestion des API s’appuie sur Microsoft Entra ID et le contrôle d’accès en fonction du rôle (RBAC) Azure.
  • Le portail des développeurs Gestion des API prend en charge plusieurs options pour faciliter l’inscription et la connexion des utilisateurs.

Authentification ou autorisation

Voici une brève explication de l’authentification et de l’autorisation dans le contexte de l’accès aux API :

  • Authentification : processus de vérification de l’identité d’un utilisateur ou d’une application qui accède à l’API. L’authentification peut être effectuée via des informations d’identification telles que le nom d’utilisateur et le mot de passe, un certificat ou l’authentification unique (SSO) ou d’autres méthodes.

  • Autorisation : processus permettant de déterminer si un utilisateur ou une application a l’autorisation d’accéder à une API particulière, souvent par le biais d’un protocole basé sur des jetons tel que OAuth 2.0.

Remarque

Pour compléter l’authentification et l’autorisation, vous devez également sécuriser l’accès aux API à l’aide de TLS pour protéger les informations d’identification ou les jetons que vous utilisez pour l’authentification ou l’autorisation.

Concepts OAuth 2.0

OAuth 2.0 est un framework d’autorisation standard largement utilisé pour sécuriser l’accès aux ressources telles que les API web. OAuth 2.0 limite les actions de ce qu’une application cliente peut effectuer sur les ressources pour le compte de l’utilisateur, sans jamais partager les informations d’identification de l’utilisateur. Bien qu’OAuth 2.0 ne soit pas un protocole d’authentification, il est souvent utilisé avec OpenID Connect (OIDC), qui étend OAuth 2.0 en fournissant des fonctionnalités d’authentification utilisateur et d’authentification unique.

Flux OAuth

Que se passe-t-il lorsqu’une application cliente appelle une API avec une requête sécurisée à l’aide de TLS et OAuth 2.0 ? Voici un échantillon de flux abrégé :

  • Le client (application appelante ou porteur) s’authentifie à l’aide d’informations d’identification auprès d’un fournisseur d’identité.

  • Le client obtient un jeton d’accès (jeton web JSON ou JWT) limité dans le temps, du serveur d’autorisation du fournisseur d’identité.

    Le fournisseur d’identité (par exemple, Microsoft Entra ID) est l’émetteur du jeton, et le jeton inclut une revendication d’audience qui autorise l’accès à un serveur de ressources (par exemple, à une API principale ou à la passerelle gestion des API elle-même).

  • Le client appelle l’API et présente le jeton d’accès ; par exemple, dans un en-tête d’autorisation.

  • Le serveur de ressources valide le jeton d’accès. La validation est un processus complexe qui inclut la vérification que les revendications d’émetteur et d’audience contiennent des valeurs attendues.

  • Sur la base de critères de validation de jeton, l’accès aux ressources de l’API back-end est accordé.

Selon le type d’application cliente et les scénarios, différents flux d’autorisation sont nécessaires pour demander et gérer des jetons. Par exemple, le flux de code d’autorisation et le type d’octroi sont couramment utilisés dans des applications qui appellent des API web. Découvrez plus d’informations sur les Flux OAuth et scénarios d’application dans Microsoft Entra ID.

Scénarios d’autorisation OAuth 2.0 dans Gestion des API

Scénario 1 – L’application cliente autorise directement le back-end

Un scénario d’autorisation courant a lieu lorsque l’application appelante demande directement l’accès à l’API back-end et présente un jeton OAuth 2.0 dans un en-tête d’autorisation à la passerelle. La gestion des API Azure agit ensuite comme un proxy « transparent » entre l’appelant et l’API back-end et transmet le jeton sans modification au serveur principal. L’étendue du jeton d’accès est comprise entre l’application appelante et l’API back-end.

L’image suivante montre un exemple où Microsoft Entra ID est le fournisseur d’autorisation. L’application cliente peut être une application monopage (SPA).

Diagramme montrant une communication OAuth où l’audience est l’API back-end.

Bien que le jeton d’accès envoyé avec la requête HTTP soit destiné à l’API back-end, le service Gestion des API permet toujours une approche de défense en profondeur. Par exemple, configurez des stratégies pour valider le JWT, rejetant les demandes qui arrivent sans jeton ou un jeton non valide pour l’API back-end prévue. Vous pouvez également configurer le service Gestion des API pour vérifier d’autres revendications d’intérêt extraites du jeton.

Remarque

Si vous sécurisez ainsi une API exposée via la Gestion des API Azure avec OAuth 2.0, vous pouvez configurer la Gestion des API pour générer un jeton valide à des fins de test pour le compte d’un utilisateur de console de test du Portail Azure ou du portail des développeurs. Vous devez ajouter un serveur OAuth 2.0 à votre instance de Gestion des API et activer les paramètres d’autorisation OAuth 2.0 dans l’API. Pour plus d’informations, consultez Comment autoriser la console de test du portail des développeurs en configurant une autorisation utilisateur OAuth 2.0.

Exemple :

Conseil

Dans le cas particulier où l’accès à l’API est protégé avec Microsoft Entra ID, vous pouvez configurer la stratégie validate-azure-ad-token pour la validation de jeton.

Scénario 2 – L’application cliente autorise le service Gestion des API

Dans ce scénario, le service Gestion des API agit pour le compte de l’API, et l’application appelante demande l’accès à l’instance de Gestion des API. L’étendue du jeton d’accès se situe entre l’application appelante et la passerelle Gestion des API. Dans le service Gestion des API, configurez une stratégie (validate-jwt ou validate-azure-ad-token) pour valider le jeton avant que la passerelle ne transmette la requête au back-end. Un mécanisme distinct sécurise généralement la connexion entre la passerelle et l’API back-end.

Dans l’exemple suivant, Microsoft Entra ID est à nouveau le fournisseur d’autorisation, et l’authentification TLS mutuelle (mTLS) sécurise la connexion entre la passerelle et le back-end.

Diagramme montrant une communication OAuth où l’audience est la passerelle de Gestion des API.

Il existe différentes raisons pour procéder de la sorte. Exemple :

  • Le back-end est une API héritée qui ne peut pas être mise à jour pour prendre en charge OAuth

    Vous devez d’abord configurer API Management pour valider le jeton (vérification des assertions concernant l’émetteur et l’audience au minimum). Après validation, utilisez l’une des options disponibles pour sécuriser les connexions ultérieures à partir du service Gestion des API, comme une authentification TLS mutuelle (mTLS). Consultez les options côté service plus loin dans cet article.

  • Il n’est pas possible d’établir le contexte requis par l’API back-end à partir de l’appelant

    Une fois que la Gestion de l'API a correctement validé le jeton reçu de l’appelant, elle doit ensuite obtenir un jeton d'accès pour l'API back-end en utilisant son propre contexte ou un contexte dérivé de l'application appelante. Ce scénario peut être réalisé en utilisant, au choix :

    • Une stratégie personnalisée telle que send-request pour obtenir d’un fournisseur d’identité configuré un jeton d’accès ultérieur valide pour l’API back-end.

    • L’identité de l’instance de Gestion des API, en transmettant à l’API principale le jeton de l’identité managée affectée par le système de la ressource Gestion des API, ou affectée par l’utilisateur.

  • L’organisation souhaite adopter une approche d’autorisation standardisée

    Indépendamment des mécanismes d’authentification et d’autorisation sur leurs back-ends d’API, les organisations peuvent choisir de converger sur OAuth 2.0 pour une approche d’autorisation standardisée sur le serveur frontal. La passerelle Gestion des API peut permettre une configuration d’autorisation cohérente et une expérience commune pour les consommateurs d’API à mesure que les back-ends de l’organisation évoluent.

Scénario 3 : le service Gestion des API autorise le back-end

Avec les connexions managées (anciennement appelées autorisations), vous utilisez le gestionnaire d’informations d’identification dans Gestion des API pour autoriser l’accès à un ou plusieurs services back-end ou SaaS tels que LinkedIn, GitHub ou d’autres back-ends compatibles avec OAuth 2.0. Dans ce scénario, un utilisateur ou une application cliente effectue une requête à la passerelle Gestion des API, avec l’accès à la passerelle contrôlé à l’aide d’un fournisseur d’identité ou d’autres options côté client. Ensuite, par le biais de la configuration de la stratégie, l’utilisateur ou l’application cliente délègue l’authentification et l’autorisation back-end à Gestion des API.

Dans l’exemple suivant, une clé d’abonnement est utilisée entre le client et la passerelle, et GitHub est le fournisseur d’informations d’identification pour l’API back-end.

Diagramme indiquant l'autorisation d'accéder à un service SaaS dorsal à l'aide d'une connexion gérée dans le gestionnaire d'informations d'identification.

Avec une connexion à un fournisseur d’informations d’identification, le service Gestion des API acquiert et actualise les jetons pour l’accès à l’API dans le flux OAuth 2.0. Les connexions simplifient la gestion des jetons dans plusieurs scénarios, tels que :

  • Une application cliente peut avoir besoin d’autoriser plusieurs back-ends SaaS à résoudre plusieurs champs à l’aide de GraphQL résolveurs.
  • Les utilisateurs s’authentifient auprès du service Gestion des API par l’authentification unique à partir de leur fournisseur d’identité, mais autorisent un fournisseur SaaS back-end (tel que LinkedIn) à l’aide d’un compte organisationnel commun.
  • Une application cliente (ou bot) doit accéder à des ressources en ligne sécurisées par un back-end pour le compte d’un utilisateur authentifié (par exemple, vérifier les e-mails ou passer une commande).

Exemples :

Autres options pour sécuriser les API

Bien que l’autorisation soit préférée et OAuth 2.0 est devenue la méthode dominante d’activation d’une autorisation forte pour les API, Gestion des API fournit plusieurs autres mécanismes pour sécuriser ou restreindre l’accès entre le client et la passerelle (côté client) ou entre la passerelle et le serveur principal (côté service). En fonction des exigences de l’organisation, vous pouvez les utiliser pour compléter OAuth 2.0. Vous pouvez également les configurer indépendamment si les applications appelantes ou les API back-end sont héritées ou ne prennent pas encore en charge OAuth 2.0.

Options côté client

Mechanism Description Considérations
mTLS Valider le certificat présenté par le client de connexion et cocher les propriétés de certificat par rapport à un certificat géré dans Gestion des API Le certificat peut être stocké dans un coffre de clés.
Restreindre les adresses IP de l’appelant Filtrer (autoriser/refuser) les appels à partir d’adresses IP ou de plages d’adresses spécifiques. Permet de restreindre l’accès à certains utilisateurs ou organisations, ou au trafic provenant de services en amont.
Clé d’abonnement Limiter l’accès à une ou plusieurs API basées sur un abonnement Gestion des API Nous vous recommandons d’utiliser une clé d’abonnement (API) en plus d’une autre méthode d’authentification ou d’autorisation. Par lui-même, une clé d’abonnement n’est pas une forme d’authentification forte, mais l’utilisation de la clé d’abonnement peut être utile dans certains scénarios ; par exemple, le suivi de l’utilisation de l’API des clients individuels ou l’octroi de l’accès à des produits API spécifiques.

Conseil

Pour la défense en profondeur, nous vous recommandons vivement de déployer un pare-feu d’applications web en amont de l’instance Gestion des API. Par exemple, utilisez Azure Application Gateway ou Azure Front Door.

Options côté service

Mechanism Description Considérations
Authentification d’une identité managée Authentifiez-vous auprès de l’API back-end avec une identité managée affectée par le système ou affectée par l’utilisateur. Recommandé pour l’accès limité à une ressource de back-end protégée en obtenant un jeton Microsoft Entra ID.
Authentification par certificat Authentifiez-vous auprès de l’API back-end à l’aide d’un certificat client. Le certificat peut être stocké dans le coffre de clés.
Authentification de base Authentifiez-vous auprès de l’API back-end avec un nom d’utilisateur et un mot de passe transmis via un en-tête d’autorisation. Déconseillé si des options d’authentification plus sécurisées sont disponibles (par exemple, identité managée, certificats, gestionnaire d’informations d’identification). Si vous choisissez cette option, utilisez des valeurs nommées pour fournir des informations d’identification, avec des secrets protégés dans un coffre de clés.

Contenu connexe

  • Last updated on