Wellsbabo
← 블로그로 돌아가기
API

Google Cloud Console에서 OAuth2 인증 정보 만들기: OAuth 2.0 Client ID와 Service Account의 차이

Google Cloud Console의 OAuth 2.0 Client ID와 Service Account 인증 방식 및 용도 차이를 알아봅니다.

7분 분량
#Google Cloud#OAuth2#Google API

Google Cloud Console에서 OAuth2용 인증 정보를 설정하면 OAuth 2.0 Client ID와 Service Account라는 두 가지 선택지를 만나게 됩니다.

Google Play Store 영수증 검증 및 처리 API를 만들면서 두 방식의 차이를 자세히 살펴봤고, 그 내용을 정리해 봅니다.

간단히 말해 OAuth 2.0 Client ID를 사용하려면 Redirect URL을 등록해야 하지만 Service Account에는 Redirect URL이 필요하지 않습니다.

OAuth 2.0과 Service Account 인증의 기본 개념

OAuth 2.0 Client ID

OAuth 2.0은 서드파티 애플리케이션이 사용자 데이터에 제한적으로 접근하도록 허용하는 인가 프로토콜입니다.

  1. 사용자 중심: 최종 사용자가 자신의 데이터에 대한 접근을 허용합니다.
  2. 위임된 접근: 사용자 비밀번호를 공유하지 않고 특정 리소스에 접근하게 합니다.
  3. 토큰 기반: Access Token으로 인증과 권한을 관리합니다.
  4. Redirect 필요: 사용자 동의를 얻기 위한 Redirect URL이 필요합니다.

Service Account

Service Account는 개인 사용자가 아니라 애플리케이션이나 가상 머신을 위한 특수 계정입니다.

  1. 애플리케이션 중심: 특정 서비스나 애플리케이션을 대신해 동작합니다.
  2. 키 기반 인증: JSON 키 파일을 사용해 인증합니다.
  3. 직접 접근: 사용자 개입 없이 리소스에 직접 접근할 수 있습니다.
  4. Redirect 불필요: 사용자 동의 과정이 없으므로 Redirect URL도 필요하지 않습니다.

두 방식의 핵심 차이는 사용자 개입이 필요한지, 인증 흐름이 어떻게 구성되는지에 있습니다. OAuth 2.0은 사용자 동의가 필요하지만 Service Account는 백그라운드에서 자동으로 동작합니다.

OAuth 2.0 Client 인증

동작 방식: Google 예시

  1. 사용자가 Google 계정으로 애플리케이션에 로그인하려고 합니다.
  2. 애플리케이션은 사용자를 Google 인증 서버의 OAuth 2.0 인증 페이지로 이동시킵니다.
  3. 사용자가 Google 계정으로 로그인합니다.
  4. 애플리케이션이 요청한 권한을 허용할지 묻는 화면이 표시됩니다.
  5. 사용자가 동의하면 Google 인증 서버가 Authorization Code와 함께 사용자를 미리 등록한 Redirect URL로 돌려보냅니다.
  6. 애플리케이션은 Authorization Code를 사용해 Google 인증 서버에 Access Token을 요청합니다.
  7. Access Token을 발급받은 애플리케이션은 이를 사용해 Google Resource Server의 사용자 데이터에 접근합니다.

이 흐름에서 Google 인증 서버는 인증과 인가를 처리하고, Resource Server는 프로필이나 이메일 같은 실제 사용자 데이터를 저장하고 제공합니다.

Redirect URL

이 과정에서 Redirect URL이 필요한 이유는 보안 때문입니다. Google 인증 서버는 Authorization Code를 등록된 Redirect URL로만 전송합니다. 이 등록 절차가 없다면 악의적인 제삼자가 Authorization Code를 가로챌 수 있습니다.

또한 Redirect URL이 없으면 인증을 마친 사용자가 애플리케이션으로 돌아갈 수 없으므로 인증 절차를 완료할 수 없습니다.

Service Account 인증

