위임된 소셜 로그인 (Google · Apple SSO)

Source: oauth/google-apple-delegation.md · Live: https://docs.1pass.dev/oauth/google-apple-delegation LLM-sanitized: internal links absolutized, VitePress containers → admonitions, line numbers in the Jump-to Index reference this rendered file (1-indexed).

📍 Jump-to Index

• L24-L41: ## 왜 이게 중요한가
• L42-L70: ## logi 를 붙이면
• L71-L82: ## 하는 것 / 안 해도 되는 것
• L83-L100: ## RP 통합 (3단계)
• L101-L107: ## RP 가 받는 identity
• L108-L122: ## 당신의 계정은 당신 것
• L123-L136: ## 주의
• L137-L142: ## 관련 문서

---

위임된 소셜 로그인 (Google · Apple SSO)

💡 Tip: 한 줄 요약 RP 는 Google·Apple 에 자기 앱을 따로 등록할 필요가 없습니다. logi 가 Google/Apple 을 upstream IdP 로 대신 물고 있어서, RP 는 logi 하나만 붙이면 로그인 화면에 "Apple/Google 로 계속" 버튼이 자동으로 제공됩니다.

왜 이게 중요한가

소셜 로그인은 "버튼 하나"처럼 보이지만, RP 가 직접 붙이려면 provider 마다 아래를 전부 해야 합니다. 반나절에서 며칠씩 걸리고, 출시 후에도 계속 운영해야 하는 지점입니다.

Google 직접 구현 시

• Google Cloud 프로젝트 생성 → OAuth Web Client ID 발급
• OAuth Consent Screen 구성 + 게시 심사 (요청 scope 에 따라 Google 검증에 수 주 소요)
• 환경(dev/staging/prod)마다 Authorized redirect URI 관리
• client secret 로테이션 운영

Apple 직접 구현 시

• Apple Developer 계정(유료) + App ID
• Services ID 생성 + 도메인 검증(Return URL·도메인 등록)
• Sign in with Apple 키(.p8) 발급 → client_secret JWT 서명 로직 직접 구현
• private relay 이메일 처리, 키 로테이션

여기에 각 provider 의 id_token 검증(JWKS·iss·aud·exp·nonce), 계정 병합, 키 회전 대응까지 RP 가 직접 떠안아야 합니다.

logi 를 붙이면

logi 서버가 자체 Google/Apple credential 을 소유·운영합니다.

• Google — logi 자체 OAuth Web Client (GOOGLE_WEB_CLIENT_ID / GOOGLE_WEB_CLIENT_SECRET)
• Apple — logi 자체 Services ID (APPLE_WEB_SERVICES_ID) + SIWA 키

사용자가 로그인 화면에서 "Apple/Google 로 계속"을 누르면, 리다이렉트·콜백·id_token 검증(JWKS·iss·aud·exp·nonce)·계정 해석을 전부 logi 가 수행합니다. RP 는 이 과정에 관여하지 않습니다.

RP 가 하는 것은 딱 하나 — logi 와 OAuth(Authorization Code + PKCE) 통합입니다. logi 는 여기까지, 즉 인증(이 사용자가 누구인지 안전하게 증명)만 대행합니다. 받은 sub 를 어디에 저장할지, 생체인증을 걸지, 세션을 어떻게 관리할지, 로그인 화면을 어떻게 그릴지는 RP 앱의 기능 영역이며 SDK 가 관여하지 않습니다.

사용자
  │ "Apple/Google 로 계속"
  ▼
logi  (Google/Apple 을 upstream IdP 로 대행)
  │ ① upstream(Google/Apple) id_token 검증 → 계정 해석
  │ ② logi 자체 id_token 발급 (canonical sub)
  ▼
RP  ← ② logi id_token 수신 → ③ RP 가 검증

🚨 Danger: 검증 레이어는 두 개입니다 — 헷갈리면 계정 탈취로 이어집니다 "id_token 검증을 전부 logi 가 한다"는 upstream(Google/Apple) 토큰(①) 얘기입니다. 그와 별개로, logi 가 RP 에게 발급한 logi id_token(②)은 RP 가 반드시 직접 검증(③)해야 합니다 — 서명(JWKS) · iss · aud(= 내 client_id) · exp · nonce.

특히 aud 검증을 빠뜨리면, 다른 client 용으로 발급된 유효한 logi 토큰을 내 RP 가 받아들여 cross-client 계정 탈취가 됩니다. sub 는 검증을 통과한 뒤에만 신뢰하세요.

👉 이 검증을 직접 구현하지 말고 공식 SDK 를 쓰면 aud·nonce 검증이 기본 내장됩니다: 백엔드는 @logi-auth/server(Node) · logi_auth(Rails) · logi-auth(Django), 클라이언트는 browser · iOS · Android · Flutter. backend 가 있는 confidential RP 는 반드시 서버에서 검증하세요.

하는 것 / 안 해도 되는 것

항목	직접 구현	logi 위임
Google Cloud OAuth Client	RP 가 발급·심사	❌ 불필요 (logi 소유)
Apple Services ID + .p8 키	RP 가 발급·서명	❌ 불필요 (logi 소유)
Consent screen 게시 심사	provider별 대응	❌ 불필요
upstream id_token 검증 (Google/Apple JWKS·nonce)	RP 가 구현	❌ logi 가 처리
키·secret 로테이션	provider별 운영	❌ logi 가 운영
logi id_token 검증 (aud·iss·nonce)	RP 가 구현	⚠️ 여전히 RP 가 검증 (공식 SDK 내장)
RP 가 하는 것	—	✅ logi OAuth 통합 (client_id 하나) + logi id_token 검증

