OAuth 2.0 정책 준수

이 가이드에서는 앱을 프로덕션 환경에 준비할 때 발생하는 가장 일반적인 개발자 문제를 해결하는 방법을 설명합니다.

개요

구현된 솔루션을 개발 환경에서 앱 사용자로 배포할 준비가 되면 Google의 OAuth 2.0 정책을 준수하기 위해 추가 단계를 거쳐야 할 수 있습니다. 이 가이드에서는 앱을 프로덕션 환경에 준비할 때 발생하는 가장 일반적인 개발자 문제를 해결하는 방법을 설명합니다. 이를 통해 오류를 최소화하면서 최대한 많은 잠재고객에게 도달할 수 있습니다.


테스트 및 프로덕션에 별도의 프로젝트 사용

Google의 OAuth 정책에서는 테스트 및 프로덕션에 별도의 프로젝트를 사용해야 합니다. 일부 정책 및 요구사항은 프로덕션 앱에만 적용됩니다. 모든 Google 계정에서 사용할 수 있는 앱의 프로덕션 버전에 해당하는 OAuth 클라이언트를 포함하는 별도의 프로젝트를 만들고 구성해야 할 수 있습니다.

프로덕션에 사용되는 Google OAuth 클라이언트는 동일한 애플리케이션을 테스트하거나 디버그하는 유사한 OAuth 클라이언트보다 더 안정적이고 예측 가능하며 안전한 데이터 수집 및 저장 환경을 제공하는 데 도움이 됩니다. 프로덕션 프로젝트는 인증을 위해 제출할 수 있으므로 서드 파티 보안 평가를 포함할 수 있는 특정 API 범위에 대한 추가 요구사항이 적용될 수 있습니다.

  1. Google API 콘솔로 이동합니다. 프로젝트 만들기 를 클릭하고 이름을 입력한 다음 만들기 를 클릭합니다.
  2. 테스트 등급과 연결될 수 있는 이 프로젝트의 OAuth 클라이언트를 검토합니다. 해당하는 경우 프로덕션 프로젝트 내에서 프로덕션 클라이언트를 위한 유사한 OAuth 클라이언트를 만듭니다.
  3. 클라이언트에서 사용 중인 API를 사용 설정합니다.
  4. Cloud Console의 브랜딩 페이지에서 새 프로젝트의 OAuth 동의 화면 구성을 검토합니다.

프로덕션에 사용되는 Google OAuth 클라이언트에는 개발자 또는 개발팀만 사용할 수 있는 테스트 환경, 리디렉션 URI 또는 자바스크립트 출처가 포함되어서는 안 됩니다. 다음은 몇 가지 예시입니다.

  • 개별 개발자의 테스트 서버
  • 앱의 테스트 또는 출시 전 버전

프로젝트 관련 연락처 목록 유지

Google 및 사용 설정한 개별 API는 서비스 변경사항 또는 프로젝트 및 클라이언트에 필요한 새로운 구성에 관해 개발자에게 문의해야 할 수 있습니다. 프로젝트의 IAM 등록정보를 검토하여 팀의 관련 담당자가 프로젝트 구성을 수정하거나 볼 수 있는지 확인합니다. 이러한 계정은 프로젝트에 필요한 변경사항에 관한 이메일을 수신할 수도 있습니다.

역할에는 프로젝트 리소스에서 특정 작업을 실행할 수 있는 권한 집합이 포함되어 있습니다. 프로젝트 편집자는 프로젝트의 OAuth 동의 화면을 변경하는 기능과 같이 상태를 수정하는 작업에 대한 권한을 보유합니다. 모든 편집자 권한이 있는 프로젝트 소유자는 프로젝트와 연결된 계정을 추가하거나 삭제하거나 프로젝트를 삭제할 수 있습니다. 프로젝트 소유자는 결제 정보가 설정될 수 있는 이유에 관한 컨텍스트를 제공할 수도 있습니다. 프로젝트 소유자는 유료 API를 사용하는 프로젝트의 결제 정보를 설정할 수 있습니다.

프로젝트 소유자와 편집자는 최신 상태를 유지해야 합니다. 프로젝트에 여러 관련 계정을 추가하여 프로젝트 및 관련 유지보수에 대한 지속적인 액세스를 보장할 수 있습니다. 프로젝트에 관한 알림 또는 서비스 업데이트가 있는 경우 이러한 계정으로 이메일을 전송합니다. Google Cloud 조직 관리자는 조직의 모든 프로젝트에 연결 가능한 연락처가 연결되어 있는지 확인해야 합니다. 프로젝트의 최신 연락처 정보가 없는 경우 조치가 필요한 중요한 메시지를 놓칠 수 있습니다.


신원 정확하게 밝히기

사용자에게 표시할 유효한 앱 이름과 로고(선택사항)를 제공합니다. 이 브랜드 정보는 애플리케이션의 신원을 정확하게 나타내야 합니다. 앱 브랜딩 정보는 OAuth 브랜딩 페이지에서 구성됩니다.

프로덕션 앱의 경우 OAuth 동의 화면에 정의된 브랜드 정보는 사용자에게 표시되기 전에 확인해야 합니다. 사용자는 브랜드 확인이 완료된 후 앱에 대한 액세스 권한을 부여할 가능성이 더 높습니다. 앱 이름, 홈페이지, 서비스 약관, 개인정보처리방침을 포함한 기본 애플리케이션 정보는 사용자가 기존 권한을 검토할 때 또는 조직의 앱 사용을 검토하는 Google Workspace 관리자에게 권한 부여 화면에 표시됩니다.

