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은 콜백 핸들러를 사용하여 앱에 동의 결과를 알리고 승인된 범위의 액세스 토큰을 반환합니다.
인증 코드 흐름을 사용하는 경우
- 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 서비스 라이브러리를 사용하는 것이 좋습니다.