본문 바로가기
Backend/Security & Auth

[Security & Auth] SSO(Single Sign-On) 개념 정리 및 기업 실무 사례 분석

prayingEZ 2026. 6. 30. 16:18
SSO(Single Sign-On)
한번의 로그인으로 여러 개의 시스템이나 애플리케이션에 자동으로 접근할 수 있게 해주는 통합 인증 방식이다.

 

목차
1. 개념
2. 기업의 SSO 활용 예시
3. SSO 장단점
4. 주의할 점

 

1. 개념

📌쉽게 이해하면 놀이공원의 자유이용권과 같다.

  • SSO가 없으면, 놀이기구 A, B, C를 탈때마다 입구 매표소 직원에게 신분증과 돈을 내며 개별 티켓을 새로 사야한다.
  • SSO가 있으면, 첫 입장 시 정문에서 신원 확인 후 자유이용권 팔찌를 하나 받는다. 그 이후에 어떤 놀이기구를 가든 그 팔찌만 보여주면 직원이 바로 들여보내준다.

📌이 비유를 백엔드/IT 용어로 매칭해 보면 다음과 같다.

  • 정문 -> 중앙 인증 서버(Identity Provider, IdP): 사용자의 신원(ID/PW)을 최초로 확인하고 인증해 주는 곳이다.
  • 자유이용권 팔찌 -> 인증 토큰(JWT, SAML 등): 사용자가 로그인 성공 시 발급받는 암호화된 입장 증명서이다.
  • 놀이기구 -> 서비스(Service Provider, SP): 올리브영, CGV 등 실제로 사용자가 이용하려는 개별 애플리케이션이다.

📌한 줄 요약

사용자는 단 한 곳(IdP)에서만 로그인하고 안전하게 암호화된 토큰을 발급받는다. 이후 연동된 서비스(SP)들은 유저의 비밀번호를 묻지 않고, 이 토큰이 위조되지 않았는지만 검증하여 유저를 통과시킨다. 한 번의 로그인으로 여러 서비스를 자유롭게 넘나드는 것이 바로 SSO이다.

 

2. 기업의 SSO 활용 예시

SSO는 비즈니스 목적과 환경에 따라 크게 계열사형/소셜 연합형/사내 폐쇄형 3가지 형태로 우리 일상에 녹아있다.

 

1) CJ ONE (계열사 연동형 SSO)

특징: 하나의 거대한 모태 기업(IdP)을 중심으로 여러 자회사(SP)가 묶인 형태이다.

예시: 사용자가 CJ ONE 계정 하나만 로그인해두면, 웹 브라우저를 켜둔 채 CGV, 올리브영 등 다양한 계열사 서비스를 넘다들 때 추가 로그인없이 즉시 인증이 공유된다.

 

2) 네이버/카카오 (소셜 로그인 연동형 SSO)

특징: 외부 거대한 플랫폼의 인증 인프라를 다른 중소 서비스들이 빌려쓰는 연합 인증(Federated SSO) 형태이다.

예시: 새로운 쇼핑몰에 가입할 때, 아이디를 새로 만들지 않고 네이버 아이디로 로그인을 누르는 경우이다. 백엔드는 표준 프로토콜인 OAuth 2.0을 기반으로 네이버가 검증해 준 안전한 사용자 프로필만 넘겨받아 세션을 생성한다.

 

3) 쿠팡 (사내 시스템 인트라넷 SSO)

특징: 일반 고객이 아닌 임직원의 사내 시스템 접근 통제 및 보안을 위한 든든한 방어벽 역할을 한다.

예시: 쿠팡의 보안 엔지니어 채용 공고를 보면 사내 계정 관리를 위해 글로벌 엔터프라이즈 SSO 솔루션인 Okta를 필수 스택으로 요구한다. 재미있는 점은 일반 사용자도 쿠팡 실제 사내 통합 인증(Okta SSO) 시스템의 로그인 요청 주소를 브라우저에서 관찰해 볼 수 있다는 것이다.

 

