Una clave de API (conocida en Apigee como clave de consumidor) es un valor de cadena que una aplicación cliente envía a tus proxies de API. La clave identifica de forma exclusiva la aplicación cliente.
La validación de claves de API es la forma más sencilla de seguridad basada en aplicaciones que puedes configurar para una API. Una aplicación cliente solo tiene que presentar una clave de API con su solicitud. Apigee comprueba que la clave de API tenga un estado aprobado para el recurso solicitado. Internamente, tus proxies usan políticas para verificar la autenticidad de las claves de API.
Para que esto sea posible, tendrás que hacer una pequeña configuración. Para admitir claves de API, debes hacer lo siguiente:
Crea un producto de API de Apigee que incluya los proxies de API que quieras proteger con la clave de API.
Crea una aplicación de desarrollador de Apigee que represente al desarrollador de la aplicación cliente
cuya aplicación vas a autenticar.
Al crear la aplicación de desarrollador, especifica los productos de API a los que tendrá acceso la aplicación del desarrollador y para los que deberá proporcionar una clave de API.
A tus proxies (los que has incluido en tu producto de API), añade políticas
para verificar que una clave de API entrante sea válida.
En Apigee, una clave de API se denomina clave de consumidor. Cuando registras aplicaciones de desarrollador, Apigee genera una clave y un secreto de consumidor. Apigee almacena la clave de consumidor para futuras validaciones. Cada clave de consumidor es única en la organización. El desarrollador de la aplicación inserta la clave de consumidor en la aplicación cliente. La aplicación cliente debe presentar la clave de consumidor en cada solicitud.
Los servicios de la API verifican la clave de consumidor antes de permitir la solicitud de la aplicación.
Pasos generales
En los siguientes pasos se describe cómo usa Apigee las claves de API. Estos pasos incluyen la posible presencia de seguridad OAuth, ya que a menudo se usa junto con las claves de API.
Crea un producto de API que incluya los proxies de API que deban protegerse con la clave de API.
Registras una aplicación de desarrollador en tu organización. Cuando lo haces, Apigee genera una clave de consumidor y un secreto de consumidor.
Asocia la aplicación de desarrollador con al menos un producto de API. Es el producto que asocia las rutas de recursos y los proxies de API con la aprobación de claves.
En el tiempo de ejecución, cuando la aplicación cliente hace una solicitud a tu API, la aplicación cliente envía la clave de consumidor al hacer la solicitud. En la práctica, la clave de consumidor se puede
transferir explícitamente o se puede hacer referencia a ella de forma implícita mediante un token de OAuth:
Cuando la API usa la verificación de claves de API (por ejemplo, implementando una política VerifyAPIKey), la aplicación cliente debe transferir la clave de consumidor de forma explícita.
Cuando la API usa la verificación de tokens de OAuth (por ejemplo, implementando una política OAuthV2), la aplicación cliente debe enviar un token que se haya derivado de la clave de consumidor.
El proxy de API valida las credenciales de la solicitud mediante una política VerifyAPIKey o una política OAuthV2 con una operación VerifyAccessToken. Si no incluyes una política de aplicación de credenciales en tu proxy de API, cualquier persona que llame podrá invocar tus APIs correctamente. Para obtener más información, consulta la política Verificar clave de API.
Si usas la verificación de tokens OAuth y has implementado una política de OAuth para verificar que la aplicación cliente ha enviado un token OAuth:
Apigee verifica que el token no haya caducado y, a continuación, busca la clave de consumidor que se usó para generar el token.
Si usas una clave de API, has implementado una política VerifyAPIKey y la aplicación cliente ha enviado su clave de consumidor:
Apigee comprueba la lista de productos de API con los que se ha asociado la clave de consumidor.
Apigee comprueba cada producto de API para ver si el proxy de API actual está incluido en el producto de API y si la ruta de recurso actual (ruta de URL) está habilitada en el producto de API.
Apigee también verifica que la clave de consumidor no haya caducado ni se haya revocado, comprueba que la aplicación no se haya revocado y comprueba que el desarrollador no esté inactivo.
Si se cumplen todas estas condiciones (el token no ha caducado, si procede, la clave de consumidor es válida y está aprobada, la aplicación está aprobada, el desarrollador está activo, el proxy está disponible en el producto y el recurso está disponible en el producto), la verificación de las credenciales se realiza correctamente.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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."]]
