SSO 2 - 구현 모델과 운영 관점

Contents

1. SSO 모델

2. 구현 방식

3. Authorization Server

4. 운영 관점

---

1. SSO 모델

SSO 모델은 서비스 구조, 도메인 구조, 기존 인증 방식, 웹/모바일 환경에 따라 달라진다.

기존 시스템이 어떤 인증 방식을 사용하고 있는지, 서비스들이 같은 도메인에 있는지, 웹과 모바일을 함께 지원해야 하는지 등을 함께 고려해야 한다.

예를 들어 기존 서비스들이 JWT 기반 인증을 사용하고 있고, 여러 서브도메인이 서로 다른 Root Domain 아래 구성되어 있다면 단순 쿠키 공유만으로는 SSO를 구현하기 어렵다.

따라서 SSO 모델은 다음 요소를 기준으로 선택해야 한다.

1. 기존 인증 방식
2. 서비스 도메인 구조
3. 웹 / 모바일 / SPA 환경
4. 토큰 기반 인증 사용 여부
5. 보안 정책과 운영 방식

1.1 Delegation Model

별도의 통합 로그인 에이전트가 사용자 대신 각 서비스의 로그인 절차를 대행하는 방식
기존 서비스의 인증 방식을 변경하기 어려울 때 고려할 수 있는 방식

Delegation은 말 그대로 “위임”을 의미한다.

이 방식에서는 각 서비스가 SSO를 직접 지원하지 않더라도,
별도의 통합 로그인 에이전트가 사용자를 대신해 각 서비스에 로그인해준다.

즉, 사용자가 각 서비스에 직접 아이디와 비밀번호를 입력하는 대신,
에이전트가 인증 절차를 대행하여 로그인 상태를 만들어주는 구조다.

사용자 → 통합 로그인 에이전트 접근
에이전트 → 사용자 인증 정보 확인
사용자 → 대상 서비스 접근
에이전트 → 대상 서비스의 로그인 절차 대행
서비스 → 로그인된 사용자로 처리

각 서비스는 사용자의 비밀번호를 직접 검증하지 않고, 공통 인증 서버가 검증한 결과를 신뢰한다.

이 방식은 특히 기존 서비스의 인증 방식을 바꾸기 어렵거나,
레거시 시스템을 그대로 두고 통합 로그인을 붙여야 할 때 고려될 수 있다.

장점은 다음과 같다.

• 기존 시스템 변경을 최소화할 수 있다.
• 레거시 시스템에도 SSO를 적용할 수 있다.
• 여러 서비스의 로그인 절차를 사용자 대신 처리할 수 있다.

다만 단점도 있다.

• 에이전트가 사용자 인증 정보를 다루게 될 수 있어 보안 부담이 크다.
• 구조가 복잡해질 수 있다.
• 서비스별 로그인 방식이 달라지면 유지보수가 어려울 수 있다.

1.2 Propagation Model

인증 서버가 발급한 토큰이나 인증 정보를 여러 서비스에 전달하여 로그인 상태를 이어가는 방식
인증 정보를 안전하게 전달하고 각 서비스가 이를 검증하는 것이 핵심인 방식

Propagation은 인증 결과, 토큰, Assertion 같은 인증 정보를 여러 서비스에 전달하는 방식이다.

예를 들어 사용자가 인증 서버에서 로그인하면,
인증 서버는 토큰이나 Assertion 같은 인증 정보를 발급한다.
이후 클라이언트는 발급받은 인증 정보를 각 서비스에 전달하고, 각 서비스는 이를 검증해 사용자를 인증된 사용자로 처리한다.

사용자 → 인증 서버 로그인  
인증 서버 → 토큰 또는 인증 정보 발급  
사용자 → 서비스 A 접근  
서비스 A → 인증 정보 검증  
서비스 A → 인증된 사용자로 처리  
사용자 → 서비스 B 접근  
서비스 B → 인증 정보 검증  
서비스 B → 인증된 사용자로 처리

이 방식은 현대적인 웹 SSO에서 많이 사용되는 구조에 가깝다.

특히 OAuth 2.0 / OIDC 기반 SSO는
인증 서버가 발급한 토큰을 여러 서비스가 검증하는 형태이므로
Propagation Model로 이해할 수 있다.

