통합 고려사항

이 단계별 가이드를 통해 모든 주요 통합 문제를 결정할 수 있습니다.

Google 계정으로 로그인 개요

다음은 사용자가 웹사이트에서 로그인 / 가입하는 일반적인 단계입니다.

  1. 사용자가 Google 웹사이트에 로그인합니다.

    Google 계정으로 로그인이 작동하려면 브라우저에 활성 Google 세션이 있어야 합니다. 원탭 및 자동 로그인은 사용자가 웹페이지를 로드하기 전에 Google에 로그인한 경우에만 트리거됩니다. 이 단계는 사용자가 버튼을 누르면 Google에 로그인하라는 메시지가 표시되므로 Google 계정으로 로그인 버튼 흐름에 선택사항입니다.

  2. 사용자가 원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼이 삽입된 웹페이지를 탐색합니다.

  3. 사용자는 원탭, Google 계정으로 로그인 버튼, 후속 UX 흐름과 상호작용하여 다음 작업을 실행합니다.

    • 계속하려면 활성 Google 세션을 선택하세요.
    • 아직 동의하지 않은 경우 웹사이트와 프로필 정보를 공유하는 것에 대한 최종 사용자의 동의를 받습니다.

    브라우저에 활성 Google 세션이 하나만 있는 경우

    • 원탭은 유일한 세션을 자동으로 선택하므로 계정 선택 도구 페이지가 건너뜁니다.
    • 'Google 계정으로 로그인' 버튼은 계정 선택 도구 페이지에 계속 표시되므로 사용자가 필요할 때 새 Google 세션을 추가할 수 있습니다.

    선택한 Google 계정이 이전에 웹사이트에서 사용된 적이 없거나 권한이 취소된 경우 동의 페이지가 표시됩니다.

    Google 계정으로 로그인 버튼 동의 화면

    승인되면 Google에서 결정을 기록하여 다음에 동의 페이지를 건너뛸 수 있도록 합니다.

  4. 사용자의 이름, 이메일, 프로필 사진을 포함하는 JSON 웹 토큰 (ID 토큰이라고도 함) 사용자 인증 정보는 JavaScript 콜백 핸들러 또는 백엔드 서비스에 대한 게시 제출을 사용하여 공유됩니다.

    클라이언트 측의 JavaScript 콜백 핸들러에 ID 토큰을 반환하는 목적은 JavaScript 코드에서 디코딩하기 위해서가 아니라 개발자가 자체 방식으로 서버에 제출하기 위해서입니다. 좋은 예는 XmlHttpRequest를 사용하여 게시 제출으로 인한 페이지 새로고침을 방지하는 것입니다.

  5. 서버 측에서는 Google에서 발급한 JWT 사용자 인증 정보가 확인되고 이를 사용하여 새 계정을 만들거나 웹사이트에서 인증된 세션을 설정합니다.

    웹사이트에서 사용자 로그인 상태를 관리합니다.

    사용자의 Google 계정 로그인 상태와 앱은 서로 독립적입니다. 단, 사용자가 인증을 완료하고 Google 계정에 로그인했음을 알 수 있는 로그인 순간은 예외입니다. 사용자는 웹사이트에서 로그인한 활성 세션을 유지하면서 로그인 상태를 유지하거나 로그아웃하거나 다른 Google 계정으로 전환할 수 있습니다.

요약하자면 비밀번호 기반 로그인과 마찬가지로 Google 계정으로 로그인은 웹에서 사용자를 인증하는 또 다른 방법을 제공합니다. Google 계정으로 로그인은 인증 후 웹사이트의 세션 관리를 위한 기능을 제공하지 않습니다.

Google API 및 서비스에 액세스

앞에서 설명한 대로 인증 API를 통합했지만 사이트에서 인증된 사용자를 대신하여 Google API 및 서비스에 액세스해야 하는 경우 승인 API도 통합해야 할 수 있습니다. 인증은 사용자를 인증하기 위한 ID 토큰을 사이트에 제공하지만 승인은 사이트에 Google API 및 서비스를 사용할 수 있는 별도의 액세스 토큰과 권한을 제공합니다. 자세한 내용은 웹용 승인을 참고하세요.

