OAuth 흐름 개요
CP-Auth는 표준 OAuth 2.0 Authorization Code Flow + PKCE (RFC 7636) 를 구현합니다. 외부 서비스가 골라 쓸 수 있는 두 가지 진입 방식이 있습니다.
두 가지 UX 모드
| 모드 | 사용자가 보는 것 | 추천 상황 | 가이드 |
|---|---|---|---|
| 자기 도메인 호스팅 | 본인 앱 페이지만 (CP 로고 없음) | 자기 브랜드 일관성 필요 | 자기 도메인 로그인 |
| CP 호스팅 페이지 | auth.cp-platform.com 로그인 페이지 | 빨리 붙이고 통합 비용 최소화 | CP 호스팅 로그인 페이지 |
두 모드 모두 백엔드 토큰 교환 부분은 동일합니다. 차이는 사용자가 로그인 UI를 어디서 보느냐 뿐입니다.
표준 흐름 (Authorization Code + PKCE)
[1] User → click "로그인"
[2] App FE → 사용자를 CP-Auth 또는 자기 폼으로 보냄
[3] User → email/password 또는 social provider로 인증
[4] CP-Auth → app FE callback URL로 ?code=<authcode>&state=<csrf> 리다이렉트
[5] App FE → code를 자기 백엔드로 전달
[6] App BE → POST /oauth/token (client_secret + code + code_verifier)
[7] CP-Auth → { access_token, refresh_token, expires_in }
[8] App BE → HttpOnly 쿠키로 access_token 저장 → User에게 응답PKCE는 누가 처리하나
| 흐름 | PKCE verifier 보관 | 토큰 교환 시 verifier 전달 |
|---|---|---|
| Google / Kakao social | CP-Auth (server-side cookie) | 불필요 — CP-Auth가 자체 처리 |
| Email 직접 인증 | 외부 클라이언트 (SDK가 자동) | 필요 — code_verifier 백엔드까지 전달 |
| CP 호스팅 페이지 redirect | CP-Auth (cookie) | 불필요 |
자기 도메인 email 흐름에서만 code_verifier 를 백엔드까지 흘려보내면 됩니다. SDK가 onSuccess 콜백에 자동으로 넘겨줍니다.
state · CSRF 방어
모든 흐름에서 state 파라미터가 사용됩니다. SDK가 자동으로 random state를 생성·검증합니다. 직접 호출하는 경우 사용자가 state 를 생성하고 callback에서 일치 여부를 검증해야 합니다.
권장: 어디서부터 읽을까
- 사용자가 CP 페이지를 한 번도 보지 않게 하고 싶다 → 자기 도메인 로그인
- 빠르게 붙이고 운영 가고 싶다 → CP 호스팅 로그인 페이지
- 받은 토큰 검증·갱신 방법이 궁금하다 → 토큰 검증·갱신