이 방식에서는 인증 정보가 여러 서비스 사이를 이동하기 때문에,
전달되는 정보의 신뢰성과 보안이 중요하다.

따라서 다음 요소를 반드시 고려해야 한다.

• 인증 정보 위변조 방지
• 토큰 서명 검증
• 만료 시간 관리
• 전달 경로 보안
• 재사용 공격 방지

1.3 Web 기반 One Cookie Domain SSO

같은 Root Domain을 사용하는 서비스들이 하나의 쿠키를 공유하는 방식

예를 들어 다음과 같은 서비스가 있다고 가정한다.

mail.company.com
hr.company.com
portal.company.com

이 서비스들은 모두 company.com이라는 같은 Root Domain을 공유한다. 이 경우 쿠키의 Domain을 .company.com으로 설정하면, 여러 서브도메인에서 같은 쿠키를 사용할 수 있다.

Cookie Domain = .company.com

그러면 사용자가 한 서비스에서 로그인한 뒤 다른 서브도메인 서비스에 접근해도, 각 서비스가 같은 쿠키를 확인하여 로그인 상태를 판단할 수 있다.

mail.company.com 로그인
→ .company.com 쿠키 생성
→ hr.company.com 접근
→ 같은 쿠키 확인 가능

장점은 구조가 비교적 단순하다는 것이다.

하지만 제약도 있다.

• 모든 서비스가 같은 Root Domain을 사용해야 한다.
• 쿠키 설정 범위가 넓어질수록 보안 관리가 중요해진다.
• 서로 다른 회사 도메인이나 외부 서비스와는 단순 쿠키 공유가 어렵다.

즉, One Cookie Domain SSO는 같은 Root Domain 안의 웹 서비스들에는 단순하고 효과적이지만, 도메인이 분리된 환경에는 적합하지 않다.

1.4 Web 기반 Multi Cookie Domain SSO

서로 다른 Root Domain을 사용하는 서비스들 사이에서 SSO를 구현하는 방식

예를 들어 다음과 같은 서비스가 있다고 가정한다.

service-a.com
service-b.com

이 둘은 Root Domain이 다르다.
따라서 쿠키를 직접 공유할 수 없다.

브라우저 보안 정책상 service-a.com에서 service-b.com의 쿠키를 마음대로 만들 수 없기 때문이다.

이 경우에는 각 도메인마다 별도의 서비스 세션이나 쿠키를 만들고, IdP의 SSO Session을 활용해 로그인 입력을 생략한다.

흐름은 다음과 같다.

1. 사용자가 service-a.com에 접근한다.
2. service-a.com은 사용자를 IdP로 리다이렉트한다.
3. 사용자는 IdP에서 로그인한다.
4. IdP에 SSO Session이 생성된다.
5. service-a.com은 인증 결과를 확인하고 자기 도메인의 쿠키를 생성한다.
 
6. 사용자가 service-b.com에 접근한다.
7. service-b.com은 사용자를 IdP로 리다이렉트한다.
8. IdP는 기존 SSO Session을 확인한다.
9. 사용자는 다시 아이디/비밀번호를 입력하지 않는다.
10. service-b.com은 인증 결과를 확인하고 자기 도메인의 쿠키를 생성한다.

즉, 서로 다른 Root Domain에서는 쿠키를 공유하지 않는다.

대신 IdP의 SSO Session을 통해 사용자가 이미 인증된 상태인지 확인하고, 각 서비스는 자기 도메인에 맞는 쿠키나 세션을 별도로 생성한다.

같은 Root Domain:
쿠키 공유 가능
 
다른 Root Domain:
쿠키 공유 불가
IdP의 SSO Session을 통해 로그인 입력 생략

1.5 Root Domain에 따른 Cookie 공유 가능 여부

쿠키는 도메인 정책의 영향을 받는다. 같은 Root Domain을 사용하는 서브도메인끼리는 쿠키 공유가 가능하다.

mail.company.com
hr.company.com
portal.company.com

이 경우 .company.com으로 쿠키를 설정하면 여러 서브도메인에서 같은 쿠키를 사용할 수 있다.

반면 Root Domain이 다르면 쿠키 공유가 불가능하다.

