API 키(Apigee에서 고객 키라고 함)는 클라이언트 앱이 API 프록시에 전달하는 문자열 값입니다. 이 키는 클라이언트 앱을 고유하게 식별합니다.
API 키 유효성 검사는 API에 구성할 수 있는 가장 간단한 앱 기반 보안 양식입니다. 클라이언트 앱은 단순히 API 키를 요청과 함께 표시합니다. 그러면 Apigee는 API 상태가 요청 대상 리소스에 승인된 상태인지 확인합니다. 내부적으로 프록시는 정책을 사용하여 API 키 신뢰성을 확인합니다.
이러한 단순성을 지원하려면 약간의 설정이 필요합니다. API 키를 지원하려면 다음을 수행해야 합니다.
API 키를 사용하여 보호할 API 프록시를 번들로 제공하는 Apigee API 제품을 만듭니다.
인증할 앱의 클라이언트 앱 개발자를 나타내는 Apigee 개발자 앱을 만듭니다.
개발자 앱을 만들 때 개발자 앱에서 액세스할 수 있는 API 제품을 지정하고 API 키를 제공해야 합니다.
프록시(API 제품에 포함된 프록시)에 정책을 추가하여 수신 API 키가 유효한지 확인합니다.
API 키를 요구하여 API 보호 튜토리얼에서 API 키를 사용하여 API 프록시에 대한 액세스를 제어하는 방법을 빠르게 알아볼 수 있습니다.
API 키 작동 방식
Apigee에서는 API 키를 고객 키라고 합니다. 개발자 앱을 등록하면 Apigee는 고객 키와 보안 비밀을 생성합니다. Apigee는 향후 유효성 검사를 위해 고객 키를 저장합니다. 각 고객 키는 조직에서 고유합니다. 앱 개발자가 고객 키를 클라이언트 앱에 삽입합니다. 클라이언트 앱은 요청마다 소비자 키를 전달해야 합니다.
API 서비스는 앱 요청을 허용하기 전에 고객 키를 확인합니다.
대략적인 단계
다음 단계에서는 Apigee에서 API 키를 사용하는 방법을 설명합니다. 이러한 단계는 종종 API 키와 함께 사용되므로 OAuth 보안도 표시될 수 있습니다.
API 키로 보호해야 하는 API 프록시가 포함된 API 제품을 만듭니다.
조직에 개발자 앱을 등록합니다. Apigee를 수행하면 고객 키와 고객 보안 비밀번호가 생성됩니다.
개발자 앱을 API 제품 최소 한 개 이상과 연결합니다. 이 제품은 키 승인을 통해 리소스 경로와 API 프록시를 연결하는 제품입니다.
런타임 시 클라이언트 앱에서 API에 요청을 실행하면 클라이언트 앱은 요청을 수행할 때 고객 키를 전송합니다. 실제로 고객 키는 명시적으로 전달되거나 OAuth 토큰을 통해 암시적으로 참조될 수 있습니다.
API가 API 키 확인을 사용하는 경우(예: VerifyAPIKey 정책 구현) 클라이언트 앱은 고객 키를 명시적으로 전달해야 합니다.
API가 OAuth 토큰 확인을 사용하는 경우(예: OAuthV2 정책 구현) 클라이언트 앱이 고객 키에서 파생된 토큰을 전달해야 합니다.
VerifyAccessToken 작업으로 VerifyAPIKey 정책이나 OAuthV2 정책을 통해 API 프록시가 요청 사용자 인증 정보의 유효성을 검사합니다. API 프록시에 사용자 인증 정보 적용 정책을 포함하지 않으면 호출자가 성공적으로 API를 호출할 수 있습니다. 자세한 내용은 API 키 정책 확인을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-18(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."]]
