민감한 범위 확인

앱에서 Google API를 사용하여 Google 사용자 데이터에 액세스할 권한을 요청하면 앱을 처음으로 공개하기 전에 확인 절차를 완료해야 할 수 있습니다.

이 요구사항이 앱에 적용되는지 여부는 크게 다음 두 가지 요인에 따라 결정됩니다.

  1. 액세스하는 사용자 데이터의 유형(공개 프로필 정보, 캘린더 항목, Drive에 있는 파일, 특정 건강 및 피트니스 데이터 등)
  2. 필요한 액세스 수준(읽기 전용, 읽기 및 쓰기 등)

OAuth 2.0을 사용하여 Google 계정에서 데이터 액세스 권한을 부여받으면 범위라고 하는 문자열을 사용하여 사용자를 대신하여 액세스하려는 데이터 유형을 지정합니다. 앱에서 민감한 또는 제한됨으로 분류된 범위를 요청하는 경우 앱 사용 시 예외가 없는 한 인증 절차를 완료해야 할 수 있습니다.

민감한 범위의 예로는 Google Calendar에 저장된 일정 읽기, Google 주소록에 새 연락처 저장, YouTube 동영상 삭제 등이 있습니다. 사용 가능한 범위 및 그 분류에 관한 자세한 내용은 앱에서 호출한 API 엔드포인트에 관한 참조 문서와 API에 게시된 관련 승인 가이드를 참고하세요.

해당 기능을 제공하는 데 필요한 사용자 데이터에 최소한의 액세스가 필요한 범위를 요청해야 합니다. 예를 들어 데이터만 읽는 앱은 API 및 관련 엔드포인트에 더 좁은 범위를 사용할 수 있을 때 콘텐츠를 읽고 쓰고 삭제할 수 있는 액세스를 요청해서는 안 됩니다. Google API에서 수신하는 데이터는 API의 정책을 준수하고 앱 작업 및 개인정보처리방침에서 사용자를 나타내는 방식으로만 사용되어야 합니다.

앱 출시 계획 또는 새로운 범위가 필요한 새로운 기능의 출시 완료에 필요한 시간을 고려해야 합니다. 민감한 범위 확인 절차를 완료하는 데 일반적으로 영업일 기준 3~5일이 걸립니다. 앱은 민감한 범위 확인 요청의 하위 집합으로 브랜드 인증을 완료할 수 있습니다.

민감한 범위 이해하기

민감한 범위는 Google에서 액세스 권한을 부여하기 전에 Google의 검토를 받아야 합니다. Google Workspace 조직 관리자는 민감한 범위에 대한 액세스를 제한하여 조직에서 신뢰할 수 있는 것으로 명시적으로 표시하지 않은 OAuth 클라이언트 ID로 액세스를 방지할 수 있습니다.

범위 사용 이해하기

  • 앱에서 사용하거나 사용하려는 범위를 검토합니다. 기존 범위 사용을 찾으려면 앱의 소스 코드에서 승인 요청과 함께 전송된 범위를 검사하세요.
  • 요청된 각 범위가 앱 기능의 의도된 작업에 필요하며 기능을 제공하는 데 필요한 최소한의 권한을 사용하는지 확인합니다. Google API에는 일반적으로 엔드포인트 또는 엔드포인트 내 특정 속성을 호출하는 데 필요한 범위가 포함된 제품의 Google 개발자 페이지에 관한 참조 문서가 있습니다. 앱에서 호출하는 API 엔드포인트에 필요한 액세스 범위에 관한 자세한 내용은 이러한 엔드포인트의 참조 문서를 확인하세요.
  • Google API에서 수신하는 데이터는 API의 정책을 준수하고 앱 작업 및 개인정보처리방침에서 사용자를 나타내는 방식으로만 사용되어야 합니다.
  • 잠재적 sensitive or restricted 또는 제한 상태를 비롯하여 각 범위에 관해 자세히 알아보려면 API 문서를 참고하세요.
  • API Console의 OAuth 동의 화면 구성 범위 페이지에서 앱에서 사용하는 모든 범위를 선언합니다. 지정한 범위는 민감한 카테고리 또는 제한된 카테고리로 그룹화되어 필요한 추가 인증을 강조표시합니다.
  • 통합에 사용된 데이터와 일치하는 최적의 범위를 찾고 용도를 이해한 후 테스트 환경에서 모든 것이 여전히 작동하는지 확인한 다음 인증을 위해 제출을 준비합니다.