인증 및 승인을 위한 UX 분리

웹사이트에서 인증 API와 승인 API를 모두 호출해야 하는 경우 서로 다른 시점에 별도로 호출해야 합니다. 인증과 승인 시점 분리를 참고하세요.

웹사이트에서 이전에 인증 토큰과 승인 토큰을 함께 요청한 경우 Google ID 서비스 JavaScript 라이브러리를 사용할 때 인증 순간과 승인 순간을 분리하도록 UX를 조정해야 합니다.

  • 인증 시 웹사이트는 원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼과 통합하여 사용자가 웹사이트에 로그인하거나 가입할 수 있도록 할 수 있습니다.
  • 승인 시점에 웹사이트는 승인 API를 호출하여 Google API 또는 서비스에 액세스할 권한과 토큰을 가져올 수 있습니다.

원활한 UX 전환과 복잡성 감소를 위해 프로세스를 두 단계로 나누는 것이 일반적입니다.

  1. 인증과 승인 시점을 분리하도록 UX를 리팩터링합니다.
  2. Google ID 서비스 JavaScript 라이브러리로 이전합니다.

HTML API와 JavaScript API 비교

HTML API 또는 JavaScript API를 사용하여 원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼을 웹페이지에 통합할 수 있습니다.

HTML API를 사용하면 더 많은 내장 기능을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

  • 페이지 로드 시 탭 한 번 또는 Google 계정으로 로그인 버튼 렌더링
  • 원탭, 자동 로그인 또는 버튼 팝업/리디렉션 UX가 완료된 후 반환된 사용자 인증 정보를 data-login_uri 속성으로 지정된 서버 측 엔드포인트에 제출합니다.
  • double-submit-cookie를 사용하여 CSRF 공격을 방지합니다.
  • 코드 생성기를 사용하여 HTML 코드를 생성한 후 HTML 페이지에 복사합니다.

HTML API를 사용하여 동작을 맞춤설정하는 JavaScript를 작성할 수도 있습니다.

  • 자체 콜백 핸들러를 작성한 다음 함수 이름을 data-callback 속성으로 설정할 수 있습니다. 좋은 예로 XmlHttpRequest를 사용하여 반환된 사용자 인증 정보를 서버에 제출하여 기본 게시 제출로 인한 페이지 새로고침을 방지하는 방법이 있습니다.

JavaScript API를 사용하면 일부 시나리오에서 더 유연하게 작업할 수 있습니다.

  • 나중에 OneTap 및 Google 계정으로 로그인 버튼을 렌더링합니다. 예를 들어 사용자가 메뉴에서 로그인을 선택한 후
  • API를 여러 번 호출합니다. 예를 들어 로그인 대화상자가 렌더링될 때마다 Google 계정으로 로그인 버튼을 렌더링해야 합니다.
  • HTML 페이지를 동적으로 생성하여 API 호출 코드를 페이지 내에 삽입하기 어렵습니다.
  • 훨씬 나중에 Google ID 서비스 JavaScript 라이브러리를 로드합니다.

HTML API 코드는 페이지 onload 이벤트 또는 Google Identity Services JavaScript 라이브러리 onload 이벤트 중 더 늦게 발생하는 이벤트에서만 한 번 호출할 수 있습니다. HTML API 동작이 기대치를 충족하지 않는 경우 JavaScript API를 사용해야 합니다.

페이지 초기화 또는 원탭 및 버튼 렌더링을 위해 동일한 웹페이지에서 JavaScript API와 함께 HTML API를 사용하지 마세요. HTML과 JavaScript 코드에서 겹칠 수 있는 위치를 확인합니다. 다음에 유의하세요.

  • HTML 코드에 <div id='g_id_onload' ... ><id> 또는 <div class='g_id_signin' ...></div>의 요소가 하나 이상 있는 경우 HTML API를 사용하고 있는 것입니다.
  • initialize(), prompt() 또는 render()의 메서드 중 하나 이상이 JavaScript 코드에서 호출되는 경우(인라인으로 포함되든 별도의 JavaScript 파일에서 로드되든 관계 없음) JavaScript API를 사용하고 있는 것입니다.

