개요

통합 경로 선택

필요에 가장 적합한 경로를 선택하세요.

경로	권장 용도	자세히 알아보기
범용 상거래 프로토콜 (UCP)	판매자 및 소매업체	UCP 문서
표준 계정 연결	스마트 홈, TV, YouTube	Docs

계정 연결을 통해 Google 계정 보유자는 빠르고 원활하며 안전하게 서비스에 연결할 수 있습니다. Google 계정 연결을 구현하여 플랫폼의 사용자 데이터를 Google 앱 및 서비스와 공유할 수 있습니다.

보안 OAuth 2.0 프로토콜을 사용하면 사용자의 Google 계정을 플랫폼의 계정과 안전하게 연결하여 Google 애플리케이션과 기기가 서비스에 액세스할 수 있도록 허용할 수 있습니다.

사용자는 계정을 연결하거나 연결 해제할 수 있으며, Google 계정 연결을 사용하여 플랫폼에서 새 계정을 만들 수 있습니다.

사용 사례

Google 계정 연결을 구현해야 하는 이유는 다음과 같습니다.

플랫폼의 사용자 데이터를 Google 앱 및 서비스와 공유합니다.
범용 상거래 프로토콜 (UCP)을 사용하여 Google 쇼핑 및 AI 표시 경로 (검색, Gemini)와 통합합니다.
Google TV를 사용하여 동영상 및 영화 콘텐츠를 재생합니다.
Google Home 앱과 Google 어시스턴트를 사용하여 Google 스마트 홈 연결 기기를 관리하고 제어하세요. 'Hey Google, 조명 켜 줘'
대화형 작업을 사용하여 사용자 맞춤 Google 어시스턴트 환경과 기능을 만드세요. 예를 들어 "Hey Google, 스타벅스에서 내가 자주 주문하는 메뉴를 주문해 줘"와 같이 말할 수 있습니다.
사용자가 Google 계정을 리워드 파트너 계정에 연결한 후 YouTube에서 자격 요건을 충족하는 라이브 스트림을 시청하여 리워드를 받을 수 있도록 지원합니다.
가입 시 Google 계정 프로필에서 동의를 얻어 공유된 데이터로 새 계정을 미리 채웁니다.

기능 및 요구사항

다음 표에서는 각 연결 흐름에 대한 지원 및 권장사항을 정의합니다.

흐름 연결	표준 기능	UCP 기능
App Flip	추천	추천
간소화된 연결	추천	추천
OAuth 연결	필수 (대체)	필수 (대체)
OAuth 2.1	추천	추천

필요한 데이터만 공유하도록 맞춤 범위를 정의하여 사용자 개인 정보를 개선하고, 데이터 사용 방식을 명확하게 정의하여 사용자 신뢰를 높입니다.
계정을 연결 해제하면 플랫폼에서 호스팅되는 데이터 및 서비스에 대한 액세스 권한이 취소될 수 있습니다. 선택사항인 토큰 취소 엔드포인트를 구현하면 Google에서 시작한 이벤트와 동기화할 수 있으며, 교차 계정 보호(RISC)를 사용하면 플랫폼에서 발생하는 연결 해제 이벤트를 Google에 알릴 수 있습니다.

계정 연결 흐름

Google 계정 연결 흐름에는 3가지가 있으며 모두 OAuth 기반이며 OAuth 2.0 호환 승인 및 토큰 교환 엔드포인트를 관리하거나 제어해야 합니다.

연결 프로세스 중에 계정 소유자의 계정 연결 및 데이터 공유 동의를 얻은 후 개별 Google 계정에 대한 액세스 토큰을 Google에 발급합니다.

OAuth 연결

사용자를 연결을 위해 웹사이트로 보내는 OAuth 연결 흐름입니다. 사용자가 계정에 로그인할 수 있도록 웹사이트로 리디렉션됩니다. 로그인하면 사용자는 서비스에서 Google과 데이터를 공유하는 데 동의합니다. 이때 사용자의 Google 계정과 서비스가 연결됩니다.

OAuth 연결은 승인 코드 및 암시적 OAuth 흐름을 지원합니다. 서비스는 암시적 흐름을 위한 OAuth 2.0 호환 승인 엔드포인트를 호스팅해야 하며, 승인 코드 플로우를 사용할 때는 승인 및 토큰 교환 엔드포인트를 모두 노출해야 합니다.

그림 1. OAuth 연결을 사용하여 사용자 휴대전화에서 계정 연결

OAuth 기반 앱 플립 연결 ('앱 플립')

연결을 위해 사용자를 앱으로 보내는 OAuth 흐름

