1.1: OAuth 계정 연결

소개 및 비즈니스 영향


Google API를 활용하려면 무료 등록정보 및 유료 광고에 온보딩하는 데 필요한 판매자 액세스 권한을 통합에 부여하는 데 OAuth가 필요합니다.

대체 OAuth

요청을 승인하려면 애플리케이션에서 OAuth 2.0을 사용해야 합니다. 다른 승인 프로토콜은 지원되지 않습니다.

UX 안내


목표: 판매자에게 Google 앱의 데이터 사용 공유 권한을 부여합니다.

디자인 원칙: 적시에 적절한 권한을 요청하세요. 판매자가 권한을 부여하지 않으면 적절하게 실패합니다.

판매자에게 액세스 권한을 제공하라는 메시지가 표시됩니다. 이러한 안내가 판매자에게 표시되는 방법의 예를 찾아보세요.

oauth_1

oauth_2

판매자가 이러한 초기 단계를 완료하면 다음과 같은 세 가지 결과가 발생할 수 있습니다.

결과 1: 판매자가 모든 권한에 동의하는 경우:

oauth_3

판매자가 전체 권한을 제공하는 경우 모든 체크박스를 선택하고 온보딩 프로세스를 계속 진행하라는 메시지가 표시됩니다.

결과 2: 판매자가 광고에 동의하지 않는 경우

oauth_4

판매자는 Google Ads와 관련된 권한을 제외한 모든 체크박스를 선택합니다. 사용자가 온보딩 프로세스를 계속 진행한 후 나중에 새 Google Ads 계정을 만들거나 기존 계정에 연결할 때 권한을 부여하라는 메시지가 다시 표시됩니다.

oauth_5 oauth_6

결과 3: 제품 데이터 또는 사이트 인증이 선택 해제된 경우 판매자의 온보딩이 차단됨

oauth_7

oauth_8

oauth_9

oauth_10

앞의 옵션을 모두 사용하면 동일한 오류 메시지가 표시됩니다.

oauth_11

기술 가이드


OAuth 2.0을 사용한 승인 요청 선택

판매자 인증 방법을 선택하는 방법에는 두 가지가 있습니다.

비서비스 계정용 OAuth 2.0 (적극 권장) 서비스 계정용 OAuth 2.0
OAuth 2.0 클라이언트는 애플리케이션을 식별하고 최종 사용자가 애플리케이션에 Google 데이터에 대한 제한된 액세스 권한을 부여할 수 있도록 합니다. 이를 통해 애플리케이션에서 최종 사용자를 대신하여 Google Cloud API에 액세스할 수 있습니다.

목록에 나열된 어커런스로 인해 액세스 토큰이 무효화되며 코드에서 고려해야 합니다.

● 사용자가 액세스를 취소했습니다.
● 사용자가 비밀번호를 변경했습니다.
● 부여된 갱신 토큰 수가 한도를 초과함
● 갱신 토큰이 6개월 이내에 사용되지 않았습니다.
서비스 계정은 애플리케이션에서 OAuth 2.0을 사용하여 프로그래매틱 방식으로 Google API에 액세스하는 데 사용할 수 있는 특수한 Google 계정으로, 사람의 승인이 필요하지 않은 OAuth 2.0 흐름을 사용합니다. 대신 본인의 애플리케이션만 액세스할 수 있는 키 파일을 사용합니다.

참고: 인증을 위해 서비스 계정을 사용하는 애플리케이션은 자체 판매자 센터 계정에만 액세스할 수 있습니다. 고객의 판매자 센터 계정에 액세스해야 하는 서드 파티 애플리케이션을 작성하는 경우 요청 승인 가이드를 참고하세요.

참고: Cloud 프로젝트가 필요하며 최대 100개의 서비스 계정을 만들 수 있습니다. 문서를 참고하세요.

OAuth 흐름 설정

OAuth 2.0 승인 프레임워크를 사용하면 서드 파티 애플리케이션이 리소스 소유자와 HTTP 서비스 간의 승인 상호작용을 조정하거나 서드 파티 애플리케이션이 자체적으로 액세스 권한을 획득하도록 허용하여 리소스 소유자를 대신하여 HTTP 서비스에 대한 제한된 액세스 권한을 얻을 수 있습니다.

