당신은 구글 시그니인을 쉽게 통합할 것으로 생각했을 것입니다. 그러나 인증 화면을 보면서 하나의 앱 유형이 클라이언트 시크릿을 제공하고 다른 하나는 제공하지 않는 이유를 이해하고 싶을 것입니다. 이 혼란은 특히 Capacitor, 아이오닉, 일렉트론, 또는 혼합 웹 및 네이티브 스택을 사용하는 경우에 일반적입니다.
실제 구현을 깨는 부분은 대부분의 가이드가 생략하는 것입니다: Google Client IDs는 플랫폼에 따라 다릅니다., 그리고 웹 앱이 아닌 타입은 종종 없습니다. 잘못된 자격 증명을 만들면 비밀 키를 강제로 흐름에 넣으려고 할 때
일반적으로 오류가 발생하는 OAuth 설정을 만들게 됩니다. 이는 디버깅이 더 어려울 수 있습니다.
- 내용목록
- 앱을 Google 생태계와 연결하는 방법
- 실무에서 클라이언트 ID Google의 위치
- 플랫폼별 클라이언트 ID 설정
- 구글 API 자격 증명 보안
- 클라이언트 ID 오류를 해결하는 방법
구글 생태계와 앱을 연결하는 방법
많은 팀이 동시에 이 문제를 겪습니다. 그들은 구글과 함께 로그인하세요또는 사용자 인증을 승인하기 위해 드라이브나 캘린더와 같은 것에 접근하고자 할 때, suddenly API 키가 더 이상 충분하지 않습니다.
사용자 로그인 및 위임된 접근이 OAuth를 통해 실행되기 때문입니다. 구글이 앱을 식별할 수 있는 방법이 필요합니다.그것은 API가 호출되는 것만이 아닙니다. 구글 클라이언트 ID가 그 역할을 합니다..
다중 플랫폼 코드베이스에서 작업 중이라면 혼란이 빨리 심해집니다. 웹 프론트엔드, 안드로이드 셸, iOS 앱, 그리고 데스크톱용 일렉트론 빌드가 공유할 수 있습니다. 그들은 제품 브랜딩과 백엔드 논리도 공유할 수 있지만, OAuth 식별성을 공유해서는 안 됩니다.
실용적인 OAuth 설정은 몇 가지 구현 질문으로 귀결됩니다.
- 어떤 애플리케이션 유형을 생성해야 합니까?
- 클라이언트 시크릿이 필요합니까?
- redirect URI 또는 origin이 정확히 일치해야 하는지
- 모바일 및 웹 흐름을 연결하는 방법은 어떻게 해야 합니까? credential을 섞어서는 안 됩니다.
- 브라우저에서 작동하는 흐름이 네이티브 래퍼 내에서 실패하는 이유
실용적인 규칙: If your app is asking for user permission or sign-in, start by thinking in OAuth client types, not API keys.
이 distinction은 시간을 절약하고, 웹 인증서만으로 모바일 로그인 흐름을 구축하는 일반적인 오류를 방지합니다. Capacitor 앱에서 이 기능을 구현하는 경우, 이 Capacitor 앱에서 OAuth2를 구현하는 방법에 대한 이 안내서 OAuth2 in Capacitor 앱 Google Client ID란
Google OAuth 2.0 클라이언트 ID
Google 인증 시스템 내에서 애플리케이션의 공개 식별자입니다. Google은 앱이 Google 인증 엔드포인트에서 접근 토큰을 요청할 때 사용하는 고유한 사용자 이름으로 설명하며, __CAPGO_KEEP_0__ 키와는 구별되는 점은 OAuth 흐름에서 앱의 신원을 확인하는 데 사용되는 보안 계층으로 작용한다는 것입니다. Google Cloud의 OAuth 클라이언트 문서에서 자세히 설명하고 있습니다. Google Client ID는 애플리케이션의 고유 식별자와 보안 계층으로 작용하는 다이어그램 is the public identifier for your application in Google’s auth system. Google describes it as the unique username for an application when requesting access tokens from Google authentication endpoints, and notes that it’s distinct from API keys because it’s used in OAuth flows to verify the app’s identity during token exchange, as explained in Google Client ID는 앱의 신원을 확인하는 데 사용되는 보안 계층으로 작용하는 다이어그램.
간단한 정신 모델
앱의 Google 클라이언트 ID 문제를 앱의 공개된 사용자 이름.
Google에
이 요청은 이 등록된 애플리케이션에서 오는 것입니다.
이것은 로그인, 동의, 토큰 교환 및 사용자가 앱이 대신 행동하도록 요청하는 모든 흐름에서 중요합니다. 클라이언트 ID는 앱과 Google의 인증 서버 모두가 참조해야 하는 것을 의미합니다.
API key identifies a project for certain API calls that don’t involve delegated user authorization.
OAuth에서 앱을 식별합니다. 은 비밀을 안전하게 유지할 수 있는 흐름과 앱 유형에서만 사용되는 비밀 counterpart입니다.
많은 깨진 통합은 이러한 것들을 동일한 것으로 다루는 사람들 때문에 시작됩니다. 그들은 아님.
실제로 클라이언트 ID Google은 어디에 위치하는지
만약에 구글로 로그인 또는 구글 로그인클라이언트 ID는 frontend에서 인증 핸드셰이크를 시작하기 위해 사용하는 값입니다.
구글의 문서에도 웹 앱은 전체 스킴과 호스트 이름을 포함한 인증된 JavaScript 원본을 구성하거나 리다이렉트 URI를 구성해야 한다고 언급하고 있습니다.
그것이为什么 설정이 단순한 키를 생성하는 것보다 더 엄격하게 느껴지는 이유입니다.
- 구글은 단순히 접근을 허용하는 것이 아니라 인증 요청을 알려진 앱 식별자와 결합하는 것입니다.
- 하이브리드 앱을 개발하는 팀에게 가장 안전한 정신 모델은 다음과 같습니다:
- 정확한 앱 유형을 사용하여 비밀을 흐름에 포함시킬지 결정하세요.
앱 식별성과 위임된 접근 권한이 어떻게 연결되는지 더 넓은 개요를 원한다면, 이 앱 인증화의 안내서 앱 식별자 및 위임된 접근 권한을 연결하는 방법에 대한 개요입니다.
클라이언트 ID를 만들고 보는 방법
콘솔 경로가 변경되었습니다. 개발자는 종종 잘못된 곳에 있다고 생각합니다. Google은 현재 두 가지 네비게이션 경로를 이러한 자격 증명에 노출하고 있습니다: 새로운 Google Auth Platform > Clients 경로와 더 오래된 APIs & Services > Credentials 경로, Google의 설정 문서.
__CAPGO_KEEP_0__
Google Cloud Console에서 시작하여 프로젝트를 선택하거나 생성하세요. 인증 설정을 여러 프로젝트에 흩어지게 하면 후에 감사 및 지원이 고통스러울 것입니다.
그곳에서 다음 중 하나로 이동하세요:
- Google Auth Platform > 클라이언트
- APIs & Services > 자격 증명
If your team sees different navigation labels, that’s expected. Google has been separating identity setup from the rest of the API credential surface.
자격 증명을 생성하세요. 자신을 한정짓지 마세요.
새로운 OAuth 클라이언트를 생성할 때 가장 큰 결정은 애플리케이션 유형입니다. Google은 Web, Android와 같은 특정 유형을 선택하도록 요청합니다. Web, Android, iOS, or 데스크톱. 이 선택은 단순히 외관을 결정하는 것이 아니라 앱의 식별과 필요한 지원 구성에 영향을 미치는 중요한 결정입니다.
웹 앱의 경우 다음 값을 입력할 수 있습니다:
- 인증된 자바스크립트 원본
- 인증된 리다이렉션 URI
이 값은 정확해야 합니다. 웹 자격 증명에 대한 경우, Google은 전체 스킴과 호스트 이름을 기대하며, 예를 들어 https://www.example.com, 대신/loose 도메인 개념이 아닌
모바일 플랫폼의 경우 모양은 다릅니다. Android 등록은 패키지 수준의 식별성과 소유권 확인이 필요하며, iOS는 자신의 플랫폼 식별자를 사용합니다. Google 인증을 다른 인증层와 combination하는 경우 이 Capacitor Supabase의 social login 설정은 이러한 조각이 종종 어떻게 함께 작동하는지 보여주는 유용한 예입니다. 이 social login 설정은 Supabase
이 walkthrough는 UI를 비교하고 클릭하는 동안 사용할 수 있는 합리적인 시각적 참조입니다.
후속 조치
클라이언트 ID는 프로젝트의 자격 증명 목록에 표시됩니다. 동일한 프로젝트 공간은 팀이 API를 활성화하고 OAuth 식별성을-consent 화면에 연결하는 방법도 보여줍니다. 등록된 애플리케이션 이름은 사용자가 허가 요청 시 볼 수 있는 이름입니다. 이는 앱 이름을 정확하게 지정하는 이유 중 하나입니다.
Google은 이러한 자격 증명을 시간이 지남에 따라 관리할 수 있도록 합니다. 클라이언트 ID를 복사하고 설정을 검토하고, 해당 자격 증명과 관련된 클라이언트 시크릿을 관리할 수 있습니다.
consent 화면은 장식이 아닙니다. 그것은 신뢰 경계의 일부입니다. 사용자는 애플리케이션 이름을 볼 수 있습니다. 내부 프로젝트의 별명이 아닙니다.
플랫폼별 클라이언트 ID 구성
Google 로그인 설정을 깨트리기 가장 빠른 방법은 하나의 클라이언트 ID가 모든 플랫폼을 커버할 수 있다고 가정하는 것입니다. 그러나 그것은 할 수 없습니다. 다중 플랫폼 앱의 경우 각 플랫폼은 자신의 DISTINCT OAuth 2.0 클라이언트 ID를 등록해야 하며, Android 설정은 SHA1 지문이 소유권을 확인하기 위해 필요하다는 점을 포함하여 이 플랫폼 설정 참조.
왜 하나의 앱이 여러 클라이언트 ID가 필요합니까
사용자는 앱을 하나로 보지만 Google에선 하나의 앱이 여러 OAuth 클라이언트입니다.
A 웹 앱그것은, an Android 빌드그것은, an iOS 빌드그것은, 그리고 데스크톱 앱 같은 보안 속성을 제공하지 않습니다. 그들은 동일한 방식으로 신원을 증명하지 않으며, 모든 플랫폼이 신뢰할 수 있는 환경에서 자격 증명을 저장하지 않습니다. Google은 각 플랫폼에 독립된 앱 등록 모델을 제공하여 이를 해결합니다.
그것은 좋은 보안 관행입니다. 만약 하나의 플랫폼의 자격 증명 설정이 취약하거나 잘못 구성되었다면 다른 플랫폼은 자동으로 노출되지 않습니다.
다음은 실제적인 분리를 따르는 방법입니다:
- 웹 웹 클라이언트 ID를 사용하고 엄격한 원본 및 리다이렉션 URI 매칭을 사용합니다.
- Android Android 앱 ID는 패키지 식별자와 SHA1 finger print와 연결됩니다.
- iOS iOS 앱 ID는 앱의 번들 식별자와 연결됩니다.
- Desktop or Electron Desktop 스타일 OAuth 패턴을 사용하는 경우, 설치된 OAuth 패턴을 사용하는 경우가 많습니다.
Google Client ID 종류 비교
| 애플리케이션 유형 | 주 식별자 | 클라이언트 시크릿 제공 여부 | 주 용도 |
|---|---|---|---|
| 웹 | 인증된 자바 스크립트 원본 및 리다이렉션 URI | 일반적으로 yes | 브라우저 앱과 백엔드 지원 웹 OAuth |
| Android | 패키지 식별자 + SHA1 지문 | 많은 경우 no | 자연어 Android 로그인 |
| iOS | 앱 번들 식별자 | 많은 경우 no | 자연어 아이폰 및 아이패드 로그인 |
| 데스크톱 | 설치된 앱 식별자 | 가끔은 | 데스크톱 앱, Electron-style 네이티브 흐름 포함 |
모바일 및 데스크톱용 클라이언트 시크릿의 역설
이것은 많은 튜토리얼이 틀린 부분입니다.
모바일 및 데스크톱 개발자들은 일반적으로 OAuth 클라이언트가 클라이언트 ID와 클라이언트 시크릿을 모두 포함하는 것으로 기대합니다. 그들은 콘솔에서 시크릿을 볼 수 있는 유일한 방법이 Web Application credential이기 때문에 Web Application credential을 생성합니다. 흐름이 더 완전하게 보이기 때문에 그들은 계속 진행합니다. 그러나 인증이 혼란스럽게 실패합니다. Web Application credential 클라이언트 ID 클라이언트 시크릿OAuth 클라이언트 인증 이러한 오류
따라서 이 설명은 모바일 인증서 불일치에 대한 것입니다.모바일 인증서 불일치에 대한 설명입니다.
Android, iOS 및 설치된 앱과 같은 웹 앱이 아닌 애플리케이션 유형은 종종 클라이언트 ID만 받고 클라이언트 시크릿을 의도적으로 받지 않습니다. 왜냐하면 구글은 사용자가 클라이언트 측 소프트웨어에서 추출할 수 있는 비밀을 포함하는 클라이언트 측 소프트웨어에 비밀을 포함하지 않으려 하기 때문입니다.
그것은 올바른 디자인 선택입니다. 모바일 앱 또는 Electron 패키지는 안전한 비밀 저장소가 아닙니다.
이것이 작동합니다: 공개 클라이언트를 위한 클라이언트 측 OAuth 흐름.
For Capacitor teams, this usually shows up in one of two bad patterns:
- 모바일 앱에 대한 웹 인증서를 만들어서 implementation에 비밀을 강요하는 것입니다. __CAPGO_KEEP_0__ 팀에게는 일반적으로 두 가지 나쁜 패턴 중 하나가 나타납니다. 앱은 웹 클라이언트를 사용하여 브라우저 기반 흐름을 시작하고 그다음에 비밀을 포함하는 서버와 같이 행동하려고 합니다.
- 앱은 클라이언트 시크릿 code에서 제공하는 패키지에서 code를 얻는 대신, 시크릿이 숨겨져 있는 것을 피하기 위해.
모바일 앱과 데스크톱 앱을 모두 pubic 클라이언트로 다루는 것이 더 낫습니다.
오늘날의 OAuth에서 일반적으로는, 시크릿이 클라이언트 내부에 숨겨져 있는 것을 의존하지 않는 흐름을 사용합니다. 백엔드가 참여하는 경우, 백엔드에서 비밀을 숨기고 클라이언트는 pubic 클라이언트가 해야 하는 것만 수행하도록 합니다. 또 다른 중요한 점은 Firebase-backed Android 로그인 설정에서 중요합니다. 이 경우, 웹 애플리케이션 타입 클라이언트 ID
는 백엔드 서버의 OAuth 클라이언트 ID로 사용되며, Android 앱은 자신의 플랫폼에 특화된 식별자를 유지합니다. 이 분리는 팀이 두 가지 유형의 자격증명(웹 자격증명과 모바일 자격증명)을 같은 프로젝트에서 볼 때 혼란을 일으킵니다. 하나가 다른 것을 대체하는 것으로 착각합니다. 그렇지 않습니다. 그들은 서로 다른 역할을 수행합니다. 만약 하나의 규칙을 기억한다면, code가 실행되는 위치에 맞는 클라이언트 타입을 선택하십시오. code의 형태가 원하는 자격증명과 일치하는 것은 아닙니다..
구글 API 자격증명 보안
오늘날의 OAuth 사고의 대부분은 복잡한 공격이 아닌, 팀이 자격증명을 누설하거나, 리다이렉션 설정을 너무 넓게 설정하거나, __CAPGO_KEEP_0__를 안전하지 않은 곳에 넣는 것입니다.
Google의 OAuth 지침은 클라이언트 ID 및 비밀 키를 개인 데이터로 다루어야 한다고 강조하며 웹 앱의 경우 클라이언트 ID는 미리 등록된 리다이렉트 URI와 일치하는지 확인합니다. 리다이렉트 URI가 엄격하게 일치하지 않으면 Google은 요청을 거부합니다. 이 원본 바인딩은 토큰 중계 방지에 대한 보호 기능의 일부로, OAuth.com의 클라이언트 등록 지침에 설명되어 있습니다. OAuth.com의 클라이언트 등록 지침.
즉시 잠그어야 할 것들
만약에 몇 가지 사항을 올바르게 처리한다면, 다음을 수행하세요:
- Never ship a client secret in app code. 웹 번들, 모바일 바이너리 및 Electron 패키지는 사용자에 의해 검사할 수 있습니다.
- 정확한 리다이렉트 URI를 등록하세요. 가까운 것은 충분하지 않습니다. Google은 웹 흐름에 대해 엄격한 일치 검증을 수행합니다.
- 원본을 단단히 유지하세요. 설치의 마찰을 피하기 위해 광범위한 도메인을 허용하지 마십시오.
- 플랫폼 자격 증명을 분리하세요. 편의성을 위해 안드로이드, iOS, 웹을 하나의 자격 증명으로 밀어내지 마세요.
Google은 기존 클라이언트 ID에 새로운 비밀을 생성하고 이전 비밀을 비활성화할 수 있음을 간과하기 쉬운 운영 상세 정보입니다. 이는 비밀 노출 시나 배포 프로세스를 강화할 때 중요합니다.
보안 팀이 실제로 무엇을 하는지
안전한 팀은 OAuth 자격 증명을 다른 프로덕션 비밀처럼 다루는 팀입니다.
그들은 웹 클라이언트 비밀을 백엔드에 유지하고 환경 관리를 통해 주입하고 콘솔 접근 권한을 감사합니다. 릴리스 PIPELINE을 정리하는 경우, CI/CD PIPELINE에서 비밀 관리에 대한 이 가이드를 적용하는 것도 가치가 있습니다. 그들은 또한 메타데이터를 검토합니다. OAuth 동의 화면은 사용자가 보는 클라이언트 식별과 관련이 있습니다. 애플리케이션 이름이 모호하거나 허위 정보일 경우 사용자는 동의 화면을 신뢰하지 않거나 잘못된 애플리케이션을 승인할 가능성이 높습니다. 보안은 비밀을 숨기기만 하는 것이 아닙니다. 올바른 애플리케이션 식별, 리다이렉트 목적지, 승인 화면이 매번 일치하는지 확인하는 것입니다.
클라이언트 ID 오류를 해결하는 방법
대부분의 Google OAuth 오류는 작은 설정 오류로 인한 것입니다. 오류 메시지는 항상 친절하지 않지만, 문제를 해결하는 데 필요한 정보는 일반적으로 오류 메시지에서 찾을 수 있습니다.
대부분의 오류를 해결하는 방법
https://capgo.dev/ko/blog/client-id-google/
https://capgo.dev/ko/blog/client-id-google/
redirect_uri_mismatch
앱이 등록된 웹 클라이언트와 정확히 일치하지 않는 리다이렉트 URI를 보내고 있습니다. scheme, host, path 및尾隨 차이점을 확인하십시오. 웹 OAuth의 경우 정확한 일치가 보안 모델의 일부입니다.
invalid_client
이 경우 일반적으로 앱이 잘못된 클라이언트 ID를 보내거나, 잘못된 비밀 키를 보내거나, 플랫폼 간에 인증 정보를 혼용하는 경우입니다. 예를 들어 Android 또는 iOS 흐름이 잘못된 위치에서 웹 인증 정보를 사용하는 경우가 있습니다.
invalid_request
이 문제는 광범위하지만, 크로스 플랫폼 앱에서 일반적으로 인증 매개 변수가 잘못된 경우나 클라이언트 유형에 맞지 않는 흐름을 사용하는 경우를指示합니다. 앱이 비밀 키를 포함하려고 할 때, 또는 선택한 OAuth 흐름이 다른 종류의 클라이언트를 기대하는 경우를 확인하십시오.
Google Sign-In은 웹에서 작동하지만 모바일에서 실패합니다.
첫 번째로 검사해야 하는 것은 클라이언트 유형입니다. 모바일 개발자의 가장 일반적인 오류 원인은 웹 애플리케이션 클라이언트 ID를 생성하여 클라이언트 비밀 키를 얻으려고 할 때, 실제로 Android 또는 iOS 유형을 사용해야 하는 경우입니다. 이에 대한 자세한 설명은 클라이언트 비밀 키 일치 오류에서 확인할 수 있습니다. 만약 인증 후 토큰 라이프 사이클 작업이 포함된 경우,
토큰 취소 안내서
도 유용합니다.
Android 인증이 생성된 인증 정보 후에 실패합니다. Android 클라이언트에 첨부된 SHA1 지문이 올바르지 않으면, 앱이 Google이 기대하는 소유권을 증명하지 못합니다. 확인하십시오.
OAuth 설정에서 콘솔에 첨부된 애플리케이션 이름과 브랜딩을 확인하세요. 사용자는那里에서 볼 수 있는 것을 승인하므로 잘못된 메타데이터는 신뢰 문제와 지원 잡음 모두를 생성합니다.
디버깅의 실제 순서는 간단합니다: 클라이언트 유형을 먼저 확인하고, 리다이렉트 설정, 플랫폼 식별자, 그리고 비밀키가 흐름에 포함되어야 하는지 여부를 확인하세요..
팀이 Capacitor 또는 Electron 앱을 배포한다면, 인증 오류는 거의 고립되지 않고, 릴리즈 압박, 롤백 필요, 환경에 따라서 고쳐야 하는 문제와 함께 표면화됩니다. Capgo Capgo는 앱 code 및 자산에 대한 표적 업데이트를 배포하는 팀에게 도움이 됩니다. 스토어 리뷰를 기다리지 않고, 이는 로그인 흐름, 콜백 처리, 클라이언트 측 인증 문제를 수정할 때 생산 환경에서 오류가 발생할 때 더 쉽게 수정할 수 있습니다.
