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와 함께 사용하기에 적합한 액세스 토큰을 반환합니다.
사용자 보안이 강화되므로 승인 코드 흐름을 사용하는 것이 좋습니다. 또한 이 흐름은 사용자가 없을 때 액세스 토큰을 가져오는 데 사용할 수 있는 갱신 토큰을 반환하므로 플랫폼에서 마지막 1분에 예약된 예정된 회의에 대한 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 사용에 설명된 단계를 따를 수 있습니다.
두 경우 모두 OAuth 2.0 보안 최신 권장사항에 설명된 것과 같은 개발 시간과 노력을 줄이고 보안 위험을 최소화하기 위해 Google ID 서비스 라이브러리를 사용하는 것이 좋습니다.