Google은 신원을 허위로 표시하거나 사용자를 속이려고 시도하는 앱의 Google API 서비스 및 기타 Google 제품 및 서비스에 대한 액세스 권한을 취소하거나 정지할 수 있습니다.


필요한 범위만 요청

애플리케이션을 개발하는 동안 API에서 제공하는 예시 범위를 사용하여 애플리케이션 내에서 개념 증명을 만들어 API의 기능에 관해 자세히 알아볼 수 있습니다. 이러한 예시 범위는 특정 API의 가능한 모든 작업을 포괄적으로 다루므로 앱의 최종 구현에 필요한 것보다 더 많은 정보를 요청하는 경우가 많습니다. 예를 들어 예시 범위는 읽기, 쓰기, 삭제 권한을 요청할 수 있지만 애플리케이션에는 읽기 권한만 필요합니다. 애플리케이션을 구현하는 데 꼭 필요한 정보로 제한되는 관련 권한을 요청합니다.

앱이 호출하는 API 엔드포인트의 참조 문서를 검토하고 앱에 필요한 관련 데이터에 액세스하는 데 필요한 범위를 기록합니다. API에서 제공하는 모든 승인 가이드를 검토하고 가장 일반적인 사용 사례를 포함하도록 범위를 더 자세히 설명합니다. 애플리케이션에서 관련 기능을 지원하는 데 필요한 최소한의 데이터 액세스를 선택합니다.

이 요구사항에 관한 자세한 내용은 OAuth 2.0 정책의 필요한 범위만 요청 섹션과 Google API 서비스 사용자 데이터 정책의 관련 권한 요청 섹션을 참고하세요.


민감하지 않거나 제한되지 않은 범위를 사용하는 프로덕션 앱을 인증을 위해 제출

Google 계정으로 로그인은 사용자를 인증하는 동안 민감하고 제한된 범위를 요청하지 않습니다. 애플리케이션에서 인증에만 Google 계정으로 로그인을 사용하는 경우 브랜드 인증을 위해 애플리케이션을 제출해야 합니다. Google Cloud 콘솔의 브랜딩 페이지에서 인증을 위해 제출할 수 있습니다. 이 인증은 동의 화면에 이름, 로고, 개인정보처리방침, 서비스 약관, 범위 등 앱의 브랜딩 요소를 표시하는 데 필요합니다.

앱에서 로그인 버튼을 배치할 때 공식 브랜딩 가이드라인을 준수하는 것이 좋습니다.


내가 소유한 도메인만 사용

Google의 OAuth 동의 화면 인증 프로세스에서는 프로젝트의 홈페이지, 개인정보처리방침, 서비스 약관, 승인된 리디렉션 URI 또는 승인된 자바스크립트 출처와 연결된 모든 도메인을 확인해야 합니다. OAuth 동의 화면 편집기의 승인된 도메인 섹션에 요약된 앱에서 사용 중인 도메인 목록을 검토하고 내가 소유하지 않아 확인할 수 없는 도메인을 식별합니다. 프로젝트의 승인된 도메인 소유권을 확인하려면 Google Search Console을 사용하세요. API 콘솔 프로젝트와 연결된 Google 계정을 소유자 또는 편집자로 사용합니다.

프로젝트에서 공통 공유 도메인이 있는 서비스 제공업체를 사용하는 경우 자체 도메인을 사용할 수 있는 구성을 사용 설정하는 것이 좋습니다. 일부 제공업체는 서비스를 이미 소유한 도메인의 하위 도메인에 매핑하도록 제공합니다.


프로덕션 앱의 홈페이지 호스팅

OAuth 2.0을 사용하는 모든 프로덕션 앱에는 공개적으로 액세스할 수 있는 홈페이지가 있어야 합니다. 앱의 잠재 사용자는 홈페이지를 방문하여 앱에서 제공하는 기능에 관해 자세히 알아볼 수 있습니다. 기존 사용자는 기존 권한 목록을 검토하고 앱의 홈페이지를 방문하여 제품을 계속 사용하고 있음을 상기할 수 있습니다.

애플리케이션의 홈페이지에는 앱의 기능에 관한 설명과 개인정보처리방침 및 서비스 약관(선택사항) 링크가 포함되어야 합니다. 홈페이지는 내가 소유한 확인된 도메인에 있어야 합니다.


보안 리디렉션 URI 및 자바스크립트 출처 사용

웹 앱용 OAuth 2.0 클라이언트는 일반 HTTP가 아닌 HTTPS 리디렉션 URI 및 자바스크립트 출처를 사용하여 데이터를 보호해야 합니다. Google은 보안 컨텍스트에서 시작되지 않거나 보안 컨텍스트로 리디렉션되지 않는 OAuth 요청을 거부할 수 있습니다.

페이지로 돌아가는 토큰 및 기타 사용자 인증 정보에 액세스할 수 있는 서드 파티 애플리케이션 및 스크립트를 고려합니다. 토큰 데이터 확인 및 저장으로 제한되는 리디렉션 URI 위치를 사용하여 민감한 정보에 대한 액세스를 제한합니다.


다음 단계

이 페이지의 OAuth 2.0 정책을 앱이 준수하는지 확인한 후 인증 프로세스에 관한 자세한 내용은 브랜드 인증을 위해 제출을 참고하세요.