Sécuriser les API à l’aide d’abonnements
Lors de la publication d’API via la Gestion des API, il est facile et courant de sécuriser l’accès à ces API au moyen de clés d’abonnement. Les développeurs qui utilisent les API publiées doivent inclure une clé d’abonnement valide dans les requêtes HTTP lorsqu’ils effectuent des appels vers ces API. Sinon, les appels sont immédiatement rejetés par la passerelle de Gestion des API. Ils ne sont pas transférés vers les services backend.
Pour obtenir une clé d’abonnement permettant d’accéder aux API, un abonnement est nécessaire. Un abonnement est avant tout un conteneur nommé pour une paire de clés d’abonnement. Les développeurs devant utiliser les API publiées peuvent obtenir des abonnements. Et ils n’ont pas besoin de l’approbation des éditeurs d’API. Les éditeurs d’API peuvent également créer des abonnements directement pour les consommateurs d’API.
Notes
Gestion des API prend également en charge d’autres mécanismes de sécurisation de l’accès aux API, notamment OAuth 2.0, les certificats clients et la liste des adresses IP autorisées.
Abonnements et clés
Une clé d’abonnement est une clé unique générée automatiquement qui peut être transmise dans les en-têtes de la requête du client ou sous forme de paramètre de chaîne de requête. La clé est directement liée à un abonnement, qui peut être limité à différentes zones. Les abonnements vous offrent un moyen de contrôle granulaire sur les autorisations et les stratégies.
Les trois étendues principales des abonnements sont :
| Étendue | Détails |
|---|---|
| Toutes les API | S’applique à toutes les API accessibles à partir de la passerelle. |
| API unique | Cette étendue s’applique à une seule API importée et tous ses points de terminaison. |
| Produit | Un produit est une collection contenant une ou plusieurs API que vous configurez dans Gestion des API. Vous pouvez affecter des API à plusieurs produits. Les produits peuvent avoir des règles d’accès, des quotas d’utilisation et des conditions d’utilisation différents. |
Les applications qui appellent une API protégée doivent inclure la clé dans chaque demande.
Vous pouvez regénérer ces clés d’abonnement à tout moment, par exemple si vous pensez qu’une clé a été partagée avec des utilisateurs non autorisés.
Chaque abonnement a deux clés : une clé principale et une clé secondaire. Le fait d’avoir deux clés facilite la regénération d’une clé quand c’est nécessaire. Par exemple, si vous voulez changer la clé principale et éviter les temps d’arrêt, vous pouvez utiliser la clé secondaire dans vos applications.
Pour les produits où des abonnements sont activés, les clients doivent fournir une clé lors des appels aux API de ces produits. Les développeurs peuvent obtenir une clé en envoyant une demande d’abonnement. Si vous approuvez la demande, vous devez leur envoyer la clé d’abonnement de façon sécurisée, par exemple, dans un message chiffré. Cette étape est un élément fondamental du workflow de Gestion des API.
Appeler une API avec la clé d’abonnement
Les applications doivent inclure une clé valide dans toutes les requêtes HTTP quand elles effectuent des appels aux points de terminaison d’API qui sont protégés par un abonnement. Les clés peuvent être passées dans l’en-tête de la demande ou sous la forme d’une chaîne de requête dans l’URL.
Le nom de l’en-tête par défaut est Ocp-Apim-Subscription-Key, et la chaîne de requête par défaut est subscription-key.
Pour tester vos appels d’API, vous pouvez utiliser le portail des développeurs ou des outils en ligne de commande, comme curl. Voici un exemple de requête GET effectuée avec le portail des développeurs, qui montre l’en-tête de la clé d’abonnement :
Voici comment vous pouvez passer une clé dans l’en-tête de la demande avec curl :
curl --header "Ocp-Apim-Subscription-Key: <key string>" https://<apim gateway>.azure-api.net/api/path
Voici un exemple de commande curl qui passe une clé dans l’URL sous la forme d’une chaîne de requête :
curl https://<apim gateway>.azure-api.net/api/path?subscription-key=<key string>
Si la clé n’est pas passée dans l’en-tête ou sous la forme d’une chaîne de requête dans l’URL, vous obtenez une réponse 401 Accès refusé de la passerelle API.