Partager via

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

  • Article

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.

Notes

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 et 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 par le biais d’informations d’identification telles que le nom d’utilisateur et le mot de passe, d’un certificat ou de l’authentification unique (SSO) ou d’autres méthodes.

  • Autorisation – Processus permettant de déterminer si un utilisateur ou une application est autorisé à accéder à une API précise, souvent par le biais d’un protocole basé sur des jetons comme OAuth 2.0.

Notes

Pour compléter l’authentification et l’autorisation, l’accès aux API doit également être sécurisé à l’aide du protocole TLS afin de protéger les informations d’identification ou les jetons utilisés pour l’authentification ou l’autorisation.

Concepts OAuth 2.0

OAuth 2.0 est un cadre 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 quand une application cliente appelle une API avec une requête sécurisée à l’aide du protocole TLS et d’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 comprend une revendication d’audience autorisant l’accès à un serveur de ressources (par exemple, à une API de back-end 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 Authorization.

  • 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. Le service Gestion des API Azure agit ensuite comme un proxy « transparent » entre l’appelant et l’API back-end, et transmet le jeton par le biais d’un jeton inchangé au back-end. L’étendue du jeton d’accès est 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 requêtes qui arrivent sans jeton ou avec un jeton non valide pour l’API back-end visée. 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. Par exemple :

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

    Le service Gestion des API doit d’abord être configuré pour valider le jeton (au minimum, vérification des revendications d’émetteur et d’audience). 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 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 le service Gestion des API a correctement validé le jeton reçu de l’appelant, il doit 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

    Quels que soient les mécanismes d’authentification et d’autorisation sur leurs back-ends d’API, les organisations peuvent choisir de converger vers OAuth 2.0 pour une approche d’autorisation standardisée sur le front-end. 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 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 recommandée, et qu’OAuth 2.0 soit devenu la méthode dominante pour activer l’autorisation forte pour les API, le service 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 back-end (côté service). Selon les exigences de l’organisation, celles-ci peuvent être utilisées 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

Mécanisme 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.
Restrict caller IPs 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. En soi, 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, pour le suivi de l’utilisation de l’API de clients individuels ou pour l’octroi d’accès à des produits API spécifiques.

Conseil

Pour une défense en profondeur, le déploiement d’un pare-feu d’applications web en amont de l’instance Gestion des API est fortement recommandé. Par exemple, utilisez Azure Application Gateway ou Azure Front Door.

Options côté service

Mécanisme 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 un coffre à clé.
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 de meilleures options sont disponibles.

Étapes suivantes