앱 외주개발 Google OAuth 인수: 도메인·리디렉션 URI·동의 화면을 나누는 5가지 기준

앱 외주개발 Google OAuth 인수: 도메인·리디렉션 URI·동의 화면을 나누는 5가지 기준

앱 외주개발이 끝난 뒤 Google 로그인 기능이 남아 있다면, “OAuth client ID를 받았다”는 확인만으로 운영 인수가 끝났다고 보기 어렵습니다. Cloud 프로젝트의 소유·복구 권한, 승인 도메인, 웹 콜백 주소, 사용자가 보는 동의 화면, 토큰을 실제로 쓰는 서버 또는 앱 흐름은 서로 다른 대상입니다. 목록 한 줄에 묶으면 어느 항목이 확인됐고 어느 항목이 빠졌는지 알기 어려워집니다.

Google의 웹 서버 OAuth 안내는 redirect_uri가 등록된 승인 URI 중 하나와 정확히 일치해야 하며 scheme·대소문자·마지막 슬래시도 일치해야 한다고 설명합니다(C001). OAuth 정책은 웹 앱이 소유하거나 사용 권한이 있는 도메인만 redirect URI와 JavaScript origin에 사용해야 한다고 안내합니다(C002).

Google Cloud의 OAuth 앱 브랜딩 문서는 프로젝트에서 쓰는 도메인을 승인 도메인으로 사전 등록하도록 설명합니다(C003). 이 글은 특정 프로젝트의 설정값이나 외주 계약의 책임 범위를 확인한 결과는 아닙니다.

먼저 답하기: OAuth 인수는 client ID 전달이 아니라 프로젝트·도메인·콜백·동의 화면·운영 경로를 각각 확인하는 일입니다

우선 로그인 버튼이 보인다는 관찰과, 조직이 로그인 기능을 변경·복구할 수 있다는 상태를 분리하세요. 인수표에는 비밀값을 적지 말고 프로젝트 식별 정보, 소유 조직, 현재 관리자 역할, 승인 도메인, 등록된 URI의 목적, 연결된 배포 환경, 마지막 제한 검증일과 복구 담당을 남깁니다. 아직 모르는 항목은 빈칸이나 확인 필요로 두어야 합니다. 그 빈칸을 추측으로 채우면 인수 기록이 오히려 오해를 만들 수 있습니다.

이 표는 모든 Google 로그인 구현에 동일한 권한을 요구하는 양식이 아닙니다. 웹 서버, Android, iOS처럼 앱 유형에 따라 등록 항목과 검증 방식은 달라질 수 있습니다. 목적은 각 항목의 실제 설정을 대신 결정하는 것이 아니라, 인수 완료라는 말에 섞이기 쉬운 대상을 구분하는 데 있습니다.

기준 1: 프로젝트 소유와 OAuth client 설정을 같은 것으로 보지 않습니다

OAuth client는 애플리케이션을 식별하는 자격 증명이고, 이를 관리하는 Cloud 프로젝트는 별도의 운영 단위입니다(C001). 따라서 client ID가 보인다고 해서 조직이 프로젝트의 관리자·복구 권한을 확보했다는 뜻은 아닙니다.

먼저 현재 프로젝트가 어느 조직 또는 계정에 속하는지, 새 운영자가 어떤 역할로 클라이언트와 동의 화면을 확인할 수 있는지, 결제·도메인·지원 연락처의 변경 경로가 누구에게 있는지를 실제 콘솔과 조직의 승인 절차로 확인하세요.

여기서 개인 계정 이메일, client secret, refresh token을 인수 문서에 복사하지 않는 것이 중요합니다. 값 자체가 아닌 ‘보관 위치’, ‘접근 승인자’, ‘연결된 서비스’, ‘교체 또는 폐기 판단 상태’를 남기면 노출 위험을 늘리지 않고도 인수 진행을 구분할 수 있습니다.

기준 2: 승인 도메인과 제품의 공개 주소를 별도 목록으로 대조합니다

OAuth 정책은 redirect URI와 JavaScript origin에 소유하거나 사용 권한이 있는 도메인을 사용하도록 안내합니다(C002). Cloud OAuth 앱 브랜딩 안내도 브랜딩 페이지나 client 설정 페이지에서 쓰는 도메인을 승인 도메인으로 사전 등록하도록 설명합니다(C003).

이는 어떤 도메인이 자동으로 적합하다는 뜻이 아닙니다. 실제 서비스의 홈페이지, 개인정보처리방침, 콜백, 테스트·운영 환경 주소가 무엇인지 먼저 모은 뒤 등록 상태와 소유 확인 상태를 한 항목씩 비교해야 합니다.

외주 기간에 쓰던 임시 도메인이나 개발자 개인 소유 도메인이 남아 있을 수 있습니다. 이를 발견했다고 즉시 제거하는 것이 정답이라고 단정할 수는 없습니다. 해당 주소를 호출하는 배포 환경·테스트·사용자 흐름이 있는지와, 변경 후 되돌릴 방법을 확인한 뒤 교체 순서를 정하세요.

우리 앱 운영 인수 범위 점검하기

기준 3: 리디렉션 URI는 ‘도메인 일치’가 아니라 등록값과 실제 흐름의 정확한 대조가 필요합니다

