통합 고려사항

이 단계별 가이드는 모든 주요 통합 문제를 결정하는 데 도움이 됩니다.

개요에서 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 및 서비스에 액세스해야 하는 경우 authorization API를 통합해야 할 수도 있습니다. 인증은 사이트에 사용자를 인증하는 ID 토큰을 제공하는 반면, 승인은 사이트에 Google API 및 서비스를 사용할 수 있는 (별도의) 액세스 토큰과 권한을 제공합니다. 자세한 내용은 웹 인증을 참고하세요.

인증과 승인을 위한 UX 분리

웹사이트에서 인증 API와 승인 API를 모두 호출해야 한다면 서로 다른 시점에 별도로 호출해야 합니다. 인증 및 승인 시점 분리를 참조하세요.

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

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

원활한 UX 전환 및 복잡성을 줄이기 위해 일반적인 방법은 프로세스를 두 단계로 나누는 것입니다.

  1. UX를 리팩터링하여 인증 순간과 승인 시점을 구분합니다.

  2. Google ID 서비스 자바스크립트 라이브러리로 이전하세요.

HTML API와 자바스크립트 API 비교

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

HTML API를 사용하면 기본 제공되는 기능이 더 많아집니다. 예를 들면 다음과 같습니다.

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

HTML API를 사용하면 몇 가지 자바스크립트를 작성하여 동작을 맞춤설정할 수도 있습니다.

  • 콜백 핸들러를 직접 작성한 다음 함수 이름을 data-callback 속성으로 설정할 수 있습니다. 한 가지 좋은 예는 XmlHttpRequest를 사용하여 반환된 사용자 인증 정보를 서버에 제출하는 것입니다. 이렇게 하면 기본 사후 제출로 인해 페이지가 새로고침되지 않습니다.

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

  • 원탭 렌더링 및 Google 계정으로 로그인 버튼 예를 들어 사용자가 메뉴에서 로그인을 선택한 후
  • API를 여러 번 호출 예를 들어 Google 계정으로 로그인 버튼은 로그인 대화상자가 렌더링될 때마다 렌더링되어야 합니다.
  • HTML 페이지를 동적으로 생성하여 그 안에 API 호출 코드를 삽입하기 어려움
  • 나중에 Google ID 서비스 자바스크립트 라이브러리를 로드합니다.

HTML API 코드는 페이지 온로드 이벤트 또는 Google ID 서비스 자바스크립트 라이브러리 온로드 이벤트 중 나중에 발생하는 이벤트에서 한 번만 호출할 수 있습니다. HTML API 동작이 예상에 맞지 않는 경우 JavaScript API를 사용해야 합니다.

페이지를 초기화하거나 원탭 버튼 렌더링을 위해 동일한 웹페이지에서 JavaScript API와 함께 HTML API를 사용하지 마세요. HTML 및 자바스크립트 코드에서 중복될 수 있는 위치를 확인하세요. 다음에 유의하세요.

  • <div id='g_id_onload' ... ><id> 또는 <div class='g_id_signin' ...></div>에 있는 요소 중 하나 이상이 HTML 코드에 있다면 HTML API를 사용하고 있는 것입니다.
  • initialize(), prompt() 또는 render()에 있는 메서드 중 하나 이상이 자바스크립트 코드에서 호출되는 경우 JavaScript API를 사용하고 있는 것입니다. 메서드가 인라인 처리되든 분리된 자바스크립트 파일에서 로드되든 상관없습니다.

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

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

팝업과 리디렉션 비교

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

팝업 UX에서 ID 공급업체는 클라이언트 측 교차 출처 통신 채널을 기반으로 빌드하여 ID 공급업체의 동의 페이지가 표시되는 팝업 창에서 서드 파티 페이지가 표시되는 기본 창으로 OAuth 응답을 전달해야 합니다. 일반적으로 여러 창에서 OAuth 응답을 보내고 받으려면 양쪽에 자바스크립트 코드가 필요합니다.

팝업 및 리디렉션 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_uri를 Google API 콘솔에서 클라이언트의 승인된 리디렉션 URI에 추가해야 합니다.

버튼 맞춤설정

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

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

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

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

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

버튼 렌더링 권장사항

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

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

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

  • 가능한 한 빨리 Google ID 서비스 자바스크립트 라이브러리를 로드합니다. 특히 모바일 웹에서 다른 큰 라이브러리보다 먼저 자바스크립트 라이브러리를 로드하는 것이 좋습니다.

  • 사용자가 메뉴에서 로그인을 선택한 후에만 Google 계정으로 로그인 버튼이 렌더링되는 경우 먼저 숨겨진 요소에서 Google 계정으로 로그인 버튼을 렌더링한 다음 사용자가 메뉴에서 로그인을 선택하면 이 버튼이 표시되도록 할 수 있습니다.

원탭 고려사항

자동 로그인

취소 가능한 자동 로그인을 사용하면 다음과 같은 이점이 있습니다.

  • 사용자 작업 1개를 저장하여 로그인율을 개선할 수 있습니다.
  • 지원 중단된 이전 Google 로그인 자바스크립트 라이브러리에서 제공하는 자동 로그인과 달리, 자동 로그인이 발생할 때 사용자에게 항상 일부 UI가 표시되는데, 이를 통해 사용자가 웹사이트에 로그인한 이유와 방법에 관한 컨텍스트를 확인할 수 있습니다. 사용자는 원하는 경우 취소할 수도 있습니다.
  • 사용자가 이전에 사용한 계정을 자동으로 선택하므로 사용자가 웹사이트에서 중복 계정을 만드는 것을 방지할 수 있습니다.

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

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

