5. SSO와 CIAM의 관계: 고객 로그인 경험을 바꾸는 구조
앱이 세 개인 기업이 있습니다. 쇼핑몰, 멤버십 포인트 앱, 고객 서비스 챗봇. 고객은 이 세 곳에서 각각 로그인해야 합니다. 불편하다는 민원이 쌓입니다. 담당자는 "SSO 도입하면 되지 않나요?"라고 제안합니다. 맞습니다. 하지만 SSO는 버튼 하나로 해결되는 기능이 아닙니다. 그 뒤에는 프로토콜 선택, 세션 관리, 계정 통합, 장애 대응 설계가 숨어 있습니다.
이 글에서는 SSO가 무엇인지, CIAM과 어떻게 다른지, 그리고 실무에서 SSO를 제대로 구현하기 위해 알아야 할 핵심 설계 포인트를 체계적으로 정리합니다.
1. SSO란 무엇인가 — CIAM과의 관계 정리
SSO(Single Sign-On)는 한 번의 로그인으로 여러 서비스·앱에 접근할 수 있도록 하는 인증 메커니즘입니다. CIAM과 혼동하기 쉽지만, 명확히 구분해야 합니다.
| 구분 | SSO | CIAM |
|---|---|---|
| 성격 | 인증 기능(Feature) | 고객 신원 관리 체계(System) |
| 범위 | 로그인 경험 단순화 | 가입~탈퇴 전체 생애주기 |
| 관계 | CIAM의 핵심 구성 요소 | SSO를 포함하는 상위 체계 |
| 비유 | 건물의 마스터키 | 건물 전체의 보안·출입 관리 시스템 |
즉, SSO는 CIAM 없이 단독으로 존재할 수 없습니다. 토큰 발급, 사용자 식별, 세션 관리, 로그아웃 처리 모두 CIAM 인프라가 뒷받침해야 SSO가 정상 작동합니다.
2. SSO를 구현하는 3가지 프로토콜 비교
SSO는 추상적 개념이고, 실제 구현은 프로토콜로 이루어집니다. 현재 업계에서 사용하는 주요 프로토콜은 세 가지입니다.
| 프로토콜 | 주요 용도 | 특징 | 적합 환경 |
|---|---|---|---|
| SAML 2.0 | 엔터프라이즈 SSO | XML 기반, 성숙한 표준, 모바일 환경에 약함 | B2B, 기업 내부 시스템 연동 |
| OAuth 2.0 | 인가(Authorization) 위임 | JSON/REST 기반, 토큰 방식, 인증 자체는 지원 안 함 | API 접근 권한 위임 |
| OIDC (OpenID Connect) |
고객용 SSO 표준 | OAuth 2.0 위에 인증 레이어 추가, ID Token 제공 | B2C 소비자 서비스, 소셜 로그인 |
- 일반 소비자 대상 B2C 서비스: OIDC가 현재 표준. 소셜 로그인(Google·Apple·카카오)도 OIDC 기반
- 기업 고객사와의 SSO 연동: 고객사가 Microsoft AD·Okta를 쓴다면 SAML 2.0 지원 필수
- API 기반 권한 위임: OAuth 2.0 단독 사용. 단, 인증은 OIDC로 별도 처리
- 레거시 시스템: SAML만 지원하는 경우 OIDC와의 브릿지 레이어 구성 필요
3. 고객용 SSO vs 직원용 SSO — 설계 차이
같은 'SSO'라는 이름을 쓰지만, 고객용과 직원용은 설계 철학이 다릅니다.
| 항목 | 고객용 SSO (CIAM) | 직원용 SSO (IAM) |
|---|---|---|
| 네트워크 환경 | 인터넷 공개, 예측 불가 | VPN·사내망 제한, 예측 가능 |
| 기기 환경 | 개인 스마트폰·PC·태블릿 혼재 | 회사 지급 단말 중심 |
| 세션 관리 | 브라우저 변경·앱 전환·오프라인 처리 필요 | 단일 기기 중심, 비교적 단순 |
| 로그아웃 처리 | 개별 앱 로그아웃 vs 전체 로그아웃 옵션 제공 | 일괄 강제 로그아웃 정책 적용 |
| 확장성 | 수백만 동시 세션 대응 필요 | 수만 명 수준, 예측 가능 |
| UX 우선순위 | 로그인 마찰 최소화가 핵심 | 보안 통제 우선, 불편 수용 가능 |
고객용 SSO에서 가장 어려운 부분은 예측 불가능한 고객 행동에 대응하는 것입니다. 고객은 브라우저를 갑자기 닫거나, 같은 계정으로 스마트폰과 PC에서 동시에 접속하거나, 몇 달 만에 다시 서비스를 찾아오기도 합니다. 이 모든 시나리오가 세션 설계에 반영되어야 합니다.
4. 외부 IdP 연동과 Unified ID 설계
현대 고객용 SSO에서 빼놓을 수 없는 것이 외부 Identity Provider(IdP) 연동입니다. Google, Apple, 카카오, 네이버 같은 소셜 플랫폼이 사실상 외부 IdP 역할을 합니다.
하지만 외부 IdP를 단순히 연결만 하면 심각한 문제가 생깁니다.
- 계정 중복: 이메일로 먼저 가입한 고객이 같은 이메일의 Google 로그인을 시도할 때 신규 계정이 생성됨
- 정보 불일치: 소셜 플랫폼에서 가져온 이름·이메일이 기존 프로파일과 충돌
- 데이터 고립: 소셜 연동 해제 후 해당 계정으로 가입한 고객이 로그인 수단을 잃음
- Apple 이메일 릴레이: Apple Sign-in은 실제 이메일 대신 릴레이 주소를 제공하여 이메일 기반 식별이 불가능
이 문제의 해법이 Unified ID(통합 식별자) 설계입니다. 외부 계정으로 로그인하더라도 우리 CIAM 안에서는 하나의 마스터 프로파일로 매핑합니다.
- 모든 외부 로그인은 내부 고유 식별자(Internal User ID)와 매핑
- 이메일을 1차 연결 키로 사용, Apple 릴레이 주소는 별도 처리
- 동일 이메일의 신규 소셜 로그인 시도는 계정 연동 제안으로 처리 (신규 생성 금지)
- 소셜 연동 해제 시에도 내부 계정은 유지, 대체 로그인 수단 안내
- 연동 이력을 감사 로그로 보관
5. SSO 세션 관리의 실무 문제
SSO의 편의성을 유지하면서 보안을 지키려면 세션 관리 정책이 정교하게 설계되어야 합니다. 실무에서 자주 부딪히는 문제들입니다.
| 문제 상황 | 설계 대응 방안 |
|---|---|
| 세션 만료 시점 불일치 | 앱 A의 세션은 살아있는데 앱 B에서 재로그인을 요구하는 현상 → 중앙 세션 서버에서 세션 상태 단일 관리 |
| 복수 기기 동시 로그인 | 스마트폰·PC·태블릿 동시 접속 허용 여부 정책 수립 → 기기별 독립 세션 또는 최대 기기 수 제한 |
| 장기 비활성 세션 | 수개월간 앱을 열지 않은 고객의 세션 처리 → Sliding Expiration 방식으로 마지막 활동 기준 만료 |
| 브라우저 탭 간 세션 공유 | 같은 브라우저에서 A 서비스 로그아웃 시 B 탭도 영향받는 문제 → iframe 기반 세션 체크 또는 BroadcastChannel API 활용 |
| 모바일 앱 백그라운드 전환 | 앱이 백그라운드로 전환된 후 복귀 시 인증 상태 처리 → Refresh Token 기반 자동 갱신, 고위험 앱은 재인증 요구 |
세션 유효 시간 권장 기준: 금융 서비스는 15~30분, 일반 커머스는 1~24시간, '로그인 상태 유지' 선택 시 7~30일(Refresh Token 기반)이 업계 일반 기준입니다. 서비스 민감도에 따라 조정하되, 너무 짧으면 재로그인 이탈률이 올라갑니다.
6. Single Logout(SLO) — 자주 놓치는 설계
SSO를 도입하면서 로그인은 신경 쓰지만 로그아웃(SLO, Single Logout)을 제대로 설계하지 않는 경우가 많습니다. 이것이 보안 취약점이 됩니다.
고객이 공용 PC에서 서비스 A에 로그인한 후 A에서만 로그아웃합니다. 하지만 SSO로 연결된 서비스 B·C는 여전히 로그인 상태입니다. 다음 사용자가 B·C에 접근하면 이전 고객의 계정으로 바로 진입할 수 있습니다.
SLO 설계에서 결정해야 할 두 가지 옵션이 있습니다.
한 곳에서 로그아웃하면 SSO로 연결된 모든 서비스의 세션이 일괄 종료됩니다. 보안 측면에서 이상적이나, 작업 중인 다른 앱에서도 갑자기 세션이 끊겨 불편할 수 있습니다.
"현재 앱에서만 로그아웃" vs "모든 기기·앱에서 로그아웃" 옵션을 고객에게 제공합니다. 계정 탈취 피해자가 "모든 세션 강제 종료"를 직접 실행할 수 있어 보안 사고 대응에도 유용합니다.
실무 권장은 옵션 B입니다. 고객 경험을 해치지 않으면서도 보안 우려에 대응할 수 있습니다.
7. SSO 장애 시나리오와 대응 전략
SSO의 가장 큰 위험은 중앙 인증 서버 장애 시 연결된 모든 서비스에 동시에 로그인 불가가 된다는 점입니다. "Single Point of Failure" 문제입니다.
| 장애 유형 | 대응 전략 |
|---|---|
| 인증 서버 다운 | Active-Active 이중화 구성, 최소 2개 이상의 지역에 분산 배포 |
| 외부 IdP 장애 (Google·카카오 등) |
자체 계정(이메일/비밀번호) 로그인을 항상 백업으로 유지. 소셜 로그인 의존도를 100%로 설계하지 말 것 |
| 네트워크 지연·타임아웃 | 토큰 캐싱으로 단기 오프라인 처리. 만료된 세션의 Grace Period 설정 |
| 토큰 서명 키 만료 | 키 순환(Key Rotation) 자동화. 신·구 키 동시 유효 기간 설정으로 무중단 전환 |
8. SSO 도입 효과와 주의사항
SSO를 제대로 구현했을 때 기대할 수 있는 실질적 효과와 함께, 간과하기 쉬운 주의사항도 함께 정리합니다.
| ✅ 도입 효과 | ⚠️ 주의사항 |
|---|---|
| 앱 간 전환 시 재로그인 불필요 → 이탈률 감소 | SLO 미설계 시 보안 취약점 발생 |
| 비밀번호 분실 관련 CS 문의 감소 | 외부 IdP 의존도가 높아지면 장애 파급 범위도 커짐 |
| 인증 정책 중앙화로 일관된 보안 수준 유지 | 계정 중복 문제는 Unified ID 설계 없이는 해결 불가 |
| 감사 로그가 단일 지점에 통합되어 추적 용이 | SAML·OIDC 혼용 시 프로토콜 변환 레이어 필요 |
| 신규 서비스 추가 시 인증 연동 속도 향상 | SSO 서버 이중화 없이는 단일 장애 지점(SPOF) 위험 |
9. 정리
SSO는 고객 로그인 경험을 혁신하는 강력한 도구이지만, 제대로 설계하지 않으면 오히려 보안 구멍과 운영 복잡성을 키우는 양날의 검이 됩니다.
프로토콜 · 세션 · 로그아웃 · 장애 대응까지
설계가 완성되어야 비로소 작동합니다."
CIAM 기반의 SSO 구현을 시작할 때는 프로토콜 선택(OIDC 우선)→ Unified ID 설계 → 세션 정책 수립 → SLO 설계 → 이중화 구성 순서로 접근하는 것을 권장합니다.
- IETF. (2012). The OAuth 2.0 Authorization Framework (RFC 6749). IETF.
- OpenID Foundation. (2023). OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation.
- OASIS. (2005). Security Assertion Markup Language (SAML) 2.0. OASIS Standard.
- W3C. (2023). Web Authentication: An API for accessing Public Key Credentials (WebAuthn Level 3). W3C Recommendation.
- Baymard Institute. (2024). E-Commerce UX Research: Login & Account Creation. Baymard Institute.
- Google. (2024). Google Sign-In for Websites: Overview. Google Identity Platform Documentation.
댓글
댓글 쓰기