😶실무 엿보기: 쿠팡 SSO URL 파라미터 뜯어보기

실제 쿠팡 인트라넷의 인증 요청 URL을 백엔드 엔지니어의 시각으로 분석해보면, 현대 웹 보안 표준 기술이 어떻게 실무에 업격하게 녹아있는지 교과서처럼 배울 수 있다.

 

HTTP

https://coupang.okta.com/oauth2/v1/authorize?client_id=okta.2b1959c8-bcc0-56eb-a589-cfcfb7422f26&code_challenge=VjvtzH3mRmreGZxTe5imC0y6_Ea62Fks8d-Z0zW3Kgw&code_challenge_method=S256&nonce=cqFAlUoTvpkMVJ9hu4DKySEKjTpwVWnt8MP4DhbRxqfUK7qzTxb4MpVyxRszHXM0&redirect_uri=https%3A%2F%2Fcoupang.okta.com%2Fenduser%2Fcallback&response_type=code&state=ORsIxLBJPaJLiwxrJi4o5WVnIQcv0wV7yps1BBCM1QYuSajShrfPMVL2t94byfj2&scope=openid%20profile%20email%20okta.users.read.self%20okta.users.manage.self%20okta.internal.enduser.read%20okta.internal.enduser.manage%20okta.enduser.dashboard.read%20okta.enduser.dashboard.manage%20okta.myAccount.sessions.manage%20okta.internal.navigation.enduser.read
  • coupang.okta.com/oauth2/v1/authorize
    • 쿠팡이 사용하는 글로벌 인증 솔루션인 Okta의 중앙 인증 서버 주소이다.
  • response_type=code
    • 보안상 가장 권장되는 Authorization Code Grant(인증 코드 승인) 방식을 의미한다. 로그인 성공 시 브라우저에 토큰을 바로 던져주지 않고, 백엔드끼리만 안전하게 교환할 수 있는 임시 '인가 코드'를 먼저 발급하겠다는 뜻이다.
  • client_id=okta.2b1959c8-bcc0-56eb-a589-cfcfb7422f26
    • 로그인을 요청한 사내 시스템(쿠팡 어드민, 사내 위키 등등)이 무엇인지 인증 서버에 알려주는 고유 식별 ID이다.
  • redirect_uri=https%3A%2F%2Fcoupang.okta.com
    • 로그인이 완료된 후 사용자를 다시 돌려보낼 안전한 목적지 주소이다. 해커가 중간에 다른 주소로 낚아채지 못하도록 사전에 등록된 화이트리스트 주소만 허용된다.
  • scope=openid%20profile%20email
    • 이 인증을 통해 가져올 유저 정보의 범위이다. openid가 명시된 것을 통해 이 시스템이 단순 권한 부여(OAuth 2.0)를 넘어 인증 표준인 OIDC(OpenID Connect)를 완벽하게 따르고 있음을 알 수 있다.
  • code_challenge_method=S256, &code_challenge=VjvtzH3mRmreGZxTe5imC0y6_Ea62Fks8d-Z0zW3Kgw
    • 중간에 코드가  가로채어지더라도 무력화 시키는 PKCE(Proof Key for Code Exchange) 보안 확장 표준이다. SHA-256 알고리즘을 사용해 실무 보안을 극대화한 흔적이다.

쿠팡 실제 로그인 요청 흐름은 완벽하게 표준을 따르고 있다. 외부 중앙 인증 인프라(coupang.okta.com)를 활용하면서 가장 높은 등급의 보안 방식인 Authorization Code Grant와 PKCE 확장 표준을 실무에 업격하게 적용하여 임직원 계정을 보호하고 있다.

 

3. SSO 장단점

기술을 공부할 때는 장점뿐만 아니라, 그 기술이 가진 치명적인 한계와 이를 극복하는 실무 아키텍쳐까지 세트로 이해해야 한다.

 

