서버 투 서버 어플리케이션에 OAuth 2.0사용하기 Google API


Using OAuth 2.0 for Server to Server Applications


중요: 구글 클라우드 플랫폼으로 작업하면 자체적인 클라이언트 라이브러리를 작성할게 아니면, 서비스 계정과 클라우드 클라이언트 라이브러리를 사용한다. 더 자세한 사항은 구글 클라우드 플랫폼 문서의 인증 오버뷰를 살펴본다.

구글 OAuth 2.0 시스템은 웹 어플리케이션과 구글 서비스와 같은 사이에 서버 투 서버 상호작용을 지원한다. 이런 시니라오에서는 각 엔드 유져 대신에 어플리케이션을 가진 계정인 서비스 계정이 필요하다. 서비스 계정에 일부로 구글 API를 호출하고 사용자는 직접적으로 연계되지 않는다. 이 시나리오는 간혹 "투 레그드 OAuth" 또는 2LO라고 불린다. (The related term "three-legged OAuth" refers to scenarios in which your application calls Google APIs on behalf of end users, and in which user consent is sometimes required.)

전형적으로 어플리케이션은 사용자 데이터 대신에 자체적인 데이터와 구글 API를 사용하는 어플리케이션에서 사용한다. 예를 들어, 어플리케이션이 구글 클라우드 데이터스토어를 데이터 유지를 위해 사용하면 구글 클라우드 데이터스토어 API를 호출하기 위해 서비스 계정을 사용한다.

G수트 도메인 관리자는 또한 도메인 범위 인증을 받아 도메인내의 사용자에게 사용자 데이터를 접근하기도 한다.

This document describes how an application can complete the server-to-server OAuth 2.0 flow by using either a Google APIs client library (recommended) or HTTP.

With some Google APIs, you can make authorized API calls using a signed JWT instead of using OAuth 2.0, which can save you a network request. See Addendum: Service account authorization without OAuth.

오버뷰

서버 투 서버 인터렉션을 지원하려면 먼저 API콘솔에서 프로젝트에 대한 서비스 계정을 생성한다. G수트 도메인 내의 사용자에 대한 사용자 데이터를 얻으려면 서비스 계정에 도메인 범위 접근을 델리게이트한다

어플리케이션은 서비스 계정의 크레덴셜을 사용해 인증된 API 호출을 수행하며 OAuth 2.0 인증 서버에서 접근 토큰을 요청한다.

결국, 어플리케이션은 구글 API를 호출하기 위한 접근 토큰을 사용한다.

Recommendation: Your application can complete these tasks either by using the Google APIs client library for your language, or by directly interacting with the OAuth 2.0 system using HTTP. However, the mechanics of server-to-server authentication interactions require applications to create and cryptographically sign JSON Web Tokens (JWTs), and it's easy to make serious errors that can have a severe impact on the security of your application.

For this reason, we strongly encourage you to use libraries, such as the Google APIs client libraries, that abstract the cryptography away from your application code.

서비스 계정 생성하기

서비스 계정의 크레덴셜은 생성된 이메일 주소를 포함하는데 유일하며 최소한 하나의 공개/개인 키 짝이 있어야 한다. 만약 도메인 범위 델리게이션이 활성화되면 클라이언트 아이디는 서비스 계정의 크레덴셜의 일부이다.

만약 어플리케이션이 구글 앱 엔진을 실행하면 서비스 계정은 프로젝트를 생성할 때 자동적으로 서비스 계정이 설정된다.

만약 어플리케이션이 구글 컴퓨트 엔진을 실행하면 서비스 계정은 프로젝트를 생성하면 자동적으로 설정되지만, 어플리케이션이 필요한 범위를 반드시 지정해야 한다. 더 자세한 사항은 서비스 계정을 사용하기 위해 인스턴스 준비하기 부분을 살펴본다.

만약 어플리케이션이 구글 앱 엔진이나 구글 컴퓨터 엔진을 실행하지 않으면 구글 API콘설에서 이들 크레덴셜을 얻어야 한다. 서비스 계정 크레덴셜을 생성하려면 다음을 수행한다.

1. 서비스 계정 페이지를 열고 프로젝트를 선택한다.
2. 서비스 계정 생성을 클릭한다.
3. 서비스 계정 생성 윈도우 에서 서비스 계정의 이름을 입력하고 새로운 개인키 퍼니쉬를 선택한다. 만약 G수트 도메인 범위 인증을 원하면 G 수트 도메인 범위 델리게이션을 선택한다. 그리고 저장한다.

새로운 공개/개인키 짝이 생성되었고 다운로드 되었다. 이 것은 이키의 유일한 복사본이다. 안전하게 저장한다.

API콘솔로 돌아가 이메일주소, 공개 키 지문, 그리고 다른 정보를 확인하거나 추가적인 공개/개인 키 짝을 생성할 수 있다. API콘솔에서의 서비스 계정 크레덴셜에 대한 세부사항은 API콘솔 도움말 파일내의 서비스 계정을 살펴본다.

서비스 계정의 이메일 주소와 서비스 계정의 P12 개인키 파일을 어플리케이션이 접근가능한 곳에 저장한다. 어플리케이션은 인증된 API호출을 위해 이들을 사용한다.

Note: You must store and manage private keys securely in both development and production environments. Google does not keep a copy of your private keys, only your public keys.

서비스 계정에 도메인 범위 인증 델리게이트하기

만약 G수트 도메인을 가진다면 G수트 도메인의 관리자는 G수트 도메잉ㄴ의 사용자의 일부로서 사용자 데이터에 접근하기 위해 인증할 수 있다. 예를 들어, 어플리케이션이 구글 캘린더 API를 사용하며 G수트 도메인의 모든 사용자의 캘린더에 이벤트를 추가한다면 서비스 계정을 사용해 사용자의 일부상의 구글 캘린더 API에 접근한다. 도메인 내의 사용자의 일부에서 데이터에 접근할 서비스 계정을 인증하는 것은 서비스 계정에 도메인 범위 인증 위임이라 불린다.

Note: When you use G Suite Marketplace to install an application for your domain, the required permissions are automatically granted to the application during installation. You do not need to manually authorize the service accounts that the application uses. The account must have domain-wide delegation before the application is installed.

Note: Although you can use service accounts in applications that run from a G Suite domain, service accounts are not members of your G Suite account and aren’t subject to domain policies set by G Suite administrators. For example, a policy set in the G Suite admin console to restrict the ability of G Suite end users to share documents outside of the domain would not apply to service accounts.

To delegate domain-wide authority to a service account, first enable domain-wide delegation for an existing service account in the Service accounts page or create a new service account with domain-wide delegation enabled.

Then, an administrator of the G Suite domain must complete the following steps:

Go to your G Suite domain’s Admin console.
Select Security from the list of controls. If you don't see Security listed, select More controls from the gray bar at the bottom of the page, then select Security from the list of controls. If you can't see the controls, make sure you're signed in as an administrator for the domain.
Select Show more and then Advanced settings from the list of options.
Select Manage API client access in the Authentication section.
In the Client Name field enter the service account's Client ID. You can find your service account's client ID in the Service accounts page.
In the One or More API Scopes field enter the list of scopes that your application should be granted access to. For example, if your application needs domain-wide access to the Google Drive API and the Google Calendar API, enter: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
Click Authorize.
Your application now has the authority to make API calls as users in your domain (to "impersonate" users). When you prepare to make authorized API calls, you specify the user to impersonate.

인증된 API호출 생성 준비하기


덧글

댓글 입력 영역