HTML API를 사용하면 원탭이 페이지 로드 시 항상 표시됩니다. 자바스크립트 사용

API를 사용하면 원탭 UI가 표시되는 시점을 제어할 수 있습니다. 아래에 설명된 몇 가지 이유로 인해 API가 호출된 후에 원탭 UI가 항상 표시되지는 않을 수도 있습니다.

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

버튼 클릭 이벤트에 원탭 UI만 표시하려고 하지 마세요. 위와 같은 이유로 원탭 UI가 표시되지 않을 수 있고 사용자 작업 후에 아무것도 표시되지 않으므로 사용자의 UX에 문제가 있을 수 있습니다. 버튼 클릭 이벤트에서:

권장됨

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

권장하지 않음

  • 원탭만 제공하는 경우 원탭이 표시되지 않으면 로그인 환경이 손상될 수 있습니다.
  • 원탭이 표시되지 않는 경우 UI 상태 콜백을 사용하여 다른 UI 표시 향후 출시 버전에서는 UI 상태 콜백이 제휴 사용자 인증 정보 관리에서 제대로 작동하지 않을 수 있으므로 이 방법은 사용하지 않는 것이 좋습니다.

ITP 브라우저 원탭

지능형 추적 방지 (ITP)로 인해 일반적인 원탭 UX는 iOS의 Chrome, Safari, Firefox와 같은 ITP 브라우저에서 작동하지 않습니다. 이러한 브라우저에서는 시작 페이지로 시작하는 다른 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 또는 자바스크립트 콜백 함수를 사용하는지 여부

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

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

    • HTML API를 사용하든 JavaScript API를 사용하든 로그인 URI를 설정해야 합니다. 사용자가 이미 웹페이지 외부로 리디렉션되었으므로 자바스크립트 콜백 함수를 사용하여 응답을 처리하는 것은 불가능합니다.
    • UX 요약: 사용자에게 Google 계정으로 로그인 버튼을 클릭하면 세션 선택 및 승인을 위해 Google UI로 연결되는 전체 페이지 리디렉션이 표시됩니다. 완료되면 전체 페이지 POST가 지정된 로그인 URI에 제출됩니다.

  2. 원탭 또는 Google 계정으로 로그인 버튼 팝업 UX 모드의 경우 JavaScript API를 사용하거나 HTML API를 사용하고 JavaScript 콜백 함수가 제공되는 경우 다음을 충족해야 합니다.

    • 인증 응답은 자바스크립트 콜백 함수로 다시 전달됩니다.
    • UX 요약: 원탭 프롬프트 또는 팝업 창이 웹페이지 위에 표시됩니다. 사용자가 세션 선택 및 승인을 위한 프롬프트 또는 팝업 창에서 UX를 완료하면 자바스크립트 콜백 함수가 응답을 수신합니다. 후속 UX는 콜백 함수가 서버에 응답을 제출하는 방식에 따라 결정됩니다.

  3. 그렇지 않은 경우 (로그인 URI 사례가 있는 HTML API)

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

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

보안 고려사항

교차 사이트 요청 위조를 방지하려면 다음 안내를 따르세요.

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

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

자주 묻는 질문(FAQ)

  • WebView에서 원탭하여 Google 계정으로 로그인 버튼을 사용할 수 있나요?

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

  • 내 소유의 Google 계정으로 로그인 버튼을 사용할 수 있나요? 아니요. OAuth 서버 측 흐름 또는 이전 버전의 Google 로그인 자바스크립트 라이브러리를 사용하면 의존 당사자가 로그인 브랜드 가이드라인을 사용하여 자신만의 Google 로그인 버튼을 만들 수 있었습니다.

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

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

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

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

    웹사이트에서 원탭과 Google 계정으로 로그인 버튼을 모두 사용하는 것이 좋습니다. 지수 쿨다운으로 인해 탭 한 개가 항상 표시되지 않을 수도 있습니다. 사용자가 실제로 자신의 Google 계정으로 웹사이트에 로그인하려는 경우 기본 로그인 대화상자로 이동하여 거기에서 Google 계정으로 로그인 버튼을 사용하여 로그인하면 됩니다. Google 계정으로 로그인 버튼을 사용하여 성공적으로 로그인하면 원탭 대기 상태가 해제되어 다음 로그인 시 원탭이 표시될 수 있습니다. Google의 다른 버튼 흐름은 서로 다른 JavaScript 바이너리에 있으므로 원탭 대기 상태를 삭제할 수 없습니다.

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

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

    Google ID 서비스 JavaScript 라이브러리는 JavaScript 라이브러리 로드 이벤트 또는 DomContentLoaded 이벤트 중 나중의 이벤트에서 HTML API 코드를 파싱하고 실행합니다.

    • 자바스크립트 라이브러리가 로드될 때 DomContentLoaded 이벤트가 트리거되면 HTML API 코드가 즉시 파싱되어 실행됩니다.
    • 그렇지 않은 경우 자바스크립트 라이브러리는 DomContentLoaded 이벤트에 대한 리스너를 추가합니다. 트리거되면 리스너는 HTML API 코드를 파싱하고 실행합니다.

    또한 HTML API 코드의 파싱 및 실행은 일회성입니다.

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