다음 JavaScript API는 초기화 또는 원탭 및 버튼 렌더링과는 별개로 사용할 수 있으며 상응하는 HTML API가 없습니다.

Google 계정으로 로그인 버튼 고려사항

이 섹션에서는 웹사이트에 Google 계정으로 로그인 버튼을 통합할 때 고려해야 할 사항을 설명합니다.

팝업과 리디렉션 비교

OAuth 2.0 사양에서는 HTTP 리디렉션을 고려하지만 팝업 대화상자 렌더링에 관한 안내는 없습니다. 특히 데스크톱 웹에서 팝업 UX는 최종 사용자에게 더 나은 UX를 제공할 수 있습니다. 이는 사용자가 서드 파티 페이지에서 리디렉션되지 않고 대화상자와 같은 팝업 창이 권한 부여를 위한 문맥 내 환경을 제공하기 때문입니다.

팝업 UX를 사용하면 ID 공급업체는 클라이언트 측 교차 출처 통신 채널을 기반으로 하여 ID 공급업체의 동의 페이지가 표시되는 팝업 창에서 서드 파티 페이지가 표시되는 기본 창으로 OAuth 응답을 전달해야 합니다. 일반적으로 창 간에 OAuth 응답을 주고받으려면 양쪽 모두 JavaScript 코드가 필요합니다.

팝업과 리디렉션 UX는 모두 Google 계정으로 로그인 버튼에서 지원됩니다. 기본적으로 팝업 UX가 사용됩니다. data-ux_mode 속성을 설정하여 UX를 변경할 수 있습니다.

Google 계정으로 로그인 버튼 리디렉션 흐름과 OAuth 리디렉션 흐름에는 몇 가지 차이점이 있습니다.

  • Google 계정으로 로그인 버튼 리디렉션 흐름은 항상 POST 메서드를 사용하여 사용자 인증 정보를 웹 서버에 제출하는 반면 OAuth 리디렉션은 일반적으로 GET 메서드를 사용합니다.
  • Google 계정으로 로그인 버튼 리디렉션 흐름에서 제출하는 매개변수는 OAuth 리디렉션 흐름의 매개변수와 다릅니다.

HTML API를 사용하는 개발자의 경우 어떤 UX를 사용하든 사용자 인증 정보는 항상 POST 메서드와 동일한 매개변수를 사용하여 data-login_uri에 제출됩니다. 이렇게 하면 다른 코드 변경 없이 UX 모드를 전환할 수 있습니다. 리디렉션 UX의 경우 data-login_uriGoogle API 콘솔의 클라이언트 승인된 리디렉션 URI에 추가해야 합니다.

버튼 맞춤설정

자체 버튼을 사용하는 것은 지원되지 않습니다. 버튼 흐름을 프로그래매틱 방식으로 시작하는 API는 없습니다.

Google 계정으로 로그인 버튼 흐름을 사용 설정하려면 웹페이지에 하나 이상의 Google 계정으로 로그인 버튼을 렌더링하기만 하면 됩니다. 버튼 흐름은 사용자가 이러한 버튼을 클릭할 때 투명하게 시작되고 처리됩니다.

버튼 렌더링 API를 사용하면 Google 계정으로 로그인 버튼의 디자인을 맞춤설정할 수 있습니다. 코드 생성기를 사용하여 버튼을 대화식으로 디자인하는 것이 좋습니다. JavaScript API를 사용하더라도 먼저 HTML 코드를 생성한 다음 코드를 JavaScript API의 해당 필드에 복사할 수 있습니다.

웹사이트에서 버튼을 렌더링하는 데 개인 맞춤 정보를 사용해야 하는지 여부를 제어할 수 있는 API는 없습니다. 모든 조건이 충족되면 맞춤 버튼이 표시됩니다. 자세한 내용은 맞춤 버튼 이해하기를 참고하세요.