앱이 보호된 (비공개) 데이터에 액세스하므로 OAuth 2.0 클라이언트 ID가 필요합니다. Google API는 인증과 승인에 OAuth 2.0 프로토콜을 사용합니다. Google은 웹 서버, 설치된 애플리케이션, 클라이언트 측 애플리케이션과 같은 일반적인 OAuth 2.0 시나리오를 지원합니다.

자세히 알아보기

쇼핑용 Content API에 OAuth를 사용할 때 알아야 할 사항은 다음과 같습니다.

  1. access_type을 오프라인으로 설정했는지 확인: 액세스 토큰은 주기적으로 만료되어 관련 API 요청에 사용할 수 없는 사용자 인증 정보가 됩니다.

  2. 액세스 토큰 갱신: 토큰과 연결된 범위에 대한 오프라인 액세스를 요청한 경우 사용자에게 권한을 요청하지 않고도 (자세히 알아보기) 액세스 토큰을 갱신할 수 있습니다 (사용자가 없는 경우 포함).

  3. 라이브러리에서 OAuth 구현: Google API 클라이언트 라이브러리를 사용하는 것이 좋습니다.

  4. 범위: Google 판매자 센터 OAuth 범위(https://www.googleapis.com/auth/content)를 사용하여 Google 계정에 대한 읽기 및 쓰기 액세스 권한을 부여하도록 판매자에게 요청해야 합니다.

  5. OAuth를 사용하여 주요 사용자 프로필 정보를 획득할 수 있습니다.

통합에 사용할 범위

판매자를 위해 빌드하려는 통합 유형에 따라 지금은 필요한 모든 범위를 요청하는 것이 좋습니다.

프로그램 범위 범위가 필요한 형식
Content API https://www.googleapis.com/auth/content 무료 등록정보
사이트 확인 https://www.googleapis.com/auth/siteverification 무료 등록정보 및 유료 광고
Google Ads https://www.googleapis.com/auth/adwords 무료 등록정보 및 유료 광고

판매자가 OAuth 액세스 권한을 부여했는지 확인하기

판매자는 특정 범위에 대한 액세스 권한을 부여하려면 OAuth 동의 흐름에서 체크박스를 선택해야 합니다. 필수 범위가 누락된 경우 판매자에게 이러한 범위가 필요한 이유를 설명하고 권한을 다시 요청합니다(자세한 내용). 이러한 모든 권한에 액세스할 수 없으면 판매자가 완전히 온보딩할 수 없습니다.

access

다음 API 엔드포인트를 호출하여 부여된 범위를 확인합니다.

https://www.oauth2.googleapis.com/token

URL은 다음 정보를 반환합니다.

  • access_token
  • 사용자에게 부여된 범위
  • 토큰 만료까지 남은 시간

요청

민감한 범위 및 OAuth 확인 프로세스

OAuth API에서 사용하는 일부 범위는 민감한 것으로 간주되며 확인 절차가 필요합니다. 자세한 내용 및 예는 Content API용 OAuth를 참고하세요.

  1. 정책 준수를 위한 민감한 앱 범위: 앱이 Google의 API 서비스 사용자 데이터 정책을 준수하는지 확인해야 합니다. 또한 API 서비스 약관에 동의해야 합니다.

  2. 앱이 인증 요구사항 예외에 나열된 사용 사례에 해당하지 않는지 확인합니다.

  3. Search Console을 사용하여 프로젝트의 승인된 도메인의 소유권을 확인합니다. Cloud 콘솔 프로젝트의 프로젝트 소유자 또는 프로젝트 편집자 계정을 사용합니다.

  4. OAuth 동의 화면의 모든 브랜드 정보가 일치하고 유효한지 확인합니다. 예를 들어 사용자에게 표시되는 프로젝트 이름, 지원 이메일, 홈페이지 URL, 개인정보처리방침 URL이 앱의 ID를 정확하게 나타냅니다.

  5. 인증 절차를 통해 앱에 민감한 범위를 요청합니다. 절차를 따라 양식을 작성하고 근거를 제시한 후 동영상을 전송해야 합니다.