권장사항
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 페이지에서는 OAuth 2.0과 통합하기 위한 몇 가지 일반적인 권장사항을 다룹니다. 애플리케이션 유형 및 개발 플랫폼에 관한 특정 안내 외에도 다음 권장사항을 고려하세요. 프로덕션용 앱 준비에 관한 조언 및 Google의 OAuth 2.0 정책도 참고하세요.
클라이언트 사용자 인증 정보를 안전하게 처리
OAuth 클라이언트 사용자 인증 정보는 앱의 ID를 식별하며 신중하게 처리해야 합니다. 이러한 사용자 인증 정보는 Google Cloud Secret Manager와 같은 보안 비밀 관리자를 사용하여 보안 스토리지에만 저장하세요.
사용자 인증 정보를 하드 코딩하거나 코드 저장소에 커밋하거나 공개적으로 게시하지 마세요.
사용자 토큰을 안전하게 처리
사용자 토큰에는 애플리케이션에서 사용하는 갱신 토큰과 액세스 토큰이 모두 포함됩니다. 토큰을 유휴 상태로 안전하게 저장하고 일반 텍스트로 전송하지 마세요. Android의 Keystore, iOS 및 macOS의 키체인 서비스, Windows의 사용자 인증 정보 보관함과 같이 플랫폼에 적합한 보안 저장소 시스템을 사용하세요.
더 이상 필요하지 않은 토큰은 즉시 취소하고 시스템에서 영구적으로 삭제합니다.
또한 플랫폼에 관한 다음 권장사항도 고려하세요.
갱신 토큰 취소 및 만료 처리
앱이 오프라인 액세스를 위한 갱신 토큰을 요청한 경우 무효화 또는 만료도 처리해야 합니다. 토큰은 만료되었거나 사용자 또는 자동 프로세스에 의해 앱의 액세스가 취소되는 등 다양한 이유로 무효화될 수 있습니다. 이 경우 다음 로그인 시 사용자에게 메시지를 표시하거나 데이터를 정리하는 등 애플리케이션이 어떻게 응답해야 하는지 신중하게 고려하세요. 토큰 폐기에 관한 알림을 받으려면 계정 간 보안 서비스와 통합하세요.
점진적 승인 사용
점진적 승인을 사용하여 애플리케이션에 기능이 필요할 때 적절한 OAuth 범위를 요청합니다.
앱의 핵심 기능에 필수적이지 않은 경우 사용자가 처음 인증할 때 데이터 액세스를 요청해서는 안 됩니다. 대신 가능한 가장 작고 제한된 범위를 선택한다는 원칙에 따라 작업에 필요한 특정 범위만 요청하세요.
사용자가 앱에서 액세스를 요청하는 이유와 데이터가 사용되는 방식을 이해할 수 있도록 항상 관련 맥락 안에서 범위를 요청하세요.
예를 들어 애플리케이션이 다음 모델을 따를 수 있습니다.
- 사용자가 앱으로 인증합니다.
- 추가 범위가 요청되지 않습니다. 앱은 사용자가 추가 데이터나 액세스가 필요하지 않은 기능을 탐색하고 사용할 수 있는 기본 기능을 제공합니다.
- 사용자가 추가 데이터에 대한 액세스가 필요한 기능을 선택합니다.
- 애플리케이션이 이 기능에 필요한 특정 OAuth 범위에 대한 승인 요청을 합니다. 이 기능에 여러 범위가 필요한 경우 아래 권장사항을 따르세요.
- 사용자가 요청을 거부하면 앱은 기능을 사용 중지하고 사용자에게 액세스를 다시 요청할 수 있는 추가 컨텍스트를 제공합니다.
여러 범위에 대한 동의 처리
한 번에 여러 범위를 요청하는 경우 사용자가 요청한 모든 OAuth 범위를 부여하지 않을 수 있습니다. 앱은 관련 기능을 사용 중지하여 범위 거부를 처리해야 합니다.
앱의 기본 기능에 여러 범위가 필요한 경우 동의를 요청하기 전에 사용자에게 이를 설명하세요.
범위가 필요한 특정 기능을 사용하겠다는 의사를 명확하게 표시한 후에만 사용자에게 다시 메시지를 표시할 수 있습니다. 앱은 OAuth 범위를 요청하기 전에 사용자에게 관련 컨텍스트와 근거를 제공해야 합니다.
앱이 한 번에 요청하는 범위의 수를 최소화해야 합니다. 대신 증분 승인을 활용하여 기능 및 기능의 컨텍스트에서 범위를 요청하세요.
보안 브라우저 사용
웹에서 OAuth 2.0 승인 요청은 모든 기능을 갖춘 웹브라우저에서만 이루어져야 합니다.
다른 플랫폼에서는 올바른 OAuth 클라이언트 유형을 선택하고 플랫폼에 적합한 방식으로 OAuth를 통합해야 합니다. Android의 WebView 또는 iOS의 WKWebView와 같은 모바일 플랫폼의 WebView를 비롯한 삽입된 탐색 환경을 통해 요청을 리디렉션하지 마세요. 대신 플랫폼에 네이티브 OAuth 라이브러리 또는 Google 로그인을 사용하세요.
OAuth 클라이언트의 수동 생성 및 구성
악용을 방지하기 위해 OAuth 클라이언트는 프로그래매틱 방식으로 만들거나 수정할 수 없습니다. Google 개발자 콘솔을 사용하여 서비스 약관을 명시적으로 확인하고 OAuth 클라이언트를 구성하고 OAuth 인증을 준비해야 합니다.
자동화된 워크플로의 경우 서비스 계정을 대신 사용하는 것이 좋습니다.
사용하지 않는 OAuth 클라이언트 삭제
OAuth 2.0 클라이언트를 정기적으로 감사하고 애플리케이션에 더 이상 필요하지 않거나 오래된 클라이언트를 선제적으로 삭제하세요. 사용하지 않는 클라이언트를 구성된 상태로 두면 클라이언트 사용자 인증 정보가 유출될 경우 클라이언트가 오용될 수 있으므로 잠재적인 보안 위험이 발생합니다.
사용하지 않는 클라이언트의 위험을 더욱 완화하기 위해 6개월 동안 비활성 상태였던 OAuth 2.0 클라이언트는
자동으로 삭제됩니다.
자동 삭제를 기다리지 말고 사용하지 않는 클라이언트를 선제적으로 삭제하는 것이 좋습니다. 이 방법을 사용하면 애플리케이션의 공격 표면이 최소화되고 보안 관리가 효과적으로 이루어집니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-08-31(UTC)
[null,null,["최종 업데이트: 2025-08-31(UTC)"],[[["\u003cp\u003eSecurely store and manage OAuth client credentials, avoiding hardcoding or public exposure.\u003c/p\u003e\n"],["\u003cp\u003eProtect user tokens (refresh and access) by storing them securely and revoking them when no longer needed.\u003c/p\u003e\n"],["\u003cp\u003eImplement proper handling of refresh token revocation and expiration scenarios, including user notification and data cleanup.\u003c/p\u003e\n"],["\u003cp\u003eUtilize incremental authorization to request only necessary OAuth scopes in context, minimizing initial requests and enhancing user privacy.\u003c/p\u003e\n"],["\u003cp\u003eEmploy secure browsing environments for OAuth authorization requests, avoiding embedded browsers like webviews and opting for native libraries or Google Sign-in.\u003c/p\u003e\n"]]],[],null,["This page covers some general best practices for integrating with OAuth 2.0. Consider these best\npractices in addition to any specific guidance for your type of application and development\nplatform. Also refer to the\n[advice for getting\nyour app ready for production](/identity/protocols/oauth2/production-readiness/policy-compliance) and [Google's\nOAuth 2.0 policies](/identity/protocols/oauth2/policies).\n\nHandle client credentials securely\n\n\nThe OAuth client credentials identify your app's identity and should be handled carefully. Only\nstore these credentials in secure storage, for example using a secret manager such as\n[Google Cloud Secret Manager](https://cloud.google.com/secret-manager/docs/overview).\nDo not hardcode the credentials, commit them to a code repository or publish them publicly.\n\nHandle user tokens securely\n\n\nUser tokens include both refresh tokens and access tokens used by your application. Store\ntokens securely [at rest](https://wikipedia.org/wiki/Data_at_rest)\nand never transmit them in plain text. Use a secure storage system appropriate for your\nplatform, such as\n[Keystore](https://developer.android.com/training/articles/keystore) on Android,\nKeychain Services on iOS and macOS, or Credential Locker on Windows.\n\n\n[Revoke tokens](/identity/protocols/oauth2/web-server#tokenrevoke) as soon as they\nare no longer needed and delete them permanently from your systems.\n\n\nIn addition, also consider these best practices for your platform:\n\n- For [server-side](/identity/protocols/oauth2/web-server) applications that store tokens for many users, encrypt them at rest and ensure that your data store is not publicly accessible to the Internet.\n- For native desktop apps, using the [Proof Key for Code\n Exchange (PKCE) protocol](/identity/protocols/oauth2/native-app#obtainingaccesstokens) is strongly recommended to obtain authorization codes that can be exchanged for access tokens.\n\nHandle refresh token revocation and expiration\n\n\nIf your app has requested a [refresh\ntoken for offline access](/identity/protocols/oauth2/web-server#offline), you must also handle their invalidation or expiration. Tokens\ncould be [invalidated for different reasons](/identity/protocols/oauth2#expiration),\nfor example it could have expired or your apps' access could have been revoked by the user or\nan automated process. In this case, consider carefully how your application should respond,\nincluding prompting the user at their next log in or cleaning up their data. To be notified of\ntoken revocation, integrate with the [Cross-Account\nProtection](/identity/protocols/risc) service.\n\nUse incremental authorization\n\n\nUse [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request appropriate OAuth scopes when the functionality is needed by your\napplication.\n\n\nYou should not request access to data when the user first authenticates, unless it is essential\nfor the core functionality of your app. Instead, request only the specific scopes that are\nneeded for a task, following the principle to\n[select the smallest, most limited scopes possible](/identity/protocols/oauth2/production-readiness/policy-compliance#only-request-needed-scopes).\n\n\nAlways request scopes in context to help your users understand why your app is requesting access\nand how the data will be used.\n\n\nFor example, your application may follow this model:\n\n1. The user authenticates with your app\n 1. No additional scopes are requested. The app provides basic functionality to let the user explore and use features that do not require any additional data or access.\n2. The user selects a feature that requires access to additional data\n 1. Your application makes an authorization request for this specific OAuth scope required for this feature. If this feature requires multiple scopes, follow [the best practices below](#multiple-scopes).\n 2. If the user denies the request, the app disables the feature and gives the user additional context to request access again.\n\nHandle consent for multiple scopes\n\n\nWhen requesting multiple scopes at once, users may not grant all OAuth scopes you have\nrequested. Your app should handle the denial of scopes by disabling relevant functionality.\n\n\nIf your app's basic functionality requires multiple scopes, explain this to the user before\nprompting for consent.\n\n\nYou may only prompt the user again once they have clearly indicated an intent to use the\nspecific feature that requires the scope. Your app should provide the user with relevant context\nand justification before requesting OAuth scopes.\n\n\nYou should minimize the number of scopes your app requests at once. Instead,\n[utilize incremental authorization](#use-incremental-authorization) to request scopes\nin context of features and functionality.\n\nUse secure browsers\n\n\nOn the web, OAuth 2.0 authorization requests must only be made from full-featured web browsers.\nOn other platforms, make sure to select the\n[correct OAuth client type](/identity/protocols/oauth2#basicsteps) and integrate\nOAuth as appropriate for your platform. Do not redirect the request through embedded browsing\nenvironments, including webviews on mobile platforms, such as WebView on Android or WKWebView on\niOS. Instead, utilize [native OAuth libraries](/identity/protocols/oauth2/native-app)\nor [Google Sign-in](/identity/authorization) for your platform.\n\nManual creation and configuration of OAuth clients\n\n\nIn order to prevent abuse, OAuth clients cannot be created or modified programmatically. You\nmust use the Google Developers console to explicitly acknowledge the terms of service, configure\nyour OAuth client and prepare for OAuth verification.\n\n\nFor automated workflows, consider using\n[service accounts](/identity/protocols/oauth2/service-account) instead.\n\nRemove unused OAuth clients\n\n\nRegularly audit your OAuth 2.0 clients and proactively delete any that are no longer required by\nyour application or have become obsolete. Leaving unused clients configured represents a\npotential security risk as the client can be misused if your client credentials are ever\ncompromised.\n\n\nTo further mitigate risks from unused clients, OAuth 2.0 clients that have been inactive for six\nmonths are [automatically deleted](https://support.google.com/cloud/answer/15549257#unused-client-deletion).\n\n\nThe recommended best practice is to not wait for automatic deletion but rather proactively\nremove unused clients. This practice minimizes your application's attack surface and ensures\ngood security hygiene."]]