3-1. 장점

1) 사용자 경험(UX) 개선 및 서비스 이탈률 방지

  • 패스워드 증후군 해결: 사용자는 서비스마다 아이디와 비밀번호를 새로 만들고 외울 필요가 없다.
  • 환영 효과: CJ 계열사나 쿠팡 인프라넷처럼 한곳에서만 로그인하면 다른 연동 서비스로 이동할 때 추가 입력 없이 자동으로 인증이 공유되어 서비스 체류율과 전환율이 극대화된다.

2) 중앙 집중식 보안 및 계정 관리

  • 입사/퇴사 처리의 간소화: 사내 SSO(쿠팡 예시)의 경우, 직원이 퇴사할 때 중앙 계정 시스템(Okta 등)에서 계정 하나만 '비활성화'하면 그 직원이 접근 권한을 가졌던 수십 개의 사내 툴(슬랙, 지라 , 소스코드 저장소 등) 접근 권한이 단 1초만에 일괄 차단된다.
  • 보안 정책 일괄 강제: '3달마다 비밀번호 변경', '해외 IP 차단', '2차 인증(MFA) 필수'와 같은 강력한 보안 정책을 서비스마다 따로 개발할 필요 없이 중앙 인증 서버 한곳에서만 세팅하면 연동된 모든 서비스의 보안 레벨이 함께 상향 평준회된다.

3) 운영 비용 및 CS 감소

고객센터나 IT지원팀으로 접수되는 문의의 50% 이상은 '비밀번호를 분실했어요.', '계정이 잠겼어요'이다. SSO는 인증 창구를 하나로 통일하므로 계정 찾기 관련 CS 비용을 대폭 절감해준다.

 

3-2. 단점(한계)

1) 단일 장애점 (SPOF, Single Point of Failure)

  • 전체 서비스 마비 위험: SSO 서버는 모든 서비스의 유일한 관문이다. 만약 중앙 인증 서버가 트래픽 과부하로 죽거나 인프라 장애(AWS 장애 등)가 발생하면, 올리브영이나 CGV 등 독자적으로 멀쩡히 잘 작동하던 개별 서비스들의 로그인 기능가지 통째로 마비가 된다.

2) 도미노식 해킹 (계정 탈취의 파급력)

  • 원패스 마스터 키의 위험: 해커가 피싱이나 악성코드를 통해 사용자의 SSO 마스터 계정 하나만 탈취하는 데 성공하면, 그 유저가 가입된 모든 계열사 서비스의 개인정보와 결제 수단까지 도미노처럼 한 번에 탈취당할 수 있다. 공격이 한 곳으로 집중되는 약점이 있다.

3) 크로스 도메인/쿠키 제약 및 아키텍쳐 파편화

  • 기업의 서비스들이 서로 다른 도메인으로 (예를 들어 oliveyoung.co.kr과 cgv.co.kr)을 쓸 경우, 브라우저의 기본 보안 정책(SameSite Cookie) 때문에 세션 쿠키를 단순히 공유할 수 없다. 이를 해결하기 위해 백엔드에서 복잡한 OAuth 2.0 프로토콜, 리다이렉션 흐름, 토큰 교환 매커니즘을 정교하게 설계해야 하므로 초기 개발 비용과 시스템 복잡도가 수직 상승한다.

😶 그렇다면 실제 기업들은 이 단점을 어떻게 해결할까?

 

백엔드 엔지니어들은 인프라 아키텍처와 추가 보안 설계를 통해 위 단점들을 기술적으로 방어하고 있다.

  • SPOF 방지 전략
    • 인증 서버를 여러 대 띄우는 다중화(Auto-scaling)를 기본으로 적용한다. 또한, 매번 무거운 DB를 조회하지 않도록 초고속 분산 인메모리 DB인 Redis Cluster를 도입하여, 유저의 세션 검증 응답 속도를 밀치로(ms) 단위르 극대화해 부하를 분산한다.
  • 도미노 해킹 방지 전략
    • 마스터 계정이 탈취당하는 것을 막기 위해, SSO 진입 시 스마트폰 OTP 앱 인증이나 생체 인증(FIDO)같은 MFA(다요소 인증)를 필수적으로 결합한다. 아이디와 비밀번호를 알더라도 2차 인증을 통과하지 못하면 진입할 수 없게 설계하여 계정 탈취 난이도를 극단적으로 높인다.