동일한 웹페이지에 여러 버튼을 배치할 수 있습니다. 코드 생성기는 매번 하나의 버튼만 만들 수 있습니다. 이 코드를 여러 번 실행하고 생성된 <div class='g_id_signin' ...></div> 코드를 웹페이지에 복사할 수 있습니다.

버튼 렌더링 권장사항

개인 정보 보호를 위해 맞춤설정 버튼은 accounts.google.com 도메인의 iframe에 표시됩니다. 느린 네트워크에서는 iframe을 로드하는 데 시간이 오래 걸릴 수 있습니다. 이 지연 문제를 완화하기 위해 다음과 같이 두 단계로 버튼이 렌더링됩니다.

  1. 인라인 버튼 버전은 웹사이트의 DOM 트리에서 렌더링됩니다. 텍스트 버튼일 뿐이므로 맞춤 정보는 사용할 수 없습니다. 이는 사용자가 버튼을 최대한 빨리 볼 수 있도록 하기 위함입니다.
  2. 맞춤설정된 정보가 포함될 수 있는 버튼 iframe을 로드하기 위해 iframe 요청이 Google에 전송됩니다. 버튼 iframe이 로드되면 인라인 버전 버튼이 삭제됩니다.

Google 계정으로 로그인 버튼 흐름 버튼 표시의 지연 시간을 최소화하기 위한 몇 가지 권장사항이 나와 있습니다.

  • Google ID 서비스 JavaScript 라이브러리를 최대한 빨리 로드합니다. 특히 모바일 웹에서는 다른 대규모 라이브러리보다 먼저 JavaScript 라이브러리를 로드하는 것이 좋습니다.
  • 사용자가 메뉴에서 로그인을 선택한 후에만 Google 계정으로 로그인 버튼이 렌더링되는 경우 먼저 숨겨진 요소에 Google 계정으로 로그인 버튼을 렌더링한 다음 사용자가 메뉴에서 로그인을 선택한 후에 버튼을 표시할 수 있습니다.

원탭 고려사항

자동 로그인

자동 로그인 기능을 사용하면 사용자가 이전에 웹사이트에 권한을 부여한 경우 원탭 메시지를 클릭하지 않고도 웹사이트에 로그인할 수 있습니다.

취소 가능한 자동 로그인에는 다음과 같은 이점이 있습니다.

  • 사용자 작업 하나를 저장하여 로그인율을 개선할 수 있습니다.
  • 이전의 지원 중단된 Google 로그인 JavaScript 라이브러리에서 제공한 자동 로그인과 달리 자동 로그인이 발생하면 사용자에게 항상 UI가 표시되므로 웹사이트에 로그인한 이유와 방법을 알 수 있습니다. 사용자는 원하는 경우 취소할 수도 있습니다.
  • 사용자가 이전에 사용한 계정이 자동으로 선택되므로 사용자가 웹사이트에서 중복 계정을 만들지 못할 수 있습니다.

자동 로그인을 사용 설정할지 여부는 웹사이트의 UX 및 비즈니스 요구사항에 따라 결정해야 합니다. 특히 웹사이트에서 대부분의 로그아웃이 명시적인 사용자 선택이 아닌 세션 시간 초과로 인해 발생하는 경우 자동 로그인이 사용자가 세션 상태를 복구하는 좋은 방법일 수 있습니다.

원탭 UI를 표시해야 하는 경우

HTML API를 사용하면 원탭이 페이지 로드 시 항상 표시됩니다. JavaScript API를 사용하면 원탭 UI가 표시되는 시점을 제어할 수 있습니다. 다음과 같은 이유로 API가 호출된 후에도 One Tap UI가 항상 표시되지 않을 수 있습니다.

  • 브라우저에 활성 Google 세션이 없습니다.
  • 모든 활성 Google 세션이 선택 해제됩니다.
  • 쿨다운이 진행 중입니다.

버튼 클릭 이벤트에 원탭 UI만 표시하려고 하지 마세요. 나열된 이유로 인해 원탭 UI가 표시되지 않을 수 있으며 사용자 작업 후 아무것도 표시되지 않으므로 사용자에게 UX가 손상될 수 있습니다. 버튼 클릭 이벤트:

