OAuth provider 약관 정본 관리
Google Sign-In 같은 OAuth provider를 붙일 때 공식 약관, 사용자 데이터 정책, 검증 요구사항, 동의 화면 증빙을 버전으로 고정하는 운영 가이드
핵심 요약
- OAuth provider는 단순 로그인 버튼이 아니라 식별정보·이메일·프로필·refresh token·API scope가 함께 움직이므로 약관·개인정보·보안 운영의 경계가 생깁니다.
- Google 기준 API 약관, 사용자 데이터 정책, OAuth 2.0 정책, 검증 요구사항을 URL·문서명·확인일·적용 client ID와 함께 정본으로 고정합니다.
- 인증 전용(
openid email profile)과 사용자 데이터 API(Gmail·Drive·Calendar) scope를 분리하고, 후자는 scope justification·demo video·보안 평가까지 검토합니다. - privacy policy 문구보다 실제 설정이 우선이라, consent screen·scope inventory·코드 설정을 같은 버전으로 맞춰야 검증·감사에 대응할 수 있습니다.
- dev/staging/production project와 client를 분리하고, 연동 해제·token revoke·데이터 삭제 경로를 사용자 설정에 제공합니다.
- 적용: Google Sign-In, Google OAuth, GitHub, Microsoft, Apple, Slack 등 외부 identity/API provider
- 핵심 이슈: provider 공식 약관 정본, 개인정보 처리방침 반영, scope 최소화, 검증/브랜딩 요건, 동의 화면 증빙
- 산출물: provider 약관 정본 목록 + scope inventory + OAuth consent screen 캡처 + 개인정보 처리방침 반영표
OAuth provider는 단순한 "로그인 버튼"이 아닙니다. 사용자 식별정보, 이메일, 프로필, refresh token, 연동 API scope가 함께 따라오기 때문에 약관/개인정보/보안 운영의 경계가 생깁니다.
면책조항
이 문서는 운영 체크리스트/가이드이며, 법률 자문을 대체하지 않습니다. OAuth provider의 약관, 개인정보 정책, API 정책은 수시로 바뀌니 운영에 반영하기 전에 최신 공식 문서와 법무/개인정보 검토를 함께 확인하세요.
기준일: 2026년 6월 2일
한 줄 정의
Google 같은 OAuth provider를 사용할 때, provider의 공식 약관 정본과 우리 서비스의 개인정보 고지/동의/보안 운영을 같은 버전으로 묶어 관리하는 절차입니다.
언제 필요한가
- "Google로 로그인", "Continue with Google" 같은 소셜 로그인을 제공하는 경우
- Google Drive, Gmail, Calendar, Photos 등 사용자 데이터 API scope를 요청하는 경우
- OAuth app verification, brand verification, sensitive/restricted scope review가 필요한 경우
- provider 약관/정책 변경이 우리 개인정보 처리방침, 동의 화면, 보안 운영에 영향을 줄 수 있는 경우
정본으로 관리할 문서 세트
OAuth provider별로 최소 아래 항목을 내부 저장소에 링크와 기준일로 고정하세요.
| 문서 | Google 기준 정본 | 운영상 의미 |
|---|---|---|
| API 기본 약관 | Google APIs Terms of Service | API 사용, developer credential, privacy policy, 책임/준거법 기준 |
| 사용자 데이터 정책 | Google API Services User Data Policy | Google user data 접근·사용·공유·보안 제한 |
| OAuth 정책 | OAuth 2.0 Policies | OAuth client 등록, 테스트/운영 project 분리, contact, redirect/origin 기준 |
| 검증 요구사항 | Verification requirements | brand verification, sensitive/restricted scope review, demo video, scope justification |
| OAuth client 관리 | Manage OAuth Clients | authorized domain, redirect URI, client secret, inactive client, 플랫폼별 client 관리 |
| OAuth app verification | OAuth App Verification Help Center | 검증 필요 여부, scope 분류, unverified app warning 대응 |
정본은 링크만으로 부족합니다
약관 페이지 URL, 문서명, last modified/last updated, 확인일, 담당자, 적용 중인 OAuth client ID, 사용 scope를 함께 남기세요. 링크만 저장해두면 나중에 "동의 당시 어떤 정책을 기준으로 운영했는지"를 설명하기 어렵습니다.
Google OAuth 실무 기준
Google 공식 문서 기준으로 운영자가 놓치기 쉬운 항목은 아래입니다.
| 항목 | 운영 판단 |
|---|---|
| 약관 적용 범위 | Google OAuth 2.0 사용은 Google APIs Terms, Google API Services User Data Policy, OAuth 2.0 Policies를 함께 봅니다. |
| OAuth client | 플랫폼별 web/iOS/Android/native client를 분리하고, dev/staging/production project를 분리합니다. |
| 공개 앱 | 외부 사용자에게 공개되는 앱은 verification 필요 여부를 먼저 판단합니다. |
| scope | openid email profile만 쓰는 로그인인지, Gmail/Drive/Calendar 같은 user data scope를 요청하는지 분리합니다. |
| sensitive/restricted scope | scope justification, demo video, data handling, annual security assessment 가능성을 검토합니다. |
| 개인정보 처리방침 | 수집 항목, 이용 목적, 공유/이전, 보관/삭제, user data 사용 제한을 실제 동작과 맞춥니다. |
| 브랜딩 | Google 로그인 버튼, 앱 이름, 홈페이지, support email, privacy policy, terms URL이 consent screen과 일치해야 합니다. |
| 보안 | client secret은 secret manager에 보관하고, redirect URI/origin은 소유·허가된 도메인만 사용합니다. |
로그인만 쓰는 경우와 API 권한을 쓰는 경우
가장 먼저 아래 두 가지를 분리하세요.
| 구분 | 예시 scope | 약관/개인정보 처리 포인트 |
|---|---|---|
| 인증 전용 | openid, email, profile | 식별자, 이메일, 프로필 정보를 어떤 목적으로 저장하는지 고지 |
| 사용자 데이터 API | Gmail, Drive, Calendar, Photos 등 product scope | Google User Data Policy, product-specific policy, 검증, limited use, 보안 평가 가능성까지 검토 |
인증 전용이라도 개인정보 수집·이용 동의와 처리방침에 "Google 계정으로 로그인하는 경우"의 수집 항목과 목적을 적어두는 편이 안전합니다. API 권한까지 요청한다면 처리방침 문구만으로는 부족하고 scope별 사용 목적, 저장 여부, 공유 여부, 삭제 경로까지 정리해야 합니다.
provider inventory 템플릿
OAuth provider를 도입할 때 아래 표를 운영 문서로 남기세요.
| 항목 | 기록값 |
|---|---|
| provider | Google |
| 서비스 기능 | 소셜 로그인, Google Drive 파일 가져오기 등 |
| OAuth client/project | production project, web client, iOS client, Android client |
| 사용 scope | openid email profile 또는 product scope 전체 |
| 수집/저장 항목 | sub, email, name, avatar URL, access token 저장 여부, refresh token 저장 여부 |
| 이용 목적 | 로그인, 계정 연결, 파일 가져오기, 일정 동기화 등 |
| 사용자 고지 위치 | 개인정보 처리방침, 수집·이용 동의, OAuth consent screen, 설정 화면 |
| provider 정본 | 약관 URL, 사용자 데이터 정책 URL, OAuth 정책 URL, 확인일 |
| 검증 상태 | not published, needs verification, verified, internal only 등 |
| 삭제/철회 경로 | 계정 연결 해제, token revoke, 내부 데이터 삭제, Google Account 권한 회수 안내 |
개인정보 처리방침에 반영할 문구 초안
아래는 Google 로그인/연동을 쓰는 서비스가 처리방침에 넣을 수 있는 뼈대입니다. 실제 scope와 데이터 흐름에 맞춰 줄이거나 늘리세요.
회사는 Google 계정을 통한 로그인 또는 Google API 연동 기능을 제공할 수 있습니다.
이 경우 회사는 이용자의 동의를 받아 Google 계정 식별자, 이메일 주소, 프로필 정보 및 이용자가
허용한 API scope 범위 내의 정보를 처리할 수 있습니다.
회사는 Google API를 통해 받은 정보를 서비스 제공 및 이용자가 요청한 기능 제공 목적 범위에서만
사용하며, 법령상 근거 또는 이용자의 별도 동의 없이 광고, 신용평가, 정보 중개 등 다른 목적으로
판매하거나 제공하지 않습니다.
이용자는 서비스 설정 또는 Google 계정 권한 관리 화면에서 연동을 해제할 수 있으며, 회사는 연동
해제 또는 회원 탈퇴 시 내부 정책 및 관계 법령에 따른 보존 기간을 제외하고 관련 정보를 삭제합니다.문구보다 실제 설정이 먼저입니다
privacy policy에는 "최소 scope만 요청한다"고 적어놓고 실제 OAuth client가 더 넓은 scope를 요청하면 검증, 민원, 감사 어느 쪽에서도 취약합니다. 문구와 consent screen, scope inventory, 코드 설정을 같은 버전으로 맞추세요.
검증 제출 전에 확인할 것
Google OAuth app verification을 준비할 때는 아래 항목을 먼저 맞춥니다.
- 앱 이름, 로고, support email, homepage, privacy policy URL, terms URL이 실제 서비스와 일치하는가
- Authorized domain과 redirect URI/origin이 소유·관리 가능한 도메인인가
- dev/staging/test OAuth client가 production consent screen과 섞이지 않았는가
- scope별 기능 화면과 사용자 이익을 설명할 수 있는가
- demo video가 OAuth grant flow, consent screen, scope가 쓰이는 기능을 끝까지 보여주는가
- sensitive/restricted scope의 limited use, human access, transfer restriction, secure data handling을 내부 정책으로 통제하는가
- 사용자 설정 화면에 연동 해제, 계정 연결 상태, 데이터 삭제 요청 경로가 있는가
운영 체크리스트
- provider별 정본 링크, 확인일, last modified/last updated를 저장했다.
- OAuth client ID와 platform(web/iOS/Android/native)을 구분했다.
- dev/staging/production project를 분리했다.
- scope inventory와 코드 설정, consent screen이 일치한다.
- 개인정보 수집·이용 동의와 처리방침에 provider 로그인/연동 수집 항목을 반영했다.
- Google user data를 광고, data broker, credit scoring 등 금지 목적에 쓰지 않는다는 내부 통제를 문서화했다.
- refresh token 또는 long-lived credential 저장 여부와 암호화/접근권한/삭제 정책을 점검했다.
- 연동 해제와 provider 권한 회수 안내가 사용자 설정 또는 FAQ에 있다.
- provider 정책 변경 알림을 받을 project contact가 최신이다.
- 반기 또는 연 1회 provider 약관 정본과 scope 사용 현황을 재검증한다.