4. 백엔드 개발자가 SSO를 구현할 때 밤새 고민해야 하는 3가지(주의점)

SSO 아키텍쳐를 직접 설계하거나 실무 코드를 작성할 때, 주니어 개발자들이 가장 많이 삽질하거나 놓치는 실무 주의사항이다. (블로그 주인장도 그러했음)

4-1. 토큰 탈취 방지 전략 (XSS, CSRF 대책)

핵심 문제: SSO 인증의 결과물로 발급되는 JWT나 세션 토큰은 한 번 탈취당하면 해커가 유저의 권한을 그대로 행사할 수 있기 때문에 보안이 최우선이다.

실무 대책: 클라이언트가 웹 브라우저일 경우 토큰을 어디에 저장할 지 엄격히 통제해야한다. 일반적으로 JavaScript 코드 주입 공격(XSS)으로 토큰을 가로채지 못하도록, JavaScript 접근이 우너천 차단되는 httpOnly 옵션과 HTTPS 환경에서만 전송되는 Secure 옵션이 적용된 쿠키(Cookie) 형태로 토큰을 다루는 것이 기본 규격이다.

 

4-2. 통합 로그아웃 (Single Logout)의 구현 난이도

핵심 문제: 로그인은 중앙 서버 덕분에 한 번에 처리하기 쉽지만, 로그아웃을 한 번에 시키는 것(Single Logout)은 훨씬 까다롭다. 실무 대책: 유저가 올리브영 앱에서 로그아웃할 때, 중앙 SSO 서버의 토큰만 만료시키면 안된다. CGV나 뚜레쥬르 등 각 계열사 서버들이 개별적으로 유지하고 있던 인메모리 세션이나 로컬 토큰들까지 완벽히 무효화 되도록 웹소켓 통신이나 백채널 로그아웃(Back-channel Logout) 매커니즘을 정교하게 설계해야 보안 구멍이 생기지 않는다.

 

4-3. 인증 서버 부하 분산 (네트워크 병목 방지)

핵심 문재: 각 계열사 서비스의 API가 호출될 때마다 중앙 인증 서버에 '이 토큰 유효한가요?' 라고 매번 동기식 검증 요청을 보내면, 트래픽이 몰릴 때 중앙 인증 서버가 병목 지점이 되어 시스템 전체가 견디지 못하고 다운된다.

실무 대책: 이를 해결하기 위해 비대칭키(RS256) 알고리즘을 사용한다. 중앙 인증 서버의 공개키를 각 서비스 서버가 미리 캐싱해 두고, 중앙 서버를 거치지 않고 자체적으로 토큰(JWT)의 유효성을 검증하게 만든다. 혹은 Redis 같은 고속 인메모리 DB를 활용해 인증 세션을 초고속으로 조회할 수 있는 분산 캐싱 전략이 필수적이다.

 

 

이론과 실무 사례를 알아봤으니, 이제 실제 서버 코드로 구현해 볼 차례입니다. Java와 Spring Boot 환경에서 외부 IdP를 연동하는 세부 코드는 아래 구현 편에서 이어집니다.

[Security & Auth] Java/Spring으로 OAuth2 Client 기반 SSO 구현 설계

 

'Backend > Security & Auth' 카테고리의 다른 글

[Security & Auth] Java/Spring으로 OAuth2 Client 기반 SSO 구현 설계  (9) 2026.06.30

'Backend/Security & Auth' Related Articles

티스토리툴바