OAuth 기반 앱 플립 연결은 사용자가 인증된 Android 또는 iOS 모바일 앱과 Google 플랫폼 간에 이동하여 제안된 데이터 액세스 변경사항을 검토하고 플랫폼의 계정을 Google 계정에 연결하는 데 동의하도록 안내합니다. 앱 전환을 사용 설정하려면 서비스가 승인 코드 플로우를 사용하여 OAuth 연결 또는 OAuth 기반 Google 계정으로 로그인 연결을 지원해야 합니다.

앱 플립은 Android와 iOS 모두에서 지원됩니다.

작동 방식:

Google 앱은 앱이 사용자 기기에 설치되어 있는지 확인합니다.

앱이 발견되면 사용자는 앱으로 '전환'됩니다. 앱은 Google과 계정을 연결하는 데 필요한 사용자의 동의를 얻은 다음 Google 표시 경로로 다시 '전환'됩니다.
앱을 찾을 수 없거나 앱 전환 연결 프로세스 중에 오류가 발생하면 사용자는 간소화된 연결 또는 OAuth 연결 흐름으로 리디렉션됩니다.

그림 2. 앱 플립을 사용한 사용자 휴대전화의 계정 연결

OAuth 기반 간소화된 연결 ('간소화')

OAuth 기반 Google 계정으로 로그인 간소화된 연결은 OAuth 연결 위에 Google 계정으로 로그인을 추가하여 사용자가 Google 표시 경로를 벗어나지 않고 연결 프로세스를 완료할 수 있으므로 마찰과 이탈이 줄어듭니다. OAuth 기반 간소화된 연결은 Google 계정으로 로그인과 OAuth 연결을 결합하여 원활한 로그인, 계정 생성, 계정 연결을 지원하는 최고의 사용자 환경을 제공합니다. 서비스는 OAuth 2.0 호환 승인 및 토큰 교환 엔드포인트를 지원해야 합니다. 또한 토큰 교환 엔드포인트는 JSON 웹 토큰 (JWT) 어설션을 지원하고 check, create, get 인텐트를 구현해야 합니다.

작동 방식:

Google은 사용자 계정을 어설션하고 이 정보를 전달합니다.

데이터베이스에 사용자의 계정이 있는 경우 사용자가 Google 계정을 서비스의 계정에 성공적으로 연결합니다.
데이터베이스에 사용자의 계정이 없는 경우 사용자는 Google에서 제공하는 어설션된 정보(이메일, 이름, 프로필 사진)로 새 서드 파티 계정을 만들거나 다른 이메일로 로그인하여 연결할 수 있습니다(이 경우 OAuth 연결을 사용하여 서비스에 로그인해야 함).

그림 3. 간소화된 연결을 사용하는 사용자 휴대전화의 계정 연결

어떤 흐름을 사용해야 하나요?

사용자에게 최상의 연결 환경을 제공하려면 모든 흐름을 구현하는 것이 좋습니다. 간소화된 흐름과 앱 전환 흐름을 사용하면 사용자가 몇 단계만으로 연결 프로세스를 완료할 수 있으므로 연결 마찰이 줄어듭니다. OAuth 연결 흐름은 노력이 가장 적게 들며, 이를 시작으로 다른 연결 흐름을 추가할 수 있습니다.

토큰 작업

Google 계정 연결은 OAuth 2.0 업계 표준을 기반으로 합니다.

계정을 연결하고 데이터를 공유하는 데 동의하는 계정 소유자의 동의를 얻은 후 개별 Google 계정에 대한 액세스 토큰을 Google에 발급합니다.

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.
Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.
Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

Accept unexpired access tokens, even after a newer token is issued.
Use alternatives to Refresh Token Rotation.
Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.

Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.
Reduce the number of token requests during the maintenance period:
- Limit maintenance periods to less than the access token lifetime.
- Temporarily increase the access token lifetime:
  1. Increase token lifetime to greater than maintenance period.
  2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
  3. Enter maintenance.
  4. Respond to token requests with a 503 error code and empty body.
  5. Exit maintenance.
  6. Decrease token lifetime back to normal.

영구 연결

영구 연결은 안정적인 통합을 위한 핵심 요구사항입니다. 이를 통해 일시적인 네트워크 오류나 주기적인 사용자 인증 정보 새로고침 중에도 사용자 계정이 연결된 상태로 유지됩니다.

영구 링크를 구현하려면 '슬라이딩 윈도우' 접근 방식을 사용하세요. 기존 새로고침 토큰을 순환하는 대신 만료를 연장합니다 (RFC 6749 섹션 6 참조). 이렇게 하면 새 새로고침 토큰이 발급되었지만 Google에서 성공적으로 수신하거나 저장하지 않은 경우 발생할 수 있는 경합 상태 및 의도치 않은 연결 해제가 방지됩니다.

Google 계정으로 등록

계정 연결을 사용 설정하려면 OAuth 2.0 설정에 대한 세부정보와 사용자 인증 정보를 공유해야 합니다. 자세한 내용은 등록을 참고하세요.