권장

  • 비밀번호 로그인과 Google 계정으로 로그인 버튼이 있는 로그인 대화상자를 표시하고 동시에 One Tap API를 호출합니다. 이렇게 하면 사용자에게 항상 웹사이트 로그인 방법이 제공됩니다.

권장하지 않음

  • 원탭만 제공하는 경우 원탭이 표시되지 않으면 사용자에게 로그인 환경이 손상될 수 있습니다.
  • 원탭이 표시되지 않는 경우 UI 상태 콜백을 사용하여 다른 UI를 표시합니다. 이는 향후 출시에서 UI 상태 콜백이 제휴 사용자 인증 정보 관리와 잘 작동하지 않을 수 있으므로 권장하지 않습니다.

ITP 브라우저의 원탭

지능형 추적 방지 (ITP)로 인해 iOS용 Chrome, Safari, Firefox와 같은 ITP 브라우저에서는 일반 원탭 UX가 작동하지 않습니다. 대신 이러한 브라우저에서는 시작 페이지로 시작하는 다른 UX가 제공됩니다.

원하는 경우 ITP 브라우저의 원탭 UX를 사용 중지할 수 있습니다. 자세한 내용은 ITP 브라우저의 원탭 지원을 참고하세요.

Android/macOS/Linux의 Chrome, Edge와 같은 ITP가 아닌 브라우저에서는 이 UX를 사용 설정할 수 없습니다.

사용자가 클릭하면 프롬프트 취소

기본적으로 사용자가 메시지 외부를 클릭하면 원탭 메시지가 자동으로 닫힙니다. 원하는 경우 이 동작을 변경할 수 있습니다.

데스크톱 웹에서는 화면 크기가 충분히 크기 때문에 원탭 메시지를 열어 두는 것이 좋습니다.

원탭 UX의 위치 변경

데스크톱 웹에서는 원탭 메시지의 위치를 변경할 수 있습니다. 그러나 이 기능은 향후 출시에서 제휴 사용자 인증 정보 관리에서 지원되지 않으므로 권장되지 않습니다.

로그인 컨텍스트 변경

원탭은 웹사이트의 더 큰 UX 흐름의 일부여야 합니다. 기본적으로 원탭 UI는 로그인 컨텍스트 내에서 사용됩니다. UI의 언어에 '로그인'과 같은 특정 문구가 포함되어 있습니다. 컨텍스트 속성을 변경하여 다른 문구를 만들 수 있습니다. UX 흐름에 가장 적합한 원탭 헤더 중 하나를 선택할 수 있습니다.

컨텍스트
signin 'Google 계정으로 로그인'
signup 'Google 계정으로 가입'
use 'Google과 함께 사용'

원탭 UI 상태 리슨

더 큰 UX 흐름에 원활하게 통합하기 위해 원탭은 UI 상태가 변경될 때 알림을 보낼 수 있습니다. 하지만 이 기능은 향후 제휴 사용자 인증 정보 관리 출시에서는 지원되지 않습니다.

하위 도메인 전체에서 원탭

기본적으로 원탭 쿨다운 및 기타 상태는 출처별로 추적됩니다. 웹사이트가 여러 하위 도메인에 걸쳐 원탭을 표시하는 경우 API 코드에 이를 표시해야 합니다.

정적 HTML 페이지의 원탭

기본적으로 GIS 라이브러리는 웹페이지가 동적으로 생성된다고 가정합니다. HTTP 서버는 HTML 코드를 생성할 때 사용자 로그인 상태를 확인합니다.

  • 로그인한 사용자가 없는 경우 사용자가 웹사이트에 로그인할 수 있도록 원탭을 트리거하는 원탭 HTML 코드가 결과 페이지에 포함되어야 합니다.
  • 사용자가 이미 로그인한 경우 결과 페이지에 원탭 HTML 코드가 포함되어서는 안 됩니다.

이 경우 원탭 HTML API 코드를 추가하거나 삭제하는 것은 웹 서버의 책임입니다.

