이 페이지에서는 API 키와 인증의 사용 방법 및 차이점, API 키 사용을 고려해야 할 시나리오를 비롯하여 API 키와 인증에 대한 배경 정보를 제공합니다.
API 키는 프로젝트용, 인증은 사용자용
Cloud Endpoints는 API 키와 인증 체계(Firebase 또는 Auth0)를 모두 처리합니다. 다음은 API 키와 인증의 주된 차이점입니다.
API 키는 호출하는 프로젝트, 즉 API를 호출하는 앱이나 사이트를 식별합니다.
인증 토큰은 사용자, 즉 앱이나 사이트를 사용하고 있는 사람을 식별합니다.
API 키는 프로젝트 승인 제공
가장 적절한 체계를 결정하려면 API 키와 인증에서 무엇을 제공하는지 이해하는 것이 중요합니다.
API 키는 다음을 제공합니다.
프로젝트 식별 — API를 호출하는 애플리케이션이나 프로젝트를 식별합니다.
프로젝트 승인 — 호출하는 애플리케이션에 API를 호출하는 액세스 권한이 부여되었고 프로젝트에서 API가 사용 설정되었는지 여부를 확인합니다.
API 키는 인증 토큰만큼 안전하지 않지만(API 키의 보안 참조), API를 호출하는 애플리케이션이나 프로젝트를 식별합니다. 이러한 키는 호출을 수행하는 프로젝트에서 생성되며 특정 IP 주소 범위, Android 앱, iOS 앱과 같은 환경에서 키 사용을 제한할 수 있습니다.
호출하는 프로젝트를 식별하면 API 키를 사용하여 사용 정보를 해당 프로젝트와 연결할 수 있습니다. Extensible Service Proxy(ESP)는 API 키를 사용하여 액세스 권한을 부여받지 못했거나 API에서 사용 설정되지 않은 프로젝트의 호출을 거부할 수 있습니다.
사용자 인증
이와 달리 인증 체계는 일반적으로 다음 2가지 목적에 사용됩니다.
사용자 인증 - 호출하는 사용자의 신원을 안전하게 확인합니다.
사용자 승인 - 사용자에게 이 요청을 위한 액세스 권한이 필요한지 여부를 확인합니다.
인증 체계는 호출하는 사용자를 식별하는 안전한 방법을 제공합니다.
또한 Endpoints는 인증 토큰에 API를 호출할 수 있는 권한이 있는지 확인합니다. 이 인증 내용을 토대로 API 서버는 요청 승인을 결정합니다.
API 키는 호출하는 프로젝트를 식별하지만 호출하는 사용자는 식별하지 않습니다. 예를 들어 API를 호출하는 애플리케이션을 만든 경우 API 키는 호출하는 애플리케이션을 식별하지만 애플리케이션 사용자는 식별하지 못합니다.
API를 호출할 수 있는 프로젝트나 서비스를 보다 안전하게 제한하는 방법이 필요한 경우 서비스 간 인증을 참조하세요.
API 키의 보안
API 키는 일반적으로 안전하다고 간주되지 않습니다. 대개 클라이언트가 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-09-04(UTC)"],[[["\u003cp\u003eAPI keys identify the calling project or application, not individual users, enabling project identification and authorization for API access.\u003c/p\u003e\n"],["\u003cp\u003eAuthentication tokens identify the user making a request, offering user authentication and authorization, which is a different functionality compared to API keys.\u003c/p\u003e\n"],["\u003cp\u003eAPI keys are less secure than authentication tokens because they are easily accessible to clients, and once stolen, they can be used indefinitely until revoked.\u003c/p\u003e\n"],["\u003cp\u003eAPI keys are useful for blocking anonymous traffic, controlling the number of API calls, identifying usage patterns, and filtering logs by project, but they are not meant for secure authorization.\u003c/p\u003e\n"],["\u003cp\u003eWhile API keys enable project identification and authorization for API access, they cannot be used to identify individual users, provide secure authorization, or identify the creators of a project.\u003c/p\u003e\n"]]],[],null,["# Why and when to use API keys\n\nOpenAPI \\| [gRPC](/endpoints/docs/grpc/when-why-api-key \"View this page for the Cloud Endpoints gRPC docs\")\n\n\u003cbr /\u003e\n\nThis page provides background information on API keys and authentication: how\neach of these are used, the differences between them, and the scenarios where\nyou should consider using API keys.\n\nAPI keys are for projects, authentication is for users\n------------------------------------------------------\n\nCloud Endpoints handles both API keys and authentication schemes, such as\nFirebase or Auth0. The main distinction between these two is:\n\n- API keys identify the calling project --- the application or site --- making\n the call to an API.\n\n- Authentication tokens identify a user --- the person --- that is using the app\n or site.\n\n\nAPI keys provide project authorization\n--------------------------------------\n\nTo decide which scheme is most appropriate, it's important to understand\nwhat API keys and authentication can provide.\n\nAPI keys provide\n\n- **Project identification** --- Identify the application or the project\n that's making a call to this API\n\n- **Project authorization** --- Check whether the calling application has been granted\n access to call the API and has enabled the API in their project\n\nAPI keys aren't as secure as authentication tokens (see\n[Security of API keys](#security_of_api_keys)),\nbut they identify the application or project that's calling an API. They are\ngenerated on the project making the call, and you can restrict their use to an\nenvironment such as an IP address range, or an Android or iOS app.\nBy identifying the calling project, you can use API keys to associate usage information with that project. API keys allow the [Extensible Service Proxy (ESP)](/endpoints/docs/openapi/glossary#extensible_service_proxy) to reject calls from projects that haven't been granted access or enabled in the API.\n\nAuthentication of users\n-----------------------\n\nBy contrast, authentication schemes typically serve two purposes:\n\n- **User authentication** --- Securely verify that the calling user is who\n they claim to be.\n\n- **User authorization** --- Check whether the user should have access to\n make this request.\n\nAuthentication schemes provide a secure way of identifying the calling user.\nEndpoints also checks the authentication token to verify that it\nhas permission to call an API. Based on that authentication, the API server\ndecides on authorizing a request.\n\nIf you need the ability to identify the user making the call, see\n[Authenticating users](/endpoints/docs/openapi/authenticating-users).\n\nWhile API keys identify the calling project, they don't identify the\ncalling user. For instance, if you have created an application that is calling\nan API, an API key can identify the application that is making the call, but not\nthe identity of the person who is using the application.\n\nIf you need a more secure way to limit which projects or services can call your\nAPI, see\n[Authentication between services](/endpoints/docs/openapi/service-account-authentication).\n\nSecurity of API keys\n--------------------\n\nAPI keys are generally not considered secure; they are typically accessible to\nclients, making it easy for someone to steal an API key. Once the key is stolen,\nit has no expiration, so it may be used indefinitely, unless\nthe project owner revokes or regenerates the key. While the restrictions you can\nset on an API key mitigate this, there are better approaches for\nauthorization.\n\nFor examples, see\n[Authenticating users](/endpoints/docs/openapi/authenticating-users).\n\nWhen to use API keys\n--------------------\n\nAn API may restrict some or all of its methods to require API keys. It makes\nsense to do this if:\n\n- You do want to block anonymous traffic. API keys identify an application's\n traffic for the API producer, in case the application developer needs to\n work with the API producer to debug an issue or show their application's\n usage.\n\n- You want to control the number of calls made to your API.\n\n- You want to identify usage patterns in your API's traffic. You can see\n application usage in\n [APIs \\& services](http://console.developers.google.com).\n\n- You want to filter logs by API key.\n\nAPI keys cannot be used for:\n\n- Identifying individual users --- API keys don't identify users, they\n identify projects.\n\n- Secure authorization.\n\n- Identifying the creators of a project.\n\n[Service Infrastructure](/service-infrastructure/docs/overview)\ndoesn't provide a method to directly look up projects from API keys.\n\nHow to use API keys\n-------------------\n\nTo learn how to set up and use API key access, see [Restricting access with API keys](/endpoints/docs/openapi/restricting-api-access-with-api-keys)."]]
