Google ID 서비스 또는 승인이 처음이거나 익숙하지 않다면 개요를 먼저 읽어보세요.
Google에서는 자바스크립트 라이브러리를 제공하여 승인 범위를 지정하고 사용자 동의를 얻으며 표준 OAuth 2.0 흐름을 더 쉽게 사용할 수 있도록 지원합니다. 사용자 브라우저에서 실행되는 웹 애플리케이션은 이 라이브러리를 사용하여 OAuth 2.0 암시적 흐름을 관리하거나 백엔드 플랫폼에서 완료되는 승인 코드 흐름을 시작합니다.
인증 전용 범위
email, profile, openid 등 여러 범위가 사용자 인증에만 사용됩니다. 앱에서 이 범위만 사용하는 경우 사용자 가입과 로그인에 필요한 JWT ID 토큰과 Google 계정으로 로그인이 요구사항을 충족하는지 확인하세요. 대부분의 경우 이 방식은 사용자 인증에 사용할 수 있는 가장 간단하고 간단한 방법입니다.
주요 용어 및 개념
이 가이드는 사용자가 OAuth 2.0 개념과 RFC6749 같은 IETF 표준에 대한 기본적인 지식이 있다고 가정합니다. 승인 가이드 전체에서 사용되는 용어는 다음과 같습니다.
- 액세스 토큰은 Google에서 발급하는 단기 사용자 인증 정보로, Google API를 안전하게 호출하고 사용자 데이터에 액세스하는 데 사용됩니다.
- 승인 코드는 Google에서 브라우저를 통해 Google 계정에 로그인하는 개별 사용자를 안전하게 식별하기 위해 발급하는 임시 코드입니다. 백엔드 플랫폼에서 이 코드를 액세스 및 갱신 토큰으로 교환합니다.
- 갱신 토큰은 Google에서 발급하는 장기 사용자별 사용자 인증 정보로, 플랫폼에 안전하게 저장되며 사용자가 없을 때도 유효한 새 액세스 토큰을 가져오는 데 사용할 수 있습니다.
- 범위는 정의되고 제한된 양의 사용자 데이터로 토큰을 제한합니다. 자세한 내용은 Google API의 OAuth 2.0 범위를 참고하세요.
- 팝업 모드는 사용자의 브라우저에서 실행되는 자바스크립트 콜백을 기반으로 하는 승인 코드 흐름입니다. Google에서 콜백 핸들러를 호출한 다음 플랫폼에 인증 코드를 전송하는 콜백이 실행됩니다.
- 리디렉션 모드는 HTTP 리디렉션을 기반으로 하는 승인 코드 흐름입니다. 사용자 에이전트는 먼저 Google로 리디렉션되며, Google에서 플랫폼으로 승인되는 두 번째 리디렉션에 코드가 포함됩니다.
토큰 수명은 Google에서 발급기관으로 설정합니다. 다양한 요인으로 인해 정확한 기간은 다를 수 있습니다.
OAuth 2.0 흐름
암시적 절차와 승인 코드이라는 두 가지 흐름이 설명되어 있습니다. 둘 다 Google API에 사용하기 적합한 액세스 토큰을 반환합니다.
승인 코드 흐름은 사용자 보안을 강화하므로 권장됩니다. 이 흐름은 또한 사용자가 없는 상태에서 액세스 토큰을 얻는 데 사용할 수 있는 갱신 토큰을 반환하여 플랫폼이 마지막 순간에 예약된 예정된 회의의 SMS 알림을 보내는 것과 같은 비동기 작업을 더 쉽게 수행할 수 있도록 합니다. 승인 모델 선택에서는 두 흐름 간의 차이점을 자세히 설명합니다.
Google ID 서비스 자바스크립트 라이브러리는 다음과 같은 용도로 OAuth 2.0 표준을 따릅니다.
- 암시적 흐름을 관리하여 브라우저 내 웹 앱에서 Google API를 호출하는 데 필요한 액세스 토큰을 빠르고 쉽게 가져올 수 있습니다.
- 사용자의 브라우저에서 승인 코드 흐름을 시작합니다.
일반적인 단계
암시적과 승인 코드 흐름은 모두 같은 방식으로 시작됩니다.
- 앱에서 하나 이상의 범위에 대한 액세스를 요청합니다.
- Google에서는 사용자에게 동의 대화상자를 표시하고 필요한 경우 먼저 사용자를 Google 계정에 로그인합니다.
- 사용자가 요청된 각 범위를 개별적으로 승인합니다.
그런 다음 각 흐름은 다른 단계로 완료됩니다.
암시적 흐름을 사용하는 경우
- Google은 콜백 핸들러를 사용하여 동의 결과를 앱에 알리고 승인된 범위의 액세스 토큰을 반환합니다.
인증 코드 흐름을 사용할 때
- Google에서는 사용자별 승인 코드로 응답합니다.
- 리디렉션 모드에서는 코드가 플랫폼의 승인 코드 엔드포인트로 반환됩니다.
- 팝업 모드에서는 코드가 브라우저 내 앱의 콜백 핸들러로 반환되며 사용자가 웹사이트를 나가지 않아도 됩니다.
- 4단계: OAuth 2.0 서버 응답 처리부터 백엔드 플랫폼에서 Google과 서버 간 교환을 완료하여 결국 사용자별 갱신 토큰과 액세스 토큰이 플랫폼에 반환됩니다.
사용자 동의
액세스 토큰을 받기 전에 개별 사용자가 앱에서 요청된 범위에 액세스하는 데 동의해야 합니다. 이를 위해 Google은 위의 2단계에서 동의 대화상자를 표시하고 myaccount.google.com/permissions에 결과를 기록합니다.
앱 이름, 로고, 개인정보처리방침, 서비스 약관 및 요청된 범위가 요청을 승인하거나 취소하는 옵션과 함께 표시됩니다.
그림 1에는 단일 범위의 동의 대화상자가 표시되어 있습니다. 단일 범위를 요청하는 경우 범위를 승인하거나 거부하기 위해 체크박스를 선택할 필요가 없습니다.
그림 1: 단일 범위가 표시된 사용자 동의 대화상자.
그림 2에는 여러 범위의 동의 대화상자가 표시되어 있습니다. 둘 이상의 범위가 요청되면 사용자가 각 범위를 승인하거나 거부하도록 하려면 개별 체크박스가 필요합니다.
그림 2: 여러 범위가 표시된 사용자 동의 대화상자.
사용자 계정
동의를 기록하고 액세스 토큰을 발급하려면 Google 계정이 필요합니다. 그 전에 개별 사용자는 Google 계정에 로그인하여 Google에 인증해야 합니다.
필수는 아니지만 웹 앱 또는 백엔드 플랫폼에 가입하거나 로그인하는 데 Google 계정으로 로그인하는 것이 좋습니다. 이렇게 하면 필요한 단계 수를 최소화하여 사용자의 불편을 줄이고 필요에 따라 플랫폼의 개별 계정과 액세스 토큰을 쉽게 연결할 수 있습니다.
예를 들어 Google 계정으로 로그인을 사용하면 활성 Google 계정 세션이 설정되므로 나중에 승인 요청을 할 때 사용자에게 Google 계정으로 로그인하라는 메시지를 표시하지 않아도 됩니다. 사용자 이름, 비밀번호 또는 기타 ID 공급업체를 통해 다른 방법으로 앱에 사용자를 인증하더라도 사용자는 먼저 Google 계정에 로그인하여 동의를 얻어야 합니다.
승인 초기화 중에 힌트(일반적으로 사용자의 Google 계정)를 추가하면 Google에서 계정 선택기의 표시를 건너뛰고 사용자에게 단계를 전달할 수 있습니다. Sign In With에서 반환된 ID 토큰의 사용자 인증 정보로 사용자의 이메일 주소가 포함됩니다.
브라우저에서만 실행되는 웹 앱은 사용자 인증에만 Google을 사용하여 사용자 계정 관리 시스템을 구현하지 않도록 선택할 수 있습니다. 이 시나리오(암시적 흐름이라고 함)에서는 갱신 토큰을 사용자 계정 및 관리 보안 저장소와 연결할 필요가 없습니다.
또는 승인 코드 절차에서 사용자 계정 시스템이 필요한 경우가 있습니다. 사용자별 갱신 토큰은 백엔드 플랫폼에서 개별 계정과 연결하고 나중에 사용할 수 있도록 저장해야 합니다. 사용자 계정 시스템을 구현, 사용, 관리하는 방법은 플랫폼별로 고유하며 자세한 내용은 논의되지 않습니다.
동의 조회 및 철회
사용자는 언제든지 Google 계정 설정에서 동의를 확인하거나 취소할 수 있습니다.
선택적으로 웹 앱 또는 플랫폼에서 google.accounts.oauth2.revoke를 호출하여 토큰을 취소하고 사용자 동의를 삭제할 수 있으며, 이는 사용자가 플랫폼에서 계정을 삭제할 때 유용합니다.
기타 승인 옵션
또는 브라우저에서 클라이언트 측 웹 애플리케이션용 OAuth 2.0의 설명대로 Google의 OAuth 2.0 엔드포인트를 직접 호출하여 암시적 흐름을 사용하여 액세스 토큰을 가져올 수 있습니다.
마찬가지로 승인 코드 흐름의 경우 자체 메서드를 구현하고 웹 서버 애플리케이션용 OAuth 2.0 사용에 설명된 단계를 따를 수 있습니다.
두 경우 모두 개발 시간과 작업을 줄이고 OAuth 2.0 보안 권장사항에 설명된 것과 같은 보안 위험을 최소화하기 위해 Google ID 서비스 라이브러리를 사용하는 것이 좋습니다.