웹 서버 OAuth에서는 인증 후 사용자가 돌아오는 redirect_uri가 승인된 URI와 정확히 일치해야 합니다(C001). 그래서 https와 http, 대소문자, 경로, 마지막 슬래시 차이는 단순 표기 문제가 아니라 로그인 실패로 이어질 수 있는 점검 대상입니다. 반대로 URI 목록을 문서에 복사했다고 해서 실제 배포 환경이 그 경로를 사용한다는 증거가 되지는 않습니다.

인수 시에는 ‘등록 URI → 호출하는 코드 또는 설정 → 실제 배포 환경 → 제한된 로그인·콜백 확인 → 결과 기록’ 순서로 대조합니다. 인증 코드나 토큰 값을 기록할 필요는 없습니다. 테스트 계정과 승인된 범위에서 성공·실패 상태, 확인 시각, 확인한 역할, 다음 조치만 남겨도 설정 변경과 관찰 결과를 분리할 수 있습니다.

기준 4: 동의 화면의 보이는 정보와 실제 데이터 사용 설명을 함께 확인합니다

사용자는 로그인 또는 권한 부여 과정에서 앱 이름, 지원 정보, 링크를 볼 수 있습니다. Google Cloud의 브랜딩 안내는 개인정보처리방침을 홈페이지와 OAuth 동의 화면에 연결하고, Google 사용자 데이터의 접근·사용·저장·공유 방식을 공개 정책에 설명하도록 안내합니다(C003). 이는 독자의 앱이 특정 범위의 검증을 반드시 통과한다는 보장이 아니라, 보이는 동의 화면과 공개된 안내가 서로 어긋나지 않는지 확인해야 한다는 근거입니다.

외주 종료 때는 앱 이름이나 로고만 바꾸고 지원 이메일·홈페이지·개인정보처리방침 링크가 이전 운영 주체를 가리키는 경우를 따로 찾으세요. 문구 변경과 실제 데이터 흐름 검토, 도메인 소유 확인은 같은 완료 신호가 아닙니다. 각각의 근거와 변경 승인자를 분리해 기록해야 나중에 누가 무엇을 확인했는지 되짚을 수 있습니다.

기준 5: 권한 축소는 새 운영 경로의 제한 검증 뒤에 판단합니다

새 담당자가 콘솔에 들어갈 수 있고, 필요한 환경에서 로그인과 콜백을 확인하며, 장애 때 확인할 로그와 되돌리기 경로를 알고 있는지까지 점검한 뒤에 외주 인력의 접근 축소 시점을 판단하세요. 최소 권한 원칙은 중요하지만 실제 계약의 유지보수 약속, 배포 책임, 긴급 대응 창구를 보지 않고 일괄 삭제하면 다른 운영 위험이 생길 수 있습니다.

계정·비밀값·자동화까지 포함한 넓은 인수 기록이 필요하다면 앱 외주개발 서비스 계정 인수: 소유권·권한·비밀값 교체를 나누는 5가지 기준도 함께 보세요. 그 글은 사람 계정과 서비스 계정의 인수 범위를, 현재 글은 Google OAuth의 도메인·URI·동의 화면·운영 경로를 구분합니다.

우리 앱 운영 인수 범위 점검하기

인수 직전에 남길 최소 기록

• 프로젝트 소유 조직, 현재 관리자 역할, 복구 담당

• 승인 도메인과 홈페이지·정책 링크·운영 도메인의 대조 상태

• 등록 리디렉션 URI의 목적과 실제 환경별 콜백 확인 결과

• 동의 화면의 앱 정보·지원 연락처·공개 정책 링크 확인일

• 외주 접근 변경 전 필요한 계약·장애 대응·되돌리기 확인

이 기록은 OAuth 설정이 완벽하거나 로그인 장애가 발생하지 않는다는 선언이 아닙니다. 확인한 사실, 아직 확인하지 못한 의존성, 실제 변경을 위한 승인과 검증 결과를 분리하는 운영 메모입니다. 사용하는 앱 유형과 API 범위, 코드와 인프라, 조직의 보안·개인정보 절차는 최신 공급자 문서와 함께 별도로 검토하세요.

자주 묻는 질문

외주사가 OAuth client ID를 전달하면 인수가 끝난 건가요?

아닙니다. client ID 확인은 한 항목일 뿐입니다. 프로젝트 소유와 복구 권한, 승인 도메인, 실제 리디렉션 URI, 동의 화면 정보, 토큰을 쓰는 운영 경로를 각각 확인해야 합니다.

리디렉션 URI는 도메인만 같으면 되나요?

아닙니다. Google 웹 서버 OAuth 문서는 scheme, 대소문자, trailing slash까지 승인된 URI와 정확히 일치해야 한다고 설명합니다. 실제 등록값과 배포된 콜백 경로를 따로 대조하세요.

외주 개발자의 프로젝트 권한을 바로 삭제해도 되나요?

새 운영자가 필요한 설정을 확인하고 제한된 로그인·콜백 검증을 마치기 전에는 삭제 시점이 이르다고 단정하기 어렵습니다. 계약상 지원 범위와 장애 복구 경로를 확인한 뒤 변경 순서를 남기세요.

이 체크리스트를 따르면 로그인 장애나 보안 문제가 없어지나요?

아닙니다. 이 글은 인수 대상을 분리해 기록하는 틀입니다. 사용하는 OAuth 유형, 실제 코드와 인프라, 계약과 조직의 보안 절차에 맞춰 별도 검토가 필요합니다.

출처: Google OAuth 2.0 웹 서버 애플리케이션, Google OAuth 2.0 정책, Google Cloud OAuth 앱 브랜딩 관리