표에는 API 이름, 민감한 범위 중 하나, 범위에 포함되는 설명이 표시됩니다.
그림 1. OAuth 동의 화면 구성 범위 페이지에 표시된 민감한 범위의 예

인증 준비 단계

Google API를 사용하여 데이터 액세스를 요청하는 모든 앱은 브랜드 인증을 완료하려면 다음 단계를 따라야 합니다.

  1. 앱이 인증 요구사항 예외 섹션의 사용 사례에 해당하지 않는지 확인합니다.
  2. 앱이 연결된 API 또는 제품의 브랜드 요구사항을 준수하는지 확인합니다. 예를 들어 Google 로그인 범위는 브랜딩 가이드라인을 참고하세요.
  3. Google Search Console 내에서 프로젝트의 승인된 도메인 소유권을 확인합니다. API Console 프로젝트와 연결된 Google 계정을 소유자나 편집자로 사용합니다.
  4. 앱 이름, 지원 이메일, 홈페이지 URI, 개인정보처리방침 URI 등 OAuth 동의 화면의 모든 브랜드 정보가 앱의 정체성을 정확하게 나타내는지 확인합니다.

애플리케이션 홈페이지 요구사항

홈페이지가 다음 요구사항을 충족하는지 확인하세요.

  • 홈페이지는 사이트에 로그인한 사용자뿐만 아니라 공개적으로 액세스할 수 있어야 합니다.
  • 홈페이지와 검토 중인 앱의 관련성은 명확해야 합니다.
  • Google Play 스토어 또는 Facebook 페이지의 앱 등록정보 링크가 유효한 애플리케이션 홈페이지로 간주되지 않습니다.

애플리케이션 개인정보처리방침 링크 요구사항

앱의 개인정보처리방침이 다음 요구사항을 충족하는지 확인합니다.

  • 개인정보처리방침은 사용자에게 표시되고, 애플리케이션의 홈페이지와 동일한 도메인에서 호스팅되고, Google API Console의 OAuth 동의 화면에 연결되어 있어야 합니다. 홈페이지에는 앱 기능에 대한 설명, 개인정보처리방침 및 선택적 서비스 약관 링크가 포함되어야 합니다.
  • 개인정보처리방침은 애플리케이션에서 Google 사용자 데이터에 액세스, 사용, 저장, 공유하는 방식을 공개해야 합니다. Google 개인정보처리방침에 공개된 관행으로 Google 사용자 데이터 사용을 제한해야 합니다.

인증을 위해 앱을 제출하는 방법

Google API Console 프로젝트는 모든 API Console 리소스를 구성합니다. 프로젝트는 프로젝트 작업을 수행할 수 있는 권한이 있는 연결된 Google 계정 집합, 사용 설정된 API 집합, 이러한 API의 결제, 인증, 모니터링 설정으로 구성됩니다. 예를 들어 프로젝트에는 하나 이상의 OAuth 클라이언트가 포함될 수 있으며, 이러한 클라이언트가 사용할 API를 구성할 수 있으며, 사용자가 앱 액세스를 승인하기 전에 사용자에게 표시되는 OAuth 동의 화면을 구성할 수 있습니다.

아직 OAuth 클라이언트가 프로덕션 준비가 되지 않은 경우 확인을 요청하는 프로젝트에서 해당 클라이언트를 삭제하는 것이 좋습니다. Google API Console에서 이 작업을 수행할 수 있습니다.

인증을 위해 제출하려면 다음 단계를 따르세요.

  1. 앱이 Google API 서비스 약관과 Google API 서비스 사용자 데이터 정책을 준수하는지 확인합니다.
  2. 프로젝트에 연결된 계정의 소유자 및 편집자 역할, OAuth 동의 화면의 사용자 지원 이메일, 개발자 연락처 정보를 API Console에 최신 상태로 유지합니다. 이렇게 하면 담당 팀원에게 새로운 요구사항을 알릴 수 있습니다.
  3. API ConsoleOAuth Consent Screen page로 이동합니다.
  4. 프로젝트 선택기 버튼을 클릭합니다.

  5. 다음에서 선택 대화상자가 나타나면 프로젝트를 선택합니다. 프로젝트를 찾을 수 없지만 프로젝트 ID를 알고 있다면 브라우저에서 다음 형식으로 URL을 생성할 수 있습니다.

    https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

    [PROJECT_ID]를 사용할 프로젝트 ID로 바꿉니다.

  6. 앱 수정 버튼을 선택합니다.
  7. OAuth 동의 화면 페이지에 필요한 정보를 입력한 다음 저장하고 계속하기 버튼을 선택합니다.
  8. 범위 추가 또는 삭제 버튼을 사용하여 앱에서 요청한 모든 범위를 선언합니다. Google 로그인에 필요한 초기 범위 집합은 민감하지 않은 범위 섹션에 미리 입력됩니다. 추가된 범위는 민감하지 않은 sensitive, or restricted로 분류됩니다.
  9. 앱의 관련 기능과 관련된 문서 링크를 최대 3개 제공합니다.

  10. 후속 단계에서 앱에 대해 요청하는 추가 정보를 제공합니다.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
  11. 제공하는 앱 구성에 인증이 필요한 경우 인증을 위해 앱을 제출할 수 있습니다. 필수 입력란을 작성하고 제출을 클릭하여 확인 절차를 시작합니다.