a.com
b.com

a.com에서 b.com의 쿠키를 직접 만들 수 없기 때문이다.

따라서 Root Domain이 다른 서비스 간 SSO는 단순 쿠키 공유가 아니라, IdP의 SSO Session을 활용하는 방식으로 설계해야 한다.

정리하면 다음과 같다.

같은 Root Domain:

• 쿠키 공유 가능
• One Cookie Domain SSO 가능

다른 Root Domain:

• 쿠키 공유 불가
• IdP의 SSO Session을 통해 로그인 입력 생략
• 각 서비스는 자기 도메인의 세션이나 쿠키를 별도로 생성

---

2. 구현 방식

SSO를 구현하는 대표적인 방식에는 SAML, OAuth 2.0, OIDC가 있다.

전통적인 기업용 SSO에서는 SAML이 많이 사용되었고, 현대적인 웹/모바일/API 환경에서는 OIDC가 자주 사용된다.

다만 어떤 방식이 무조건 더 좋다고 말하기는 어렵다.
기존 시스템, 연동 대상, 보안 정책, 클라이언트 환경에 따라 적절한 방식을 선택해야 한다.

2.1 SAML

XML 기반의 인증 정보 교환 표준

SAML은 오래전부터 기업용 SSO에서 많이 사용된 방식이다.

SAML에서는 IdP와 SP가 XML 기반의 Assertion을 주고받는다.

IdP:

• 사용자를 인증하고 SAML Assertion 발급

SP:

• SAML Assertion을 검증하고 사용자 로그인 처리

SAML Assertion에는 사용자의 인증 결과와 사용자 정보가 포함될 수 있다.

장점은 다음과 같다.

1. 전통적인 기업용 SSO에서 많이 사용됨
2. 엔터프라이즈 솔루션과 연동 사례가 많음
3. 브라우저 기반 기업 내부 시스템에 적합

단점은 다음과 같다.

1. XML 기반이라 구조가 무겁다.
2. 설정과 연동이 복잡할 수 있다.
3. 모바일 앱, SPA, REST API 환경에서는 상대적으로 다루기 어렵다.

즉, SAML은 전통적인 엔터프라이즈 SSO 환경에 적합한 방식이다.

2.2 OAuth 2.0

사용자의 리소스 접근 권한을 위임하기 위한 인가 프로토콜

OAuth 2.0은 인증이 아니라 인가를 위한 프로토콜이다.

핵심은 사용자의 계정 정보를 직접 넘기지 않고, 특정 권한만 위임하는 것이다.

• 사용자 비밀번호를 서비스에 넘기지 않는다.
• 대신 제한된 권한을 가진 Access Token을 발급한다.

OAuth 2.0의 주요 구성요소는 다음과 같다.

Resource Owner:
리소스의 주인, 일반적으로 사용자
 
Client:
리소스 접근을 요청하는 서비스
 
Authorization Server:
사용자를 인증하고 토큰을 발급하는 서버
 
Resource Server:
보호된 리소스를 제공하는 서버
 
Access Token:
리소스 접근 권한을 증명하는 토큰

OAuth 2.0은 권한 위임에는 적합하지만, 사용자 인증 정보를 표준화해서 전달하기에는 부족하다.

따라서 SSO에서는 보통 OAuth 2.0만 단독으로 사용하기보다 OIDC와 함께 사용한다.

2.3 OIDC(OpenID Connect)

OAuth 2.0 위에 사용자 인증 계층을 추가한 프로토콜

OAuth 2.0이 권한 위임을 담당한다면, OIDC는 사용자 인증을 담당한다.

OIDC는 OAuth 2.0 흐름에 ID Token을 추가한다.

OAuth 2.0:
Access Token 중심
리소스 접근 권한 확인
 
OIDC:
Access Token + ID Token
리소스 접근 권한 + 사용자 신원 확인

ID Token을 통해 Client는 사용자가 누구인지 확인할 수 있다.

즉, OIDC는 다음 질문에 답하기 위한 프로토콜이다.

• 이 사용자는 누구인가?
• 정말 인증된 사용자인가?
• 어떤 Authorization Server가 인증했는가?

SSO에서는 사용자가 누구인지 확인해야 하므로 OIDC가 자주 사용된다.