One Tap HTML API 코드는 정적 HTML 콘텐츠를 많이 호스팅하는 웹사이트용으로 설계된 다른 방식으로 작동할 수 있습니다. 언제든지 정적 HTML 페이지에 원탭 HTML API 코드를 포함하고 웹사이트에 사용되는 세션 쿠키 이름을 지정할 수 있습니다.

  • 세션 쿠키가 없으면 원탭 흐름이 트리거됩니다.
  • 세션 쿠키가 있으면 원탭 흐름이 건너뜁니다.

이 경우 원탭 흐름을 트리거할지 여부는 웹페이지에 원탭 HTML API 코드가 있는지 여부가 아니라 세션 쿠키 상태에 따라 제어됩니다.

서버 측 통합

원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼 UX 흐름이 완료되면 ID 토큰이 발급되어 웹사이트와 공유됩니다. 사용자를 인증하려면 ID 토큰을 수신하고 유효성을 검사하기 위해 일부 서버 측 변경사항이 필요합니다.

UX 고려사항

일반적으로 서버 측에서 응답을 처리하려면 자체 출처에 HTTP 엔드포인트를 추가해야 합니다. 다음 요소는 결과 UX에 영향을 미칠 수 있습니다.

  • 탭 한 번 또는 Google 계정으로 로그인이 트리거되는지 여부입니다.
  • HTML API 또는 JavaScript API가 사용되는지 여부입니다.
  • 응답을 처리하는 데 로그인 URI가 사용되는지 또는 JavaScript 콜백 함수가 사용되는지 여부입니다.

실제 UX는 다음과 같이 설명됩니다.

  1. Google 계정으로 로그인 버튼 리디렉션 UX 모드:

    • HTML API 또는 JavaScript API 중 어느 쪽을 사용하든 로그인 URI를 설정해야 합니다. 사용자는 이미 웹페이지에서 리디렉션되었으므로 JavaScript 콜백 함수를 사용하여 응답을 처리할 수 없습니다.
    • UX 요약: 사용자가 Google 계정으로 로그인 버튼을 클릭하면 세션 선택 및 승인을 위한 Google UI로 전체 페이지 리디렉션이 표시됩니다. 완료되면 지정한 로그인 URI에 전체 페이지 POST가 제출됩니다.
  2. 원탭 또는 Google 계정으로 로그인 버튼 팝업 UX 모드의 경우 JavaScript API가 사용되거나 HTML API가 사용되고 JavaScript 콜백 함수가 제공되는 경우:

    • 인증 응답은 JavaScript 콜백 함수에 다시 전달됩니다.
    • UX 요약: 원탭 메시지 또는 팝업 창이 웹페이지 위에 표시됩니다. 사용자가 세션 선택 및 승인 프롬프트 또는 팝업 창에서 UX를 완료하면 JavaScript 콜백 함수가 응답을 수신합니다. 후속 UX는 콜백 함수가 서버에 응답을 제출하는 방식에 따라 결정됩니다.
  3. 그 외의 경우 (로그인 URI가 있는 HTML API 케이스):

    • 인증 응답이 로그인 URI에 제출됩니다.
    • UX 요약: 원탭 메시지 또는 팝업 창이 웹페이지 위에 표시됩니다. 사용자가 세션 선택 및 승인 메시지 또는 팝업 창에서 UX를 완료하면 전체 페이지 POST 제출을 사용하여 지정된 로그인 URL에 인증 응답이 제출됩니다.

원탭 응답과 Google 계정으로 로그인 버튼 응답을 일관된 방식으로 제출하는 것이 좋습니다.

보안 고려사항

크로스 사이트 요청 위조 공격을 방지하려면

  • Google ID 서비스 클라이언트 JavaScript 라이브러리에서 트리거된 게시 후 제출의 경우 기본 제공되는 이중 제출 쿠키 패턴을 사용할 수 있습니다. 자세한 내용은 서버 측에서 Google ID 토큰 확인을 참고하세요.
  • XmlHttpRequest를 사용하여 자체 출처에 제출하는 경우 커스텀 HTTP 헤더 또는 보안팀에서 승인한 기타 보안 조치를 사용할 수 있습니다.

