Google Ads API의 OAuth 2.0 범위는 제한된 범위로 분류되므로 애플리케이션을 프로덕션 환경에 배포하기 전에 OAuth 애플리케이션 확인 절차를 완료해야 합니다. 자세한 내용은 Google ID 문서 및 고객센터 도움말을 참고하세요.
애플리케이션 사용자 인증 정보 보안
애플리케이션의 OAuth 2.0 클라이언트 ID와 클라이언트 보안 비밀번호를 보호해야 합니다. 이러한 사용자 인증 정보는 사용자와 Google이 애플리케이션을 식별하는 데 도움이 되므로 신중하게 처리해야 합니다. 이러한 애플리케이션 사용자 인증 정보는 비밀번호처럼 취급해야 합니다. 공개 포럼에 게시하거나, 이메일 첨부파일에 이러한 사용자 인증 정보가 포함된 구성 파일을 보내거나, 사용자 인증 정보를 하드 코딩하거나, 코드 저장소에 커밋하는 등 보안이 취약한 메커니즘을 사용하여 공유하지 마세요. 가능한 경우 Google Cloud Secret Manager 또는 AWS Secret Manager와 같은 보안 비밀 관리자를 사용하는 것이 좋습니다.
OAuth 2.0 클라이언트 보안 비밀번호가 유출된 경우 재설정할 수 있습니다. 개발자 토큰을 재설정할 수도 있습니다.
개발자 토큰 보안
개발자 토큰을 사용하면 계정에 API를 호출할 수 있지만 호출에 사용할 수 있는 계정에 제한이 없습니다. 따라서 보안이 취약한 개발자 토큰을 다른 사람이 사용하여 내 애플리케이션에 기여한 것으로 표시되는 호출을 할 수 있습니다. 이 시나리오를 방지하려면 다음 예방 조치를 취하세요.
개발자 토큰을 비밀번호처럼 취급하세요. 공개 포럼에 게시하거나 개발자 토큰이 포함된 구성 파일을 이메일 첨부파일로 전송하는 등 보안이 취약한 메커니즘을 사용하여 공유하지 마세요. 가능한 경우 Google Cloud Secret Manager 또는 AWS Secret Manager와 같은 보안 비밀 관리자를 사용하는 것이 좋습니다.
개발자 토큰이 유출된 경우 재설정해야 합니다.
Google Ads API를 신청할 때 사용한 Google Ads 관리자 계정에 로그인합니다.
도구 및 설정 > API 센터로 이동합니다.
개발자 토큰 옆에 있는 드롭다운 화살표를 클릭합니다.
토큰 재설정 링크를 클릭합니다. 이전 개발자 토큰은 즉시 작동이 중지됩니다.
새 개발자 토큰을 사용하도록 애플리케이션의 프로덕션 구성을 업데이트합니다.
서비스 계정 보안
서비스 계정이 Google Ads API와 올바르게 작동하려면 도메인 전체 가장이 필요합니다. 또한 도메인 전체 가장을 설정하려면 Google Workspace 고객이어야 합니다. 이러한 이유로 Google Ads API를 호출할 때는 서비스 계정을 사용하지 않는 것이 좋습니다. 하지만 서비스 계정을 사용하기로 결정한 경우 다음과 같이 보안을 유지해야 합니다.
앱에서 여러 사용자를 승인하는 경우 사용자의 갱신 토큰과 액세스 토큰을 보호하기 위한 추가 단계를 수행해야 합니다. 토큰을 유휴 상태로 안전하게 저장하고 일반 텍스트로 전송하지 마세요. 플랫폼에 적합한 보안 스토리지 시스템을 사용하세요.
갱신 토큰 취소 및 만료 처리
앱이 승인의 일부로 OAuth 2.0 갱신 토큰을 요청하는 경우 무효화 또는 만료도 처리해야 합니다. 갱신 토큰은 다양한 이유로 무효화될 수 있으며, 애플리케이션은 다음 로그인 세션 중에 사용자를 다시 승인하거나 적절하게 데이터를 정리하여 적절하게 대응해야 합니다. 크론 작업과 같은 오프라인 작업은 실패한 요청을 계속 만드는 대신 새로고침 토큰이 만료된 계정을 감지하고 기록해야 합니다. Google은 API 서버의 안정성을 유지하기 위해 지속적인 기간 동안 높은 수준의 오류를 생성하는 애플리케이션을 제한할 수 있습니다.
여러 범위에 대한 동의 관리
앱이 여러 OAuth 2.0 범위에 대한 승인을 요청하는 경우 사용자가 요청된 모든 OAuth 범위를 승인하지 않을 수 있습니다. 앱은 관련 기능을 사용 중지하여 범위 거부를 처리해야 합니다. 범위가 필요한 특정 기능을 사용하려는 의도를 명확하게 표시한 후에만 사용자에게 다시 메시지를 표시할 수 있습니다. 이 경우 증분 승인을 사용하여 적절한 OAuth 범위를 요청하세요.
앱의 기본 기능에 여러 범위가 필요한 경우 동의를 요청하기 전에 사용자에게 이 요구사항을 설명하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-27(UTC)"],[[["\u003cp\u003eThis guide provides instructions for securing your application and user credentials when using the Google Ads API.\u003c/p\u003e\n"],["\u003cp\u003eSecure your application credentials, including OAuth 2.0 client ID and client secret, by treating them like passwords and utilizing secret management tools.\u003c/p\u003e\n"],["\u003cp\u003eProtect your developer token by storing it securely and resetting it if compromised, and consider transitioning to Cloud organizations for access management.\u003c/p\u003e\n"],["\u003cp\u003eSecure user tokens, especially refresh and access tokens, using secure storage and implement mechanisms for handling token revocation and expiration.\u003c/p\u003e\n"],["\u003cp\u003eIf requesting multiple OAuth 2.0 scopes, manage user consent effectively and gracefully handle scope denials by disabling relevant features or using incremental authorization.\u003c/p\u003e\n"]]],[],null,["# Secure your credentials\n\nThis guide shows how to make sure your application and user credentials are\nsecure.\n\nComplete the OAuth App verification\n-----------------------------------\n\nThe OAuth 2.0 scope for the Google Ads API is classified as a\n[restricted scope](/identity/protocols/oauth2/production-readiness/restricted-scope-verification), which means that you should complete the OAuth\napplication verification process before productionizing your application. See\nthe [Google Identity documentation](/identity/protocols/oauth2/production-readiness/restricted-scope-verification) and [Help Center article](//support.google.com/cloud/answer/9110914) to\nlearn more.\n\nSecure the application credentials\n----------------------------------\n\nYou should secure your application's OAuth 2.0 client ID, and client secret.\nThese credentials help your users and Google identify your application and thus\nthey should be handled carefully. You should treat these application credentials\nlike passwords. Don't share them using insecure mechanisms such as posting on\npublic forums, sending configuration files containing these credentials in email\nattachments, hard coding the credentials, or committing them to a code\nrepository. We recommend using a secret manager such as [Google Cloud Secret\nmanager](//cloud.google.com/secret-manager) or [AWS Secret Manager](//aws.amazon.com/secrets-manager/) when possible.\n\nIf your OAuth 2.0 client secrets are compromised, you can [reset them](//support.google.com/cloud/answer/6158849#rotate-client-secret). A\ndeveloper token can also be [reset](/google-ads/api/docs/productionize/secure-credentials#secure_the_developer_token).\n\nSecure the developer token\n--------------------------\n\n| **Note:** Google is accepting early sign-ups for a program that uses Cloud organizations instead of developer tokens to manage access levels. [Learn\n| more](//support.google.com/cloud/answer/6158849#rotate-client-secret).\n\nThe developer token lets you make API calls to an account, but has no\nrestrictions on which accounts it can be used with to make the calls. As a\nresult, a compromised developer token can be used by someone else to make calls\nthat are attributed to your application. To avoid this scenario, take these\npreventive measures:\n\n- Treat your developer token like a password. Don't share it using insecure\n mechanisms such as posting on public forums or sending configuration files\n containing the developer tokens as an email attachment. We recommend using a\n secret manager such as [Google Cloud Secret manager](//cloud.google.com/secret-manager) or [AWS Secret\n Manager](//aws.amazon.com/secrets-manager/) when possible.\n\n- If your developer token is compromised, you should reset it.\n\n - Sign in to the Google Ads manager account that you used when applying for Google Ads API.\n - Navigate to **Tools \\& Settings \\\u003e API Center**.\n - Click the drop-down arrow next to **Developer token**.\n - Click the **Reset token** link. Your old developer token should stop working immediately.\n - Update your application's production configuration to use the new developer token.\n\nSecure the service accounts\n---------------------------\n\nService accounts require domain-wide impersonation to work correctly with the\nGoogle Ads API, In addition, you should be a Google Workspace customer to set up\ndomain-wide impersonation. For these reasons, we recommend against using service\naccounts when making Google Ads API calls. However, if you decide to use service\naccounts, you should secure them as follows:\n\n- Treat your service account key and JSON file as passwords. Secure them using\n a secret manager such as [Google Cloud Secret manager](//cloud.google.com/secret-manager) or [AWS Secret\n Manager](//aws.amazon.com/secrets-manager/) when possible.\n\n- Follow the [additional best practices](//cloud.google.com/iam/docs/best-practices-service-accounts) from Google Cloud to secure\n and manage your service accounts.\n\nSecure the user tokens\n----------------------\n\nIf your app authorizes multiple users, you should take additional steps to\nprotect the users' refresh and access tokens. Store the tokens securely [at\nrest](//wikipedia.org/wiki/Data_at_rest) and never transmit them in plain text. Use a secure storage system\nappropriate for your platform.\n\nHandle refresh token revocation and expiration\n----------------------------------------------\n\nIf your app requests OAuth 2.0 refresh token as part of authorization, you must\nalso handle their invalidation or expiration. Refresh tokens could be\n[invalidated for various reasons](/identity/protocols/oauth2#expiration), and your application should respond\ngracefully either by reauthorizing the user during their next login session, or\ncleaning up their data as appropriate. Offline jobs, such as cron jobs, should\ndetect and record accounts whose refresh tokens have expired, instead of\ncontinuing to make failed requests. Google might throttle applications that\ngenerate high levels of errors over a sustained period of time to maintain the\nstability of the API servers.\n\nManage consent for multiple scopes\n----------------------------------\n\nIf your app requests authorization for multiple OAuth 2.0 scopes, the user might\nnot grant all the OAuth scopes you've requested. Your app should handle the\ndenial of scopes by disabling the relevant features. You can prompt the user\nagain only after they've clearly indicated an intent to use the specific feature\nthat requires the scope. Use [incremental authorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request\nappropriate OAuth scopes in such cases.\n\nIf your app's basic features require multiple scopes, explain this requirement\nto the user before prompting for consent."]]