RP 통합 (3단계)

# 1. 개발자 등록
logi developer register --email <dev@example.com> --org "<My Company>"

# 2. 앱 등록 → client_id 발급
logi apps create \
  --name "My App" \
  --redirect-uri https://app.example.com/auth/logi/callback \
  --scope openid profile:basic email \
  --client-type confidential

# 3. Authorization Code + PKCE 로 /oauth/authorize 호출

자세한 흐름은 Quickstart 와 Authorization Code Flow 를 참고하세요. AI 에이전트로 붙이는 경우 에이전트 Quickstart 로 바로 진행할 수 있습니다.

RP 가 받는 identity

사용자가 Google 으로 로그인하든 Apple 로 하든, RP 가 받는 것은 동일한 logi canonical sub 입니다. provider 는 logi 내부 구현 세부사항이고, RP 는 provider 를 구별할 필요가 없습니다 (sub 정책).

• 어떤 소셜만 켤지도 RP 가 고릅니다 — "Google 만", "Apple + Google 만" 처럼 로그인 화면에 노출할 방법을 앱 단위로 on/off → 로그인 방법 제한. (단 이는 화면 노출 제어일 뿐 identity 를 바꾸지 않습니다 — 보안 경계가 아닙니다.)
• upstream SSO 의 내부 메커니즘이 궁금하면 → Web SSO

당신의 계정은 당신 것

logi 를 붙여도 사용자 계정은 RP 의 DB 에 남습니다. RP 는 로그인마다 logi 로 인증을 보내지만, User 레코드는 RP 가 소유하고 그 위에 sub(+ email)를 외부 식별자로 저장할 뿐입니다. 그래서 만에 하나 logi 를 더 이상 쓰지 않게 되어도:

• 회원을 DB 에 그대로 두고, 로그인 방법만 자체 이메일 인증 · 비밀번호 · 매직링크 등으로 갈아끼우면 됩니다.
• 잃는 것은 "logi 를 통한 재인증 경로" 하나뿐이고, 계정 · 프로필 · 데이터 · 관계는 전부 유지됩니다.

logi 는 인증을 대행할 뿐, 사용자를 인질로 잡지 않습니다.

⚠️ Warning: 단, 전환이 "무중단"은 아닙니다 데이터는 남지만 로그인 방법 전환에는 마찰이 있습니다. 소셜 로그인만 쓰던 사용자는 비밀번호가 없으므로, 자체 인증으로 갈아탈 때 이메일 기반 재설정/재인증 플로우를 한 번 거쳐야 합니다. 그래서 아래의 sub 와 email 을 함께 저장하라는 권장이 중요합니다 — email(email claim) 없이 sub 만 저장했다면 "이 사용자가 그 사람"임을 증명할 앵커가 없어 복구가 막힙니다. Apple private relay(@privaterelay.appleid.com)만 있는 사용자는 provider 없이는 특히 어렵습니다.

💡 Tip: 권장 — sub 와 email 을 함께 저장하세요 sub 만 저장하면 나중에 자체 인증으로 전환할 때 "이 사용자가 그 사람"임을 증명할 방법이 없습니다. logi 는 email claim 으로 대표 이메일을 내려주니 sub 와 email 을 함께 저장하세요. ⚠️ 단, Apple private relay 이메일(@privaterelay.appleid.com)만 있는 사용자는 provider 없이 복구가 제한됩니다.

주의

⚠️ Warning: 위임은 곧 신뢰 위임입니다 RP 는 Google/Apple 검증을 logi 에 위임합니다. 그만큼 RP 는 logi 가 발급한 id_token 의 서명·aud·iss 를 반드시 직접 검증해야 합니다 (JWKS). 소셜 로그인 인프라를 자체적으로 완전히 통제해야 하는 조직은 셀프호스팅 으로 logi 인스턴스와 credential 을 직접 운영할 수 있습니다.

• 모바일 앱은 데스크톱 web SSO 대신 native 앱 흐름(logi 앱 승인 · Universal Links)을 사용합니다 → 모바일 통합 트랙
• Apple private relay 이메일은 provider 간 자동 병합이 제한됩니다 (계정 병합)

⚠️ Warning: 동의화면 브랜딩 — 사용자는 "logi" 를 봅니다 logi 가 Google/Apple credential 을 소유하므로, upstream 동의화면(Google/Apple)에 표시되는 앱 이름·아이콘은 RP 가 아니라 logi 입니다. 또 사용자 흐름에 "logi 로 계속" 단계가 한 번 개입합니다. RP 자체 브랜드로 동의화면을 완전히 통제해야 하는 조직(브랜드 요건이 엄격한 경우)은 셀프호스팅 으로 자체 credential 을 운영하거나, provider 를 직접 등록하는 편이 맞습니다.

⚠️ Warning: 가용성 — logi 는 로그인 경로의 의존성입니다 위임은 logi 를 인증 경로의 런타임 의존성으로 둡니다. logi 에 장애가 나면 그 시간 동안 신규 로그인이 실패합니다(이미 발급된 RP 세션은 영향 없음). 이건 폐업 시나리오와 별개인 일상 가용성 문제입니다 — 상태 페이지/SLA 를 확인하고, 다운타임 허용치가 낮은 서비스는 위 "계정은 당신 것"의 자체 인증 fallback 을 미리 준비해 두세요.

관련 문서

• Web SSO (데스크톱 Apple/Google) — upstream SSO 내부 메커니즘
• 로그인 방법 제한 — 로그인 화면에 노출할 방법 좁히기
• sub 정책 — RP 가 받는 canonical sub