Une clé API (connue dans Apigee sous l'appellation clé client) est une valeur de chaîne transmise par une application cliente à vos proxys d'API. La clé identifie l'application cliente de manière unique.
La validation par clé API est la forme de sécurité la plus simple que vous pouvez configurer pour une API. Une application cliente présente simplement une clé API avec sa requête, puis Apigee vérifie que la clé API est dans un état approuvé pour la ressource demandée. En interne, vos proxys utilisent des règles pour vérifier l'authenticité des clés API.
Pour vous faciliter la tâche, vous devez effectuer une petite configuration. Pour assurer la compatibilité avec les clés API, vous devez :
Créer un produit d'API Apigee qui regroupe les proxys d'API que vous souhaitez protéger à l'aide de la clé API.
Créer une application de développeur Apigee qui représente le développeur de l'application cliente à laquelle vous allez vous authentifier.
Lors de la création de l'application de développeur, vous spécifiez les produits d'API auxquels l'application du développeur aura accès, et pour lesquels il devra fournir une clé API.
Ajoutez des règles à vos proxys (ceux que vous avez inclus dans votre produit d'API) pour vérifier qu'une clé API entrante est valide.
Dans Apigee, une clé API est appelée clé client. Lorsque vous enregistrez des applications de développeur, Apigee génère une clé et un secret client. Apigee stocke la clé client pour une validation ultérieure. Chaque clé client est unique dans l'organisation. Le développeur de l'application intègre la clé client dans l'application cliente. L'application cliente doit présenter la clé client pour chaque requête.
Les services d'API vérifient la clé client avant d'autoriser la requête de l'application.
Étapes majeures
Les étapes suivantes décrivent comment les clés API sont utilisées par Apigee. Ces étapes incluent également la présence possible de la sécurité OAuth, car elle est souvent utilisée conjointement avec des clés API.
Créez un produit d'API qui inclut des proxys d'API devant être protégés par la clé API.
Vous enregistrez une application de développeur dans votre organisation. Lorsque vous effectuez cette opération, Apigee génère une clé et un code secret client.
Associez l'application de développeur à au moins un produit d'API. C'est le produit qui associe les chemins de ressources et les proxys d'API avec l'approbation des clés.
Au moment de l'exécution, lorsque l'application cliente envoie une requête à l'API, l'application cliente envoie la clé client lors de l'envoi de la requête. En pratique, la clé client peut être soit explicitement transmise, soit implicitement appelée via un jeton OAuth :
Lorsque l'API utilise la vérification de clé API, par exemple en mettant en œuvre une règle VerifyAPIKey, l'application cliente doit transmettre explicitement la clé client.
Lorsque l'API utilise la vérification du jeton OAuth (par exemple, en mettant en œuvre une règle OAuthV2), l'application cliente doit transmettre un jeton dérivé de la clé client.
Le proxy d'API valide les identifiants de la requête via une règle VerifyAPIKey ou une règle OAuthV2 avec une opération VerifyAccessToken. Si vous n'incluez pas de règle d'application des identifiants dans votre proxy d'API, n'importe quel appelant peut appeler vos API. Pour en savoir plus, consultez la page Vérifier la règle de clé API.
Vérifier les identifiants de la requête
Il s'agit ici d'une présentation. Veillez à consulter la section Configurer la validation de la clé API pour obtenir plus de détails et des exemples de code.
Si vous utilisez la vérification de jetons OAuth, vous avez mis en œuvre une règle OAuth pour vérifier que l'application cliente a transmis un jeton OAuth :
Apigee vérifie que le jeton n'est pas arrivé à expiration, puis recherche la clé client ayant été utilisée pour générer le jeton.
Si vous utilisez une clé API, vous avez mis en œuvre une règle VerifyAPIKey et l'application cliente a transmis sa clé client :
Apigee vérifie la liste des produits d'API auxquels la clé client a été associée.
Apigee vérifie chaque produit d'API pour déterminer si le proxy d'API actuel est inclus dans le produit d'API et si le chemin d'accès à la ressource actuel (chemin de l'URL) est activé sur le produit d'API.
Apigee vérifie également que la clé client n'est pas arrivée à expiration ou révoquée, que l'application n'est pas révoquée et que le développeur n'est pas inactif.
Si toutes ces conditions sont remplies -- le jeton n'est pas arrivé à expiration (le cas échéant), la clé client est valide et approuvée, l'application est approuvée, le développeur est actif et le proxy est disponible dans le produit, et la ressource est disponible sur le produit -- la vérification des identifiants réussit.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[[["\u003cp\u003eAPI keys, also known as consumer keys, uniquely identify client apps in Apigee and are used for a simple form of app-based security.\u003c/p\u003e\n"],["\u003cp\u003eTo implement API key validation, you must create an API product bundling the desired API proxies and a developer app representing the client app to be authenticated.\u003c/p\u003e\n"],["\u003cp\u003eClient apps present the API key with each request, and Apigee proxies utilize policies to verify the key's authenticity and approved status.\u003c/p\u003e\n"],["\u003cp\u003eAt runtime, requests from client apps include the consumer key, either directly or via an OAuth token derived from the consumer key, which is then validated by the API Proxy.\u003c/p\u003e\n"],["\u003cp\u003eApigee verifies that the API key is associated with an appropriate API Product, not expired or revoked, and that the corresponding app and developer are active, as well as that the requested resource is available.\u003c/p\u003e\n"]]],[],null,["# API keys\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAn *API key* (known in Apigee as a *consumer key*) is a string value passed\nby a client app to your API proxies. The key uniquely identifies the client app.\n\nAPI key validation is the simplest form of app-based security that you can configure for an\nAPI. A client app simply presents an API key with its request, then Apigee checks to see\nthat the API key is in an approved state for the resource being requested. Internally, your\nproxies use policies to verify API key authenticity.\n\nTo support this simplicity, you'll need to do a bit of setup. To support API keys, you'll need\nto:\n\n- **Create an Apigee API product** that bundles the API proxies you want to protect using the API key.\n- **Create an Apigee developer app** that represents the client app developer whose app you'll be authenticating.\n\n In creating the developer app, you specify API products the developer's app will have\n access to -- and for which it will need to provide an API key.\n- To your proxies (the ones you included in your API product), **add policies** to verify that an incoming API key is valid.\n\nThe [Secure an API by\nrequiring API keys](/apigee/docs/api-platform/tutorials/secure-calls-your-api-through-api-key-validation) tutorial is a quick way to learn how to control access to an API proxy\nwith an API key.\n| **Note:** The security associated with API keys is limited. Because API keys can easily be extracted from app code and used to access an API, they work better as unique app identifiers, rather than security tokens. If you're looking for a way to implement security, be sure to see [OAuth home](/apigee/docs/api-platform/security/oauth/oauth-home).\n| **Note:** API keys go by many names. You may see them referred to as app keys, developer app keys, consumer keys, or client IDs.\n| **Sample:** A working sample API proxy that enforces API key validation is available in the [API Platform\n| Samples](https://github.com/apigee/api-platform-samples) available on GitHub. You can use the sample API proxy to secure your own API. Locate the API proxy found under `/sample-proxies/apikey`. Modify the TargetEndpoint configuration to point to your URL. Then deploy.\n\nHow API keys work\n-----------------\n\nIn Apigee, an API key is referred to as a consumer key. When you register developer apps,\nApigee generates a consumer key and secret. Apigee stores the consumer key for future\nvalidation. Each consumer key is unique in the organization. The app developer embeds the\nconsumer key in the client app. The client app must present the consumer key for each request.\nAPI Services verifies the consumer key before permitting the app's request.\n\n### High-level steps\n\nThe following steps describe how API keys are used by Apigee. These steps include the\npossible presence of OAuth security as well, since it is often used in conjunction with API\nkeys.\n\n1. **Create an API product** that includes API proxies that should be protected with the API key.\n2. You **register a developer app** in your organization. When you do Apigee generates a consumer key and a consumer secret.\n3. **Associate the developer app with at least one API product**. It is the product that associates resource paths and API proxies with key approval.\n4. At run time, when the client app makes a request to your API, the **client app sends\n the consumer key when making the request** . In practice, the consumer key might be either passed explicitly or it might be implicitly referred to via an OAuth token:\n - When the API uses API key verification -- such as by implementing a VerifyAPIKey policy -- the client app must pass the consumer key explicitly.\n - When the API uses OAuth token verification -- such as by implementing an OAuthV2 policy -- the client app must pass a token that has been *derived from* the consumer key.\n5. The **API Proxy validates the request** credentials through either a VerifyAPIKey policy or an OAuthV2 policy with a VerifyAccessToken operation. If you do not include a credential enforcement policy in your API Proxy, any caller can successfully invoke your APIs. For more information, see [Verify API Key\n policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy).\n\n### Verifying request credentials\n\nThis is an overview. Be sure to see\n[Setting up API key\nvalidation](/apigee/docs/api-platform/security/setting-api-key-validation) for\ndetails and code examples.\n\n1. If you're using OAuth token verification -- you've implemented an OAuth policy to verify and the client app has passed an OAuth token:\n - Apigee verifies that the token is not expired, and then looks up the consumer key that was used to generate the token.\n2. If you're using an API key -- you've implemented a VerifyAPIKey policy and the client app has passed its consumer key:\n 1. Apigee checks the list of API Products with which the consumer key has been associated.\n 2. Apigee checks each API Product to see if the current API Proxy is included in the API Product, and if the current resource path (url path) is enabled on the API Product.\n 3. Apigee also verifies that the consumer key is not expired or revoked, checks that the app is not revoked, and checks that the developer is not inactive.\n 4. If all of those things are true -- the token is not expired (if applicable), the consumer key is valid and approved, the app is approved, the developer is active, the proxy is available in the product, and the resource is available on the product -- the credential verification succeeds."]]