Google ID 서비스 또는 승인을 처음 접하거나 잘 모르는 경우 개요를 먼저 읽어보세요.
Google에서는 범위를 관리하고, 사용자 동의를 얻고, 표준 OAuth 2.0 흐름을 간소화하는 데 도움이 되는 승인 기능이 포함된 JavaScript 라이브러리를 제공합니다. 사용자의 브라우저에서 실행되는 웹 애플리케이션은 이 라이브러리를 사용하여 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 범위를 참고하세요.
- 팝업 모드는 사용자 브라우저에서 실행되는 JavaScript 콜백을 기반으로 하는 승인 코드 플로우입니다. Google은 콜백 핸들러를 호출하며, 이 핸들러는 승인 코드를 플랫폼으로 전송하는 역할을 합니다. 이 작업은 개발자가 결정합니다.
- 리디렉션 모드는 HTTP 리디렉션을 기반으로 하는 승인 코드 플로우입니다. 사용자 에이전트가 먼저 Google로 리디렉션되고 Google에서 플랫폼의 승인 코드 엔드포인트로의 두 번째 리디렉션에는 코드가 포함됩니다.
토큰 수명은 발급자인 Google에서 설정합니다. 다양한 요인으로 인해 정확한 기간은 달라질 수 있습니다.
OAuth 2.0 흐름
암시적 흐름과 승인 코드 흐름이 설명됩니다. 두 메서드 모두 Google API와 함께 사용하기에 적합한 액세스 토큰을 반환합니다.
승인 코드 플로우는 사용자 보안이 향상되므로 권장됩니다. 이 흐름은 사용자가 없어도 액세스 토큰을 획득하는 데 사용할 수 있는 갱신 토큰도 반환하므로 플랫폼에서 마지막 순간에 예약된 예정된 회의에 대한 SMS 알림을 보내는 등의 비동기 작업을 실행할 수 있습니다. 승인 모델 선택에서는 두 흐름의 차이점을 자세히 설명합니다.
Google ID 서비스 JavaScript 라이브러리는 다음을 위해 OAuth 2.0 표준을 따릅니다.
- 브라우저 내 웹 앱이 Google API를 호출하는 데 필요한 액세스 토큰을 Google에서 빠르게 가져올 수 있도록 암시적 흐름을 관리합니다.
- 사용자의 브라우저에서 승인 코드 흐름을 시작합니다.
일반적인 단계
암시적 흐름과 승인 코드 플로우는 모두 동일한 방식으로 시작됩니다.
- 앱에서 하나 이상의 범위에 대한 액세스를 요청합니다.
- 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에서 계정 선택기 표시를 건너뛸 수 있으므로 사용자가 단계를 하나 줄일 수 있습니다. Google 계정으로 로그인에서 반환된 ID 토큰 사용자 인증 정보에는 사용자의 이메일 주소가 포함되어 있습니다.
브라우저에서만 실행되는 웹 앱은 사용자 인증을 위해 Google만 사용할 수 있으며 사용자 계정 관리 시스템을 구현하지 않도록 선택할 수 있습니다. 암시적 흐름이라고 하는 이 시나리오에서는 사용자 계정 및 관리 보안 스토리지와 갱신 토큰을 연결할 필요가 없습니다.
또는 승인 코드 플로우에 사용자 계정 시스템이 필요합니다. 사용자별 갱신 토큰은 백엔드 플랫폼의 개별 계정과 연결되어야 하며 나중에 사용할 수 있도록 저장되어야 합니다. 사용자 계정 시스템을 구현하고, 사용하고, 관리하는 방법은 플랫폼마다 다르며 자세히 설명하지 않습니다.
동의 보기 및 취소
사용자는 Google 계정 설정에서 언제든지 동의를 확인하거나 취소할 수 있습니다.
선택적으로 웹 앱 또는 플랫폼에서 google.accounts.oauth2.revoke를 호출하여 토큰을 취소하고 사용자 동의를 삭제할 수 있습니다. 이는 사용자가 플랫폼에서 계정을 삭제할 때 유용합니다.
기타 승인 옵션
또는 브라우저가 클라이언트 측 웹 애플리케이션용 OAuth 2.0에 설명된 대로 Google의 OAuth 2.0 엔드포인트를 직접 호출하여 암시적 흐름을 사용하여 액세스 토큰을 가져올 수도 있습니다.
마찬가지로 승인 코드 플로우의 경우 자체 메서드를 구현하고 웹 서버 애플리케이션에 OAuth 2.0 사용에 설명된 단계를 따를 수 있습니다.
두 경우 모두 Google ID 서비스 라이브러리를 사용하여 개발 시간과 노력을 줄이고 OAuth 2.0 보안 최신 권장사항에 설명된 것과 같은 보안 위험을 최소화하는 것이 좋습니다.