2.4 SAML과 OIDC 차이

SAML과 OIDC는 모두 SSO에 사용될 수 있지만, 기술적 성격과 적합한 환경이 다르다.

SAML:

• XML 기반
• 전통적인 기업용 SSO에서 많이 사용
• 브라우저 기반 엔터프라이즈 환경에 적합

OIDC:

• OAuth 2.0 기반
• JSON / JWT 기반
• 웹, 모바일 앱, SPA, REST API 환경과 잘 맞음

다만 실제 선택은 기존 시스템, 연동 대상, 보안 정책, 운영 환경에 따라 달라진다.

---

3. Authorization Server

Authorization Server는 OAuth 2.0/OIDC 구조에서 토큰을 발급하는 핵심 서버다.

SSO 환경에서 Authorization Server는 사용자 인증 결과를 바탕으로 토큰을 발급하고, 여러 서비스의 로그인 흐름을 연결하는 중심 역할을 한다.

SSO에서는 여러 서비스가 Authorization Server를 신뢰한다.
따라서 Authorization Server의 안정성과 보안이 매우 중요하다.

Authorization Server 장애
→ 신규 로그인 불가
→ 토큰 발급 실패
→ 여러 서비스 접근 장애

3.1 Authorization Server의 역할

Authorization Server는 다음 역할을 수행한다.

1. 사용자 인증
2. 로그인 페이지 제공
3. Authorization Code 발급
4. Access Token 발급
5. ID Token 발급
6. 필요 시 Refresh Token 발급
7. 토큰 검증에 필요한 공개키 제공
8. 클라이언트 등록 및 관리
9. 인증 정책 관리

Authorization Server는 단순히 토큰만 발급하는 서버가 아니다.

로그인 요청을 받고, 사용자를 인증하고, Authorization Code를 발급하고, Token Endpoint를 통해 토큰을 발급하는 인증 흐름의 중심이다.

3.2 Keycloak

Keycloak은 SSO, OIDC, OAuth 2.0, SAML 등을 제공하는 오픈소스 IAM 솔루션이다.

IAM은 Identity and Access Management의 약자로, 사용자 인증과 접근 관리를 위한 시스템이다.

Keycloak은 다음 기능을 제공한다.

1. SSO
2. OIDC
3. OAuth 2.0
4. SAML
5. Admin Console
6. 사용자 / 그룹 / 권한 관리
7. 2FA
8. Social Login
9. 테마 커스터마이징

Keycloak의 장점은 빠르게 SSO 환경을 구축할 수 있다는 점이다.

직접 Authorization Server를 만들면 보안, 프로토콜, 토큰, 세션, 관리자 기능을 모두 직접 구현해야 한다.
반면 Keycloak은 이런 기능을 기본적으로 제공한다.

하지만 단점도 있다.

1. 제품이 제공하지 않는 프로세스는 커스터마이징이 어려울 수 있다.
2. 내부 코드를 직접 수정하면 버전 업그레이드가 어려워질 수 있다.
3. 비즈니스 데이터 저장에는 제약이 있을 수 있다.
4. 세밀한 트랜잭션 처리나 테스트가 까다로울 수 있다.

그래서 실무에서는 Keycloak에는 기본 계정 정보와 인증 관련 정보를 두고, 서비스에 필요한 추가 정보는 별도 프로필 서버에서 관리하는 방식도 사용한다.

즉, Keycloak은 표준 인증 기능을 빠르게 도입하기 좋은 솔루션이지만, 서비스 고유의 비즈니스 요구사항은 별도 구조로 보완해야 할 수 있다.

3.3 Spring Authorization Server

Spring Authorization Server는 Spring 생태계에서 OAuth 2.0/OIDC 기반 Authorization Server를 구현하기 위한 프레임워크다.

Spring Authorization Server의 장점은 Spring 기반 서비스와 잘 맞고, 필요한 구조를 직접 설계할 수 있다는 점이다.

장점은 다음과 같다.

1. Spring Boot / Spring Security와 자연스럽게 연동된다.
2. 비즈니스 요구사항에 맞게 커스터마이징할 수 있다.
3. Java / Spring 개발자가 이해하기 쉽다.
4. 기존 Spring 기반 시스템과 통합하기 좋다.