인증 응답에서 ID 토큰을 확인하려면 플랫폼에 맞는 Google API 클라이언트 라이브러리 또는 범용 JWT 라이브러리를 사용하는 것이 좋습니다.

자주 묻는 질문(FAQ)

  • 웹뷰에서 원탭 및 Google 계정으로 로그인 버튼을 사용할 수 있나요?

    아니요. 보안 문제로 인해 사용자는 WebView에 Google 세션을 추가해서는 안 됩니다. 따라서 WebView에는 Google 세션이 없어야 하므로 GIS가 사용 중지됩니다.

  • 자체 Google 계정으로 로그인 버튼을 사용할 수 있나요? 아니요. OAuth 서버 측 흐름 또는 이전 버전의 Google 로그인 JavaScript 라이브러리를 사용하면, 신뢰 당사자가 로그인 브랜딩 가이드라인을 사용하여 자체 버전의 Google 로그인 버튼을 빌드할 수 있었습니다.

    하지만 Google 계정으로 로그인에서는 이 기능이 삭제되었습니다. 모든 Google 계정으로 로그인 버튼은 Google ID 서비스 JavaScript 라이브러리에서 생성해야 합니다. 이번 변경에는 두 가지 이유가 있습니다.

    • 일부 신뢰 당사자가 가이드라인을 준수하지 않아 웹사이트에서 Google 계정으로 로그인 버튼이 일관되지 않았습니다.
    • 라이브러리에서 생성하면 로그인 브랜딩 가이드라인 자체가 변경될 때 아무것도 변경할 필요가 없습니다.

    이 규칙을 적용하기 위해 JavaScript 라이브러리는 버튼을 렌더링하는 API만 노출하고 로그인 흐름을 시작하는 API는 노출하지 않습니다.

  • 웹사이트에서 원탭만 사용 설정하고 Google 계정으로 로그인 버튼은 사용 설정하지 않은 경우 어떻게 해야 하나요?

    웹사이트에서 탭 한 번과 Google 계정으로 로그인 버튼을 모두 사용하는 것이 좋습니다. 지수 쿨다운으로 인해 원탭이 매번 표시되지 않을 수 있습니다. 사용자가 Google 계정으로 웹사이트에 로그인하려면 기본 로그인 대화상자로 이동하여 Google 계정으로 로그인 버튼을 눌러 로그인하면 됩니다. Google 계정으로 로그인 버튼을 사용하여 로그인하면 원탭 쿨다운 상태가 삭제되므로 다음 로그인 시 원탭이 표시될 수 있습니다. Google의 다른 버튼 흐름은 다른 JavaScript 바이너리에 있으므로 원탭 쿨다운 상태를 지울 수 없습니다.

    웹사이트에서 원탭만 사용 설정하고 Google 계정으로 로그인 버튼은 사용 설정하지 않은 경우, 지수 쿨다운 상태가 제때 삭제되지 않으므로 원탭 흐름의 실적이 저하될 수 있습니다.

  • HTML API 코드는 언제 파싱되나요? 나중에 HTML API 코드를 변경할 수 있나요?

    Google Identity Services JavaScript 라이브러리는 JavaScript 라이브러리 로드 이벤트 또는 DomContentLoaded 이벤트 중 더 늦은 이벤트에서 HTML API 코드를 파싱하고 실행합니다.

    • JavaScript 라이브러리가 로드될 때 DomContentLoaded 이벤트가 트리거되면 HTML API 코드가 파싱되고 즉시 실행됩니다.
    • 그렇지 않으면 JavaScript 라이브러리가 DomContentLoaded 이벤트의 리스너를 추가합니다. 트리거되면 리스너가 HTML API 코드를 파싱하고 실행합니다.

    또한 HTML API 코드의 파싱과 실행은 서로 다르다는 점에 유의하세요.

    • 파싱 및 실행 후에는 HTML API 코드에 대한 후속 변경사항이 무시됩니다.
    • 개발자가 파싱 또는 실행 프로세스를 트리거할 수 있는 API는 없습니다.