앱을 제출한 후 Google 신용안전팀에서 필요한 추가 정보나 완료해야 하는 단계가 담긴 이메일을 보내 드립니다. 개발자 연락처 정보 섹션의 이메일 주소와 OAuth 동의 화면의 지원 이메일에서 추가 정보를 요청하세요. 프로젝트의 OAuth 동의 화면 페이지에서 응답을 기다리는 동안 검토 프로세스가 일시중지되었는지 여부를 비롯한 프로젝트의 현재 검토 상태를 확인할 수도 있습니다.

인증 요건의 예외

앱이 다음 섹션에 설명된 시나리오에서 사용될 예정이라면 검토를 위해 제출하지 않아도 됩니다.

개인 용도

한 가지 사용 사례는 앱의 유일한 사용자이거나 여러분에게 개인적으로 알려진 소수의 사용자만 앱을 사용하는 경우입니다. 관리자와 제한된 수의 사용자가 확인되지 않은 앱 화면을 진행하고 개인 계정에 앱 액세스 권한을 부여해도 괜찮을 수 있습니다.

개발, 테스트 또는 스테이징 등급에 사용되는 프로젝트

Google OAuth 2.0 정책을 준수하려면 테스트 및 프로덕션 환경을 위한 여러 프로젝트가 있는 것이 좋습니다. Google 계정이 있는 모든 사용자가 앱을 사용할 수 있도록 하려면 확인 목적으로만 앱을 제출하는 것이 좋습니다. 따라서 앱이 개발, 테스트 또는 스테이징 단계에 있는 경우 확인이 필요하지 않습니다.

앱이 개발 단계 또는 테스트 단계에 있다면 게시 상태를 기본 설정인 테스트로 둘 수 있습니다. 이 설정은 앱이 아직 개발 단계이며 테스트 사용자 목록에 추가된 사용자에게만 제공됩니다. 앱 개발 또는 테스트와 관련된 Google 계정 목록을 관리해야 합니다.

Google에서 테스트를 진행 중인 앱을 확인하지 않았다는 경고 메시지
그림 2. 테스터 경고 화면

서비스 소유 데이터만 해당

앱에서 서비스 계정을 사용하여 자체 데이터에만 액세스하고 Google 계정에 연결된 사용자 데이터에는 액세스하지 않는 경우 인증을 위해 제출할 필요가 없습니다.

서비스 계정이 무엇인지 알아보려면 Google Cloud 문서의 서비스 계정을 참조하세요. 서비스 계정을 사용하는 방법은 서버 간 애플리케이션에 OAuth 2.0 사용을 참조하세요.

내부 전용

즉, Google Workspace 또는 Cloud ID 조직의 사용자만 앱을 사용합니다. 프로젝트는 조직이 소유해야 하며, 내부 사용자 유형에 대해 OAuth 동의 화면을 구성해야 합니다. 이 경우 조직 관리자의 승인이 필요할 수 있습니다. 자세한 내용은 Google Workspace 추가 고려사항을 참고하세요.

도메인 전체 설치

앱에서 Google Workspace 또는 Cloud ID 조직의 사용자만 타겟팅할 계획이며 항상 도메인 전체 설치를 사용하는 경우 앱에서 앱 인증을 요구하지 않습니다. 도메인 전체 설치를 통해 도메인 관리자가 서드 파티 및 내부 애플리케이션에 사용자 데이터에 대한 액세스 권한을 부여할 수 있기 때문입니다. 조직 관리자는 도메인 내에서 사용할 수 있도록 앱을 허용 목록에 추가할 수 있는 유일한 계정입니다.

FAQ에서 내 애플리케이션에 다른 Google Workspace 도메인의 엔터프라이즈 계정 사용자가 있는 경우에서 앱을 도메인 전체 설치로 지정하는 방법을 알아보세요.