하지만 단점도 있다.

1. 직접 구현해야 할 부분이 많다.
2. 운영 안정성과 보안에 대한 책임이 크다.
3. OAuth 2.0 / OIDC 표준을 정확히 이해해야 한다.
4. Admin Console, 사용자 관리, 2FA 등 부가 기능을 직접 구성해야 할 수 있다.

즉, Spring Authorization Server는 자유도가 높은 대신 구현과 운영 책임도 커진다.

3.4 직접 구축 vs 솔루션 사용

Authorization Server를 직접 구축할지, Keycloak 같은 솔루션을 사용할지는 요구사항에 따라 달라진다.

3.4.1 직접 구축

직접 구축의 장점은 다음과 같다.

1. 서비스 요구사항에 맞게 자유롭게 설계 가능
2. 기존 시스템과 세밀하게 연동 가능
3. 내부 정책에 맞는 인증 흐름 구현 가능
4. 비즈니스 로직과 인증 흐름을 유연하게 결합 가능

단점은 다음과 같다.

1. 보안 책임이 크다.
2. 표준 프로토콜 구현 부담이 크다.
3. 관리자 기능, 2FA, 사용자 관리 등을 직접 구현해야 한다.
4. 운영 경험이 부족하면 장애 위험이 커질 수 있다.

3.4.2 솔루션 사용

솔루션 사용의 장점은 다음과 같다.

1. 빠른 구축 가능
2. OIDC, OAuth 2.0, SAML 등 표준 기능 제공
3. Admin Console 제공
4. 2FA 등 보안 기능 제공
5. 문서와 레퍼런스 활용 가능

단점은 다음과 같다.

1. 복잡한 커스터마이징이 어려울 수 있다.
2. 솔루션 구조에 맞춰야 한다.
3. 내부 코드를 수정하면 유지보수가 어려워진다.
4. 비즈니스 요구사항을 별도 서버나 외부 로직으로 보완해야 할 수 있다.

---

4. 운영 관점

SSO는 단순 로그인 기능이 아니라 여러 서비스의 진입점 역할을 한다. SSO 장애는 단일 서비스 문제가 아니라 여러 업무 시스템의 접근 장애로 확산될 수 있다.

따라서 SSO는 기능 구현뿐 아니라 운영 관점이 매우 중요하다.

특히 회사 업무 시스템에서 SSO는 여러 서비스의 공통 인증 흐름을 담당하기 때문에, 인증 서버 장애나 토큰 발급 실패가 여러 시스템에 영향을 줄 수 있다.

운영 관점에서는 다음을 중점적으로 봐야 한다.

1. 인증 서버 장애 영향
2. 토큰 만료와 재발급
3. 로그아웃 전파
4. 인증 로그와 장애 추적
5. 보안 이슈

4.1 인증 서버 장애 영향

SSO 구조에서 인증 서버는 여러 서비스가 의존하는 핵심 지점이다.

인증 서버에 장애가 발생하면 다음 문제가 생길 수 있다.

1. 신규 로그인 불가
2. Authorization Code 발급 실패
3. 토큰 발급 실패
4. 토큰 갱신 실패
5. 사용자 정보 조회 실패
6. 여러 업무 시스템 접근 장애

즉, 인증 서버 장애는 여러 서비스로 영향을 확산시킬 수 있다.

따라서 다음 지표를 모니터링해야 한다.

1. 인증 서버 상태
2. 로그인 성공 / 실패율
3. 토큰 발급 실패율
4. 토큰 갱신 실패율
5. 응답 지연 시간
6. 오류 코드별 발생 비율
7. 장애 발생 시 영향 서비스 범위

인증 흐름은 여러 단계를 거치기 때문에, 단계별로 추적할 수 있어야 한다.

로그인 요청
→ IdP 리다이렉트
→ 사용자 인증
→ Authorization Code 발급
→ Token Exchange
→ 토큰 검증
→ 서비스 세션 생성

이 흐름을 로그로 추적할 수 있으면 장애 지점을 빠르게 좁힐 수 있다.

4.2 토큰 만료와 재발급

SSO에서는 토큰 만료와 재발급 전략이 중요하다.

주로 다음 토큰이 사용된다.