동작 방식

  1. 애플리케이션 서버가 Google Cloud Console에서 발급한 JSON 키 파일과 필요한 scope를 조합해 JWT를 만듭니다.
  2. 생성한 JWT를 Google 인증 서버로 전송합니다.
  3. Google 인증 서버가 JWT를 검증하고, 유효하면 Access Token을 발급합니다.
  4. 애플리케이션 서버는 Access Token을 사용해 Google Resource Server의 데이터에 접근합니다.

JSON 키 파일의 역할

JSON 키 파일에는 Service Account의 인증 정보가 담겨 있습니다. Google Cloud Console에서 발급해 애플리케이션 서버에 저장합니다. 서버는 이 키 파일과 필요한 scope를 조합해 JWT를 만들고, Google 인증 서버로 보내 검증받습니다.

Redirect URL이 필요하지 않은 이유

Service Account는 서버 내부에서 토큰을 생성하고 인증 서버의 검증만 받으면 되므로 Redirect URL이 필요하지 않습니다.

두 방식의 주요 차이

  1. 사용자 개입: OAuth 2.0은 사용자의 개입이 필요하지만 Service Account는 필요하지 않습니다.
  2. 인증 흐름: OAuth 2.0은 사용자 동의를 위한 Redirect URL이 필요하지만 Service Account에는 필요하지 않습니다.
  3. 보안 방식: OAuth 2.0은 Redirect URL을 통해 보안을 유지하고, Service Account는 키 파일을 안전하게 관리해야 합니다.
  4. 목적: OAuth 2.0은 사용자 데이터에 제한적으로 접근하기 위한 방식이고, Service Account는 애플리케이션이나 서비스를 대신해 동작하기 위한 방식입니다.

구현 복잡도 비교

OAuth 2.0 Client 인증은 Redirect URL 등록, 사용자 동의, Authorization Code 수신, Access Token 교환으로 이어지는 비교적 복잡한 흐름을 사용합니다. 반면 Service Account 인증은 키 파일을 이용하므로 구현 흐름이 상대적으로 단순합니다.

Redirect URL 사용 방식의 차이

Service Account에서는 애플리케이션 서버가 JSON 키 파일로 토큰을 직접 만들고, 서버에 전송해 검증받은 뒤 Access Token을 받습니다. 하나의 HTTP 요청·응답 흐름으로 인증이 완료됩니다.

OAuth 2.0 Client 인증에서는 사용자가 브라우저에서 로그인하고 권한을 허용한 다음, Authorization Code와 함께 애플리케이션의 Redirect URL로 돌아와야 합니다. 이후 이 코드를 Access Token으로 교환하므로 여러 번의 리디렉션이 발생합니다.

각 방식의 장단점

Service Account 인증

  • 장점
    • 사용자 개입 없이 인증을 자동화할 수 있습니다.
    • 서버 간 통신에 적합합니다.
    • 구현이 비교적 단순합니다.
  • 단점
    • 민감한 JSON 키 파일을 안전하게 관리해야 합니다.
    • 사용자 맥락이 필요한 작업에는 적합하지 않습니다.

OAuth 2.0 Client 인증

  • 장점
    • 사용자 동의에 기반한 안전한 인증 절차입니다.
    • 사용자 맥락이 필요한 작업에 적합합니다.
    • 토큰 갱신과 권한을 관리하기 쉽습니다.
  • 단점
    • 인증 흐름과 구현이 더 복잡합니다.
    • 사용자 개입이 필요해 자동화에 제약이 있습니다.

적절한 사용 사례

  • Service Account 인증
    • 서버 간 통신이 필요할 때
    • 백그라운드 작업이나 배치 프로세스를 실행할 때
  • OAuth 2.0 Client 인증
    • 사용자 데이터에 접근해야 하는 웹 또는 모바일 애플리케이션
    • 사용자마다 다른 권한이 필요할 때
    • 서드파티 애플리케이션에 제한된 접근 권한을 부여할 때