이 단계별 가이드는 모든 주요 통합 문제에 대한 결정을 내리는 데 도움이 됩니다.
Google 계정으로 로그인 개요
다음은 사용자가 웹사이트에서 로그인 / 가입하는 일반적인 단계입니다.
사용자가 Google 웹사이트에 로그인합니다.
Google 계정으로 로그인이 작동하려면 브라우저에 활성 Google 세션이 있어야 합니다. 원탭 및 자동 로그인은 사용자가 웹페이지를 로드하기 전에 Google에 로그인한 경우에만 트리거됩니다. 버튼을 누르면 Google 계정으로 로그인하라는 메시지가 사용자에게 표시되므로 이 단계는 Google 계정으로 로그인 버튼 흐름의 선택사항입니다.
사용자는 원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼이 삽입된 웹페이지를 탐색합니다.
사용자는 원탭, Google 계정으로 로그인 버튼 및 후속 UX 흐름과 상호작용하여 다음을 수행합니다.
- 계속하려면 활성 Google 세션을 선택하세요.
- 아직 동의하지 않은 경우 최종 사용자의 웹사이트 공유에 대한 동의를 얻습니다.
브라우저에 활성 Google 세션이 하나만 있는 경우
- 원탭은 유일한 세션을 자동으로 선택하므로 계정 선택기 페이지를 건너뜁니다.
- Google 계정으로 로그인 버튼은 계정 선택기 페이지에 유지되므로 사용자는 필요할 때 새 Google 세션을 추가할 수 있습니다.
선택한 Google 계정을 이전에 웹사이트에서 사용한 적이 없거나 권한이 취소된 경우 동의 페이지가 표시됩니다.
승인되면 Google에서 결정 내용을 기록하여 다음에는 동의 페이지를 건너뜁니다.
사용자 이름, 이메일, 프로필 사진이 포함된 JSON 웹 토큰 (ID 토큰이라고도 함) 사용자 인증 정보는 JavaScript 콜백 핸들러 또는 백엔드 서비스에 대한 게시물 제출을 통해 공유됩니다.
클라이언트 측의 JavaScript 콜백 핸들러로 ID 토큰을 반환하는 목적은 사용자가 JavaScript 코드에서 ID를 디코딩하는 것이 아니라 자체 방식으로 서버에 ID 토큰을 제출하는 것입니다. 한 가지 좋은 예는 XmlHttpRequest를 사용하여 게시물 제출로 인한 페이지 새로고침을 방지하는 것입니다.
서버 측에서 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 전환 및 복잡성 감소를 위해 프로세스를 분리된 두 단계로 나누는 것이 일반적입니다.
- UX를 리팩터링하여 인증 및 승인 순간을 분리합니다.
Google ID 서비스 JavaScript 라이브러리로 이전합니다.
HTML API와 JavaScript API 비교
HTML API 또는 JavaScript API를 사용하여 원탭, 자동 로그인 또는 Google 계정으로 로그인 버튼을 웹페이지에 통합할 수 있습니다.
HTML API를 사용하면 더 많은 기본 제공 기능을 사용할 수 있습니다. 예를 들면 다음과 같습니다.
- 페이지 로드 시 원탭 또는 Google 계정으로 로그인 버튼 렌더링
- 원탭, 자동 로그인 또는 버튼 팝업/리디렉션 UX가 완료된 후 반환된 사용자 인증 정보를
data-login_uri속성으로 지정된 서버 측 엔드포인트에 제출합니다. - 이중 제출 쿠키로 CSRF 공격을 방지합니다.
- 코드 생성기를 사용하여 HTML 코드를 생성한 다음 HTML 페이지에 복사하기만 하면 됩니다.
HTML API를 사용하면 동작을 사용자 지정하는 JavaScript를 작성할 수도 있습니다.
콜백 핸들러를 직접 작성한 다음 함수 이름을
data-callback속성으로 설정할 수 있습니다. 한 가지 좋은 예는 XmlHttpRequest를 사용하여 반환된 사용자 인증 정보를 서버에 제출하여 기본 게시물 제출로 인한 페이지 새로고침을 방지하는 것입니다.
JavaScript API를 사용하면 다음과 같은 일부 시나리오에서 더 유연하게 작업할 수 있습니다.
- 나중에 원탭 및 Google 계정으로 로그인 버튼을 렌더링합니다. 예를 들어 사용자가 메뉴에서 로그인을 선택한 후
- API를 여러 번 호출합니다. 예를 들어 Google 계정으로 로그인 버튼은 로그인 대화상자가 렌더링될 때마다 렌더링되어야 합니다.
- HTML 페이지를 동적으로 생성하여 페이지 내에 API 호출 코드를 삽입하기 어렵게 만들기
- Google ID 서비스 JavaScript 라이브러리는 훨씬 나중에 로드합니다.
HTML API 코드는 페이지 onload 이벤트 또는 Google ID 서비스 JavaScript 라이브러리 onload 이벤트 중 나중에 발생하는 이벤트를 한 번만 호출할 수 있습니다. HTML API 동작이 기대를 충족하지 않는 경우 JavaScript API를 사용해야 합니다.
페이지 초기화 또는 원탭 및 버튼 렌더링을 위해 동일한 웹페이지에서 JavaScript API와 함께 HTML API를 사용하지 마세요. 코드(HTML 및 JavaScript 모두)에서 중복될 수 있는 부분이 있는지 확인하세요. 다음에 유의하세요.
<div id='g_id_onload' ... ><id>또는<div class='g_id_signin' ...></div>의 요소 중 하나 이상이 HTML 코드에 존재하는 경우 HTML API를 사용하고 있는 것입니다.initialize(),prompt()또는render()에 있는 메서드 중 하나 이상이 JavaScript 코드에서 호출되는 경우 JavaScript API가 인라인이든 분리된 JavaScript 파일에서 로드되든 상관없이 이를 사용하고 있는 것입니다.
다음 JavaScript API는 초기화 또는 원탭 및 버튼 렌더링과 별개로 사용할 수 있습니다. 여기에는 해당하는 HTML API가 없습니다.
Google 계정으로 로그인 버튼 고려사항
팝업과 리디렉션 비교
OAuth 2.0 사양은 HTTP 리디렉션을 고려하지만 팝업 대화상자 렌더링에 관한 안내는 제공하지 않습니다. 특히 데스크톱 웹의 팝업 UX는 최종 사용자에게 더 나은 UX를 제공할 수 있습니다. 이는 사용자가 서드 파티 페이지에서 리디렉션되지 않고 대화상자와 같은 팝업 창에서 권한 부여를 위한 컨텍스트 내 환경을 제공하기 때문입니다.
팝업 UX를 사용하는 경우 ID 공급업체는 클라이언트 측 교차 출처 통신 채널을 기반으로 OAuth 응답을 ID 공급업체의 동의 페이지가 표시되는 팝업 창에서 서드 파티 페이지가 표시되는 기본 창으로 전달해야 합니다. 일반적으로 여러 창에서 OAuth 응답을 주고받으려면 양쪽에 JavaScript 코드가 필요합니다.
Google 계정으로 로그인 버튼으로 팝업과 리디렉션 UX가 모두 지원됩니다.
기본적으로 팝업 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을 로드하는 데 시간이 오래 걸릴 수 있습니다. 이 지연 시간 문제를 완화하기 위해 버튼은 다음과 같이 두 단계로 렌더링됩니다.
- 인라인 버튼 버전은 웹사이트의 DOM 트리에서 렌더링됩니다. 이 버튼은 텍스트 버튼일 뿐이며 맞춤 정보를 사용할 수 없습니다. 목표는 사용자에게 가능한 한 빨리 버튼을 표시하는 것입니다.
- 버튼 iframe을 로드하기 위해 iframe 요청이 Google로 전송되며, 여기에는 맞춤설정된 정보가 포함되어 있을 수도 있습니다. 버튼 iframe이 로드되면 인라인 버전 버튼이 삭제됩니다.
Google 계정으로 로그인 버튼 흐름 버튼이 표시될 때의 지연 시간을 최소화하기 위한 몇 가지 권장사항은 다음과 같습니다.
- Google ID 서비스 JavaScript 라이브러리를 최대한 빨리 로드합니다. 특히 모바일 웹에서는 다른 대규모 라이브러리보다 먼저 JavaScript 라이브러리를 로드하는 것이 좋습니다.
사용자가 메뉴에서 로그인을 선택한 후에만 Google 계정으로 로그인 버튼이 렌더링됩니다. 먼저 숨겨진 요소에서 Google 계정으로 로그인 버튼을 렌더링한 다음 사용자가 메뉴에서 로그인을 선택한 후에 이 버튼을 표시할 수 있습니다.
원탭 고려사항
자동 로그인
취소 가능한 자동 로그인은 다음과 같은 이점을 제공합니다.
- 사용자 작업 한 개를 저장하면 로그인 비율이 개선될 수 있습니다.
- 이전에 지원 중단된 Google 로그인 JavaScript 라이브러리에서 제공되는 자동 로그인과 달리 자동 로그인 시 사용자에게 항상 UI가 표시되므로 웹사이트에 로그인한 이유와 방법을 파악할 수 있습니다. 사용자가 원할 경우 취소할 수도 있습니다.
- 사용자가 이전에 사용한 계정이 자동으로 선택되므로 사용자가 웹사이트에서 중복 계정을 만드는 것을 방지할 수 있습니다.
자동 로그인 사용 여부는 웹사이트의 UX 및 비즈니스 요구사항에 따라 결정해야 합니다. 특히 웹사이트에서 대부분의 로그아웃이 명시적인 사용자 선택이 아닌 세션 시간 초과로 인해 발생하는 경우 자동 로그인을 사용하면 사용자가 세션 상태를 복구할 수 있습니다.
원탭 UI를 표시하는 경우
HTML API를 사용하면 페이지 로드 시 원탭이 항상 표시됩니다. JavaScript API를 사용하면 원탭 UI가 표시되는 시점을 제어할 수 있습니다. 아래에 설명된 몇 가지 이유로 인해 API가 호출된 후 원탭 UI가 표시되지 않을 수도 있습니다.
버튼 클릭 이벤트에 원탭 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 라이브러리는 웹페이지가 동적으로 생성되었다고 가정합니다. HTML 코드를 생성할 때 HTTP 서버가 사용자 로그인 상태를 확인합니다.
- 로그인한 사용자가 없는 경우 원탭을 트리거하여 사용자가 웹사이트에 로그인할 수 있도록 결과 페이지에 원탭 HTML 코드를 포함해야 합니다.
- 사용자가 이미 로그인한 경우 결과 페이지에 원탭 HTML 코드를 포함하면 안 됩니다.
이 경우 원탭 HTML API 코드를 추가하거나 삭제할 책임은 웹 서버에서 있습니다.
One Tap HTML API 코드는 많은 정적 HTML 콘텐츠를 호스팅하는 웹사이트를 위해 설계된 다른 방식으로 작동할 수 있습니다. 언제든지 정적 HTML 페이지에 OneTap HTML API 코드를 포함하고 웹사이트에서 사용되는 세션 쿠키 이름을 지정할 수 있습니다.
- 세션 쿠키가 없으면 원탭 흐름이 트리거됩니다.
- 세션 쿠키가 존재하면 원탭 플로우를 건너뜁니다.
이 경우 원탭 흐름의 트리거 여부는 웹페이지에 One Tap HTML API 코드가 있는지가 아닌 세션 쿠키 상태에 따라 제어됩니다.
서버 측 통합
원탭 후 자동 로그인 또는 Google 계정으로 로그인 버튼 UX 흐름이 완료되면 ID 토큰이 발급되어 웹사이트와 공유됩니다. 사용자를 인증하려면 ID 토큰을 수신하고 검증하는 데 서버 측에서 몇 가지 변경이 필요합니다.
UX 고려사항
일반적으로 서버 측에서 응답을 처리하려면 자체 원본에 HTTP 엔드포인트를 추가해야 합니다. 다음 요소가 결과 UX에 영향을 미칠 수 있습니다.
- 원탭 또는 Google 계정으로 로그인 트리거 여부
- HTML API 또는 JavaScript API 사용 여부
- 응답을 처리하는 데 로그인 URI 또는 JavaScript 콜백 함수를 사용하는지 여부입니다.
실제로 얻을 수 있는 UX는 다음과 같습니다.
Google 계정으로 로그인 버튼 리디렉션 UX 모드의 경우:
- HTML API 또는 JavaScript API 중 무엇을 사용하든 로그인 URI를 설정해야 합니다. 사용자가 이미 웹페이지에서 다른 페이지로 리디렉션되었으므로 JavaScript 콜백 함수를 사용하여 응답을 처리할 수 없습니다.
- UX 요약: Google 계정으로 로그인 버튼을 클릭하면 세션 선택 및 승인을 위해 Google UI로의 전체 페이지 리디렉션이 표시됩니다.
완료되면 전체 페이지
POST가 지정한 로그인 URI에 제출됩니다.
원탭 또는 Google 계정으로 로그인 버튼 팝업 UX 모드의 경우, JavaScript API를 사용하거나 HTML API를 사용하고 JavaScript 콜백 함수가 제공된 경우 다음을 충족해야 합니다.
- 인증 응답이 JavaScript 콜백 함수로 다시 전달됩니다.
- UX 요약: 원탭 메시지 또는 팝업 창이 웹페이지 위에 표시됩니다. 사용자가 세션 선택 및 승인을 위한 메시지 또는 팝업 창에서 UX를 완료하면 JavaScript 콜백 함수가 응답을 수신합니다. 후속 UX는 콜백 함수가 서버에 응답을 제출하는 방법에 따라 결정됩니다.
그렇지 않은 경우 (로그인 URI 사례가 포함된 HTML API):
- 인증 응답은 로그인 URI에 제출됩니다.
- UX 요약: 웹페이지 위에 원탭 메시지 또는 팝업 창이 표시됩니다. 사용자가 세션 선택 및 승인을 위한 메시지 또는 팝업 창에서 UX를 완료하면 지정된 로그인 URL에 전체 페이지
POST제출을 통해 인증 응답이 제출됩니다.
원탭 응답과 Google 계정으로 로그인 버튼 응답을 제출할 때는 일관된 방법을 사용하는 것이 좋습니다.
보안 고려사항
Cross-Site Request Forgery 공격을 방지하려면
- Google ID 서비스 클라이언트 JavaScript 라이브러리에 의해 트리거된 사후 제출의 경우 내장된 이중 제출 쿠키 패턴을 사용할 수 있습니다. 자세한 내용은 서버 측에서 Google ID 토큰 확인을 참고하세요.
- XmlHttpRequest를 사용하여 자체 원본에 제출하려면 커스텀 HTTP 헤더 또는 보안팀에서 승인한 다른 보안 조치를 사용하면 됩니다.
인증 응답에서 ID 토큰을 확인하려면 플랫폼의 Google API 클라이언트 라이브러리 또는 범용 JWT 라이브러리를 사용하는 것이 좋습니다.
자주 묻는 질문(FAQ)
WebView에서 원탭 및 Google 계정으로 로그인 버튼을 사용할 수 있나요?
아니요. 보안 문제로 인해 사용자는 WebView에 Google 세션을 추가하면 안 됩니다. 따라서 GIS는 WebView에서 사용 중지됩니다. Google 세션이 없을 것으로 생각되기 때문입니다.
내 'Google 계정으로 로그인' 버튼을 사용할 수 있나요? 아니요. OAuth 서버 측 흐름 또는 이전 버전의 Google 로그인 자바스크립트 라이브러리를 통해 신뢰 당사자는 로그인 브랜드 가이드라인을 사용하여 자체 버전의 Google 로그인 버튼을 빌드할 수 있었습니다.
그러나 Google 계정으로 로그인에서 이 기능이 삭제되었습니다. 모든 Google 계정으로 로그인 버튼은 Google ID 서비스 JavaScript 라이브러리로 생성해야 합니다. 이러한 변경에는 두 가지 이유가 있습니다.
- 일부 신뢰 당사자가 가이드라인을 따르지 않아 웹사이트에서 Google 계정으로 로그인 버튼이 일관되지 않은 문제가 발생했습니다.
- 라이브러리로 생성하면 로그인 브랜드 가이드라인 자체가 변경될 때 아무것도 변경할 필요가 없습니다.
이 규칙을 적용하기 위해 JavaScript 라이브러리는 버튼을 렌더링하는 API만 노출하고 로그인 과정을 시작하는 API는 노출하지 않습니다.
웹사이트에서 원탭만 사용 설정하고 Google 계정으로 로그인 버튼은 사용 설정하지 않으면 어떻게 되나요?
웹사이트에서 원탭과 Google 계정으로 로그인 버튼을 모두 사용하는 것이 좋습니다. 지수 쿨다운으로 인해 원탭이 매번 표시되지 않을 수 있습니다. Google 계정으로 웹사이트에 로그인하려는 사용자는 기본 로그인 대화상자로 이동해 Google 계정으로 로그인 버튼으로 로그인할 수 있습니다. Google 계정으로 로그인 버튼을 사용한 로그인에 성공하면 원탭 쿨다운 상태가 삭제되어 다음 번 로그인 시 원탭이 표시됩니다. Google의 다른 버튼 흐름은 다른 JavaScript 바이너리에 있기 때문에 원탭 쿨다운 상태를 삭제할 수 없습니다.
웹사이트에서 원탭만 사용 설정하고 Google 계정으로 로그인 버튼은 사용 설정하지 않은 경우 지수 쿨다운 상태가 제때 삭제되지 않으므로 원탭 흐름의 성능이 저하될 수 있습니다.
HTML API 코드는 언제 파싱되나요? 나중에 HTML API 코드를 변경할 수 있나요?
Google ID 서비스 JavaScript 라이브러리는 JavaScript 라이브러리 로드 이벤트 또는 DomContentLoaded 이벤트 중 더 늦은 시점에 HTML API 코드를 파싱하고 실행합니다.
- JavaScript 라이브러리가 로드될 때 DomContentLoaded 이벤트가 트리거되면 HTML API 코드가 즉시 파싱되어 실행됩니다.
- 그렇지 않으면 JavaScript 라이브러리는 DomContentLoaded 이벤트의 리스너를 추가합니다. 리스너는 트리거되면 HTML API 코드를 파싱하고 실행합니다.
또한 HTML API 코드의 파싱 및 실행은 일회성입니다.
- 파싱 및 실행 후에는 HTML API 코드에 대한 이후의 모든 변경사항이 무시됩니다.
- 개발자가 파싱 또는 실행 프로세스를 트리거하는 데 사용할 API는 없습니다.