Access Token:
리소스 접근에 사용
보통 짧은 만료 시간
 
Refresh Token:
Access Token 재발급에 사용
Access Token보다 긴 만료 시간
 
ID Token:
사용자 인증 정보 확인에 사용

Access Token의 만료 시간이 너무 길면 보안 위험이 커진다.
탈취된 토큰이 오래 사용될 수 있기 때문이다.

반대로 만료 시간이 너무 짧으면 사용자 경험이 나빠지고, 토큰 재발급 요청이 많아진다.

따라서 보안과 사용자 경험 사이의 균형이 필요하다.

Access Token:
짧게 유지
 
Refresh Token:
안전하게 보관하고 재발급에 사용
 
로그아웃 시:
Refresh Token 무효화

특히 Access Token이 stateless JWT라면 서버가 즉시 폐기하기 어렵다.

이 경우 다음 방식을 고려할 수 있다.

1. Access Token 만료 시간을 짧게 설정
2. Refresh Token Rotation 적용
3. Redis 등에 토큰 블랙리스트 관리
4. 세션 상태를 서버에서 관리

4.3 로그아웃 전파

SSO에서 로그아웃은 로그인만큼 중요하다.

사용자가 한 서비스에서 로그아웃했을 때 다음을 함께 고려해야 한다.

1. IdP의 SSO Session 종료
2. 해당 서비스 세션 종료
3. 로그아웃을 전파할 서비스 범위 결정
4. Refresh Token 무효화
5. Access Token 만료 전략 고려

Single Sign-Out이 제대로 되지 않으면 다음 문제가 생길 수 있다.

서비스 A에서 로그아웃
서비스 B는 여전히 로그인 상태

따라서 SSO에서는 로그인뿐 아니라 로그아웃 전파도 중요하다.

로그아웃 전파 방식은 크게 두 가지다.

Front-Channel Logout:
브라우저를 통해 각 서비스에 로그아웃 요청 전달
 
Back-Channel Logout:
서버 간 통신으로 각 서비스에 로그아웃 요청 전달

Back-Channel Logout은 브라우저 상태에 덜 의존하기 때문에 상대적으로 안정적인 방식으로 볼 수 있다.

4.4 인증 로그와 장애 추적

SSO 운영에서는 로그가 매우 중요하다.

인증 장애가 발생했을 때 다음을 확인할 수 있어야 한다.

1. 사용자가 어느 서비스에 접근했는가
2. IdP로 리다이렉트가 되었는가
3. 인증은 성공했는가 실패했는가
4. 실패했다면 이유가 무엇인가
5. Authorization Code가 발급되었는가
6. Token Exchange가 성공했는가
7. Access Token 또는 ID Token 검증에 실패했는가
8. 서비스 세션 생성에 실패했는가

인증 흐름은 여러 시스템을 거치기 때문에, 단일 로그만으로 원인을 찾기 어렵다.

따라서 다음 구조가 필요하다.

1. Trace ID 기반 요청 추적
2. 인증 단계별 로그 표준화
3. 로그인 성공 / 실패 로그
4. 토큰 발급 / 검증 로그
5. 사용자 식별자 마스킹
6. 장애 발생 시 영향 서비스 파악

4.5 보안 이슈

SSO는 여러 서비스의 인증을 담당하기 때문에 보안이 중요하다.

주요 보안 이슈는 다음과 같다.

1. 토큰 탈취
2. 세션 탈취
3. Redirect URI 조작
4. CSRF
5. XSS
6. Refresh Token 탈취
7. 과도한 권한 부여
8. 로그에 민감 정보 노출

특히 토큰은 민감한 정보다.
따라서 다음 원칙이 필요하다.

1. Access Token 만료 시간을 짧게 설정
2. Refresh Token은 안전하게 저장
3. HTTPS 적용
4. Redirect URI 엄격 검증
5. Scope 최소화
6. 토큰 서명 검증
7. 로그에 토큰 원문 저장 금지
8. 중요 기능에는 MFA / OTP / FIDO 적용

즉, SSO 보안의 핵심은 인증 흐름을 신뢰할 수 있게 만들고, 토큰과 세션이 탈취되더라도 피해 범위를 줄이는 것이다.