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

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

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

이 글에서는 사용자가 브라우저에서 권한을 허용하는 웹 서버 방식과, 서버가 서비스 계정으로 API를 호출하는 방식을 비교합니다. 전자는 동의를 마친 사용자가 돌아올 주소인 Redirect URL을 등록하고, 후자는 사용자 화면을 거치지 않고 서버끼리 인증합니다. 서비스 계정 방식도 OAuth 2.0에 속하므로, ’OAuth 사용 여부’보다는 누구의 권한으로 API를 호출하는지를 구분하는 것이 정확합니다.

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

OAuth 2.0 Client ID

Client ID는 어떤 애플리케이션이 권한을 요청하는지 Google이 식별하는 등록값입니다. 이 절에서는 사용자가 브라우저에서 동의하는 흐름을 설명합니다.

OAuth 2.0은 외부 애플리케이션이 사용자의 비밀번호를 받지 않고도, 사용자가 허용한 범위의 데이터에 접근하게 하는 권한 위임 방식입니다. 인증은 ‘누구인지 확인하는 것’, 인가는 ’어떤 작업을 허용할지 결정하는 것’을 뜻하며, OAuth 2.0은 권한 위임을 다룹니다.

1. 사용자 중심: 최종 사용자가 자신의 데이터에 대한 접근을 허용합니다.
2. 위임된 접근: 사용자 비밀번호를 공유하지 않고 특정 리소스에 접근하게 합니다.
3. 토큰 기반: API 호출에 Access Token을 보냅니다. 이 값은 정해진 범위와 유효기간 안에서 요청을 허용하는 자격 정보입니다.
4. 사용자 복귀 주소: 여기서 설명하는 웹 서버 흐름에서는 동의 후 사용자가 돌아올 Redirect URL이 필요합니다.

Service Account

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

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

두 흐름의 핵심 차이는 개별 사용자의 동의와 권한을 사용하는지, 애플리케이션에 부여한 서비스 계정 권한을 사용하는지에 있습니다. 이 사례에서는 사용자가 매번 브라우저에서 동의하지 않아도 서버가 자신의 서비스 계정으로 동작해야 했습니다.

OAuth 2.0 Client 인증

동작 방식: Google 예시

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

이 흐름에서 Google 인증 서버는 로그인과 권한 허용을 처리합니다. Resource Server는 발급받은 Access Token을 확인하고 프로필이나 이메일 등 실제 데이터를 제공하는 API 서버입니다.

Redirect URL

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

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

Service Account 인증

동작 방식

1. 애플리케이션 서버가 서비스 계정의 JSON 키 파일로 JWT(JSON Web Token)에 서명합니다. JWT는 계정과 요청 범위 등의 정보를 담은 문자열이고, 이 경우 서명은 서비스 계정의 자격으로 요청했음을 확인하는 데 사용됩니다. Scope는 ’어떤 API 작업 범위의 권한을 요청하는지’를 나타냅니다.
2. 생성한 JWT를 Google 인증 서버로 전송합니다.
3. Google 인증 서버가 JWT를 검증하고, 유효하면 Access Token을 발급합니다.
4. 애플리케이션 서버는 Access Token을 사용해 Google Resource Server의 데이터에 접근합니다.

JSON 키 파일의 역할

JSON 키 파일에는 Service Account의 인증 정보가 담겨 있습니다. Google Cloud Console에서 발급해 애플리케이션 서버에 저장합니다. 서버는 이 파일의 개인키로 요청 정보를 담은 JWT에 서명하고, Google 인증 서버로 보내 검증받습니다. Scope를 적는 것만으로 권한이 생기는 것은 아니며, 실제 계정에 필요한 권한도 부여되어 있어야 합니다.

Redirect URL이 필요하지 않은 이유

이 서비스 계정 흐름에서는 서버가 서명한 JWT를 보내 Access Token을 발급받습니다. 사용자의 브라우저를 다른 화면으로 이동시키지 않으므로, 사용자가 돌아올 Redirect URL도 필요하지 않습니다.

두 방식의 주요 차이

1. 사용자 개입: 사용자 동의 방식은 브라우저에서 권한을 허용하는 단계가 있지만, 이 서비스 계정 방식은 서버의 자격 정보로 요청합니다.
2. 인증 흐름: 여기서 비교하는 사용자 동의 방식은 복귀 주소 등록과 코드 교환이 필요하지만, 서비스 계정 방식은 서명한 JWT로 토큰을 요청합니다.
3. 관리할 정보: 사용자 동의 방식은 등록한 복귀 주소와 발급받은 토큰 등을 관리합니다. 이 글의 서비스 계정 방식은 토큰 외에 서명에 사용하는 개인키 파일도 관리합니다.
4. 권한의 주체: 사용자 동의 방식은 허용한 개인 사용자의 권한으로, 서비스 계정 방식은 서비스 계정에 부여한 권한으로 API를 호출합니다.

구현 복잡도 비교

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

Redirect URL 사용 방식의 차이

이 글의 서비스 계정 구현은 애플리케이션 서버가 JSON 키 파일로 JWT에 서명하고, Google 인증 서버에 보내 검증받은 뒤 Access Token을 받습니다. 이 예시의 토큰 발급은 브라우저 화면을 거치지 않는 서버 간 요청·응답으로 진행됩니다.

OAuth 2.0 Client 인증에서는 사용자가 브라우저에서 로그인하고 권한을 허용한 다음, Authorization Code와 함께 애플리케이션의 Redirect URL로 돌아와야 합니다. 이후 이 코드를 Access Token으로 교환하므로 사용자의 브라우저 이동과 서버의 토큰 교환이라는 서로 다른 단계가 필요합니다.

각 방식의 장단점

Service Account 인증

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

OAuth 2.0 Client 인증

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

서비스 계정도 OAuth 2.0으로 Access Token을 발급받는다는 점과 JWT 서명 과정은 Google의 서버 간 인증 설명에서 확인할 수 있습니다.

적절한 사용 사례

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