SSO

AI
gemma-4-31b
작성자
익명
작성일
2026.08.12
조회수
28
버전
v1
기술 → 보안 → 인증 서비스
SSO 통합 인증 IdP SP SAML OIDC OAuth 2.0 JWT MFA 중급

SSO (Single Sign-On, 통합 인증)

1. 개요

SSO(Single Sign-On, 통합 인증)란 사용자가 한 번의 인증 과정(ID/PW 입력 등)을 통해 연결된 여러 개의 독립적인 소프트웨어 시스템이나 서비스에 추가 로그인 없이 접근할 수 있게 하는 인증 체계이다.

현대적인 IT 환경에서는 수많은 SaaS(Software as a Service)와 내부 시스템이 혼재되어 있으며, SSO는 사용자가 각 서비스마다 개별 계정을 생성하고 기억해야 하는 번거로움을 제거하고, 관리자가 중앙에서 계정 권을 효율적으로 제어하는 것을 목적으로 한다.

2. 동작 원리 및 메커니즘

SSO의 핵심은 신뢰 관계(Trust Relationship)의 구축에 있다. 서비스 제공자가 사용자의 신원을 직접 확인하는 대신, 신뢰할 수 있는 제3의 인증 기관이 발행한 '인증 증명서(토큰)'를 믿고 접근을 허용하는 방식이다.

2.1 핵심 구성 요소

  • IdP (Identity Provider, 신원 제공자): 사용자의 신원 정보를 저장하고 인증을 수행하여 토큰을 발행하는 서버 (예: Okta, Azure AD, Google).
  • SP (Service Provider, 서비스 제공자): IdP로부터 인증 토큰을 전달받아 사용자에게 서비스를 제공하는 애플리케이션 (예: Slack, Notion, 사내 그룹웨어).

2.2 인증 방식 비교

구분 일반 로그인 방식 (Individual Login) SSO 로그인 방식 (Single Sign-On)
인증 주체 각 서비스(SP)가 직접 인증 수행 중앙 인증 서버(IdP)가 인증 수행
계정 관리 서비스별 개별 계정 생성 및 관리 중앙 집중식 단일 계정 관리
사용자 경험 서비스 이동 시마다 반복 로그인 필요 최초 1회 로그인 후 자동 접근
보안 관리 비밀번호 분실/변경 시 모든 서비스 수정 필요 IdP에서 한 번의 변경으로 모든 서비스 적용

2.3 IdP와 SP의 상호작용 시퀀스

sequenceDiagram
    participant User as 사용자 (Browser)
    participant SP as 서비스 제공자 (SP)
    participant IdP as 신원 제공자 (IdP)

    User->>SP: 서비스 접근 요청
    SP->>User: 인증 필요 (IdP 로그인 페이지로 리다이렉트)
    User->>IdP: 로그인 정보 입력 (ID/PW)
    IdP->>IdP: 사용자 신원 검증
    IdP->>User: 인증 토큰(SAML/JWT 등) 발행 및 리다이렉트
    User->>SP: 인증 토큰 전달
    SP->>IdP: 토큰 유효성 검증 요청 (선택적)
    IdP-->>SP: 검증 완료 응답
    SP->>User: 서비스 접근 허용 및 세션 생성
[인증 흐름 요약] 1. 서비스 요청: 사용자가 SP(서비스)에 접근을 시도합니다. 2. IdP 리다이렉트: SP는 인증되지 않은 사용자를 신뢰하는 IdP의 로그인 페이지로 보냅니다. 3. 토큰 발행: 사용자가 IdP에서 인증을 완료하면, IdP는 신원을 증명하는 토큰을 발행합니다. 4. 서비스 접근: 사용자가 토큰을 SP에 전달하면, SP는 이를 검증한 후 서비스 접근을 허용합니다.

3. SSO의 종류

구현 방식과 아키텍처에 따라 전통적인 방식과 현대적인 표준 방식으로 나뉜다.

3.1 전통적 방식 (Legacy Approaches)

  • 에이전트 기반 SSO (Agent-based SSO): 각 서비스 서버에 SSO 에이전트를 설치하여 IdP와 직접 통신하는 방식이다. 주로 레거시 시스템이나 온프레미스 환경에서 사용된다.
  • 포털 기반 SSO (Portal-based SSO): 중앙 포털 페이지에서 인증 후 링크를 통해 서비스로 이동하는 게이트웨이 방식이다. 웹 기반 서비스 통합에 유리하다.

3.2 현대적 표준 방식 (Modern Standard Approach)

  • 토큰 기반 SSO (Token-based SSO): SAML, OIDC와 같은 표준 프로토콜을 사용하여 인증 토큰(JWT, XML 등)을 주고받는 리다이렉션 방식이다. 서비스 간의 물리적 설치 없이 신뢰 관계 설정만으로 연동이 가능하여, 현재 대부분의 SaaS와 클라우드 환경에서 표준으로 사용된다.

4. 주요 표준 프로토콜

현대 SSO는 상호운용성을 위해 표준화된 프로토콜을 사용한다.

프로토콜 용도 데이터 포맷 주요 특징
SAML 2.0 기업용 엔터프라이즈 SSO XML 보안성이 높고 복잡하며, 주로 B2B/기업 내부망에서 사용
OAuth 2.0 권한 부여 (Authorization) JSON 리소스 접근 권한을 위임하는 프레임워크. 인증(Authentication) 프로토콜이 아니므로 단독으로 SSO를 구현하기보다 권한 관리에 집중함
OIDC 신원 인증 (Authentication) JSON (JWT) OAuth 2.0 위에 인증 레이어를 추가한 표준. SSO 구현을 위해서는 OAuth 2.0 기반의 OIDC를 사용하는 것이 표준이며, 소셜 로그인에 주로 사용

[참고] SAML vs OIDC 비교

비교 항목 SAML 2.0 OIDC (OpenID Connect)
데이터 포맷 XML JSON (JWT)
주요 타겟 기업 내부망, 엔터프라이즈 환경 모바일 앱, 웹 서비스, 소셜 로그인
전송 방식 주로 HTTP POST/Redirect REST API 기반 HTTP 요청
복잡도 설정 및 구현이 상대적으로 복잡함 가볍고 개발자 친화적이며 구현이 빠름

5. SSO의 장점과 단점

5.1 장점

  • 사용자 편의성: 여러 개의 비밀번호를 기억할 필요가 없으며, 로그인 시간이 단축된다.
  • 관리 효율성: 인사 이동이나 퇴사 발생 시, IdP에서 계정 하나만 정지시키면 연결된 모든 서비스의 접근 권한이 즉시 회수된다.
  • 비밀번호 정책 강화: 개별 서비스마다 낮은 보안 수준의 비밀번호를 설정하는 대신, IdP에서 강력한 비밀번호 정책을 일괄 적용할 수 있다.

5.2 단점 및 위험 요소

  • 단일 실패 지점 (SPOF, Single Point of Failure): IdP 서버에 장애가 발생하면 연결된 모든 서비스에 로그인할 수 없는 마비 상태가 된다.
  • 보안 집중 위험: 단일 계정이 탈취될 경우, 해당 계정과 연결된 모든 서비스의 데이터가 한꺼번에 노출되는 치명적인 결과(Blast Radius, 피해 범위의 확대)를 초래한다.

6. 보안 강화 방안

SSO의 단일 실패 위험을 보완하기 위해 다음과 같은 추가 보안 전략이 필수적으로 요구된다.

  1. 다요소 인증 (MFA, Multi-Factor Authentication): ID/PW 외에 OTP, 생체 인식, 푸시 알림 등 추가 인증 수단을 결합하여 계정 탈취 위험을 최소화한다.
  2. 조건부 액세스 (Conditional Access): 접속 IP, 기기 상태, 접속 시간, 지리적 위치 등 컨텍스트를 분석하여 위험도가 높다고 판단될 때 추가 인증을 요구하거나 접근을 차단함으로써 비정상적인 접근을 원천적으로 방지한다.
  3. 세션 및 토큰 관리:
    • 짧은 토큰 만료 시간: Access Token의 유효 기간을 짧게 설정하고 Refresh Token을 통해 갱신하게 함으로써 토큰 유출 피해를 줄인다.
    • 중앙 집중식 로그아웃 (SLO, Single Log-Out): IdP에서 로그아웃 시 연결된 모든 SP의 세션을 동시에 종료시키는 메커니즘을 구현한다.

7. 구현 예시 및 활용 사례

7.1 실제 적용 사례

  • 기업 내부망: 사내 그룹웨어, 메일, ERP, 결재 시스템을 Okta나 Azure AD로 통합하여 사원 번호 하나로 모든 업무 시스템 이용.
  • 소셜 로그인 (구글 계정 로그인): 사용자가 외부 서비스(예: 쇼핑몰, 커뮤니티)에서 '구글로 로그인'을 선택하면, 구글(IdP)이 사용자를 인증하고 해당 서비스(SP)에 ID 토큰을 전달하여 별도의 회원가입 없이 즉시 서비스를 이용하게 함.

7.2 OIDC 기반 인증 흐름 예시 (Conceptual Code)

사용자가 '구글로 로그인' 버튼을 눌렀을 때 발생하는 인증 요청과 응답의 간략한 흐름이다.

1. 인증 요청 (Authorization Request) 

GET /auth?
  client_id=CLIENT_ID&
  response_type=code&
  scope=openid profile email&
  redirect_uri=https://myapp.com/callback&
  state=random_state_string

2. 인증 응답 (Authorization Response - 토큰 교환 전 코드 전달) 

HTTP/1.1 302 Found
Location: https://myapp.com/callback?code=AUTH_CODE_VALUE&state=random_state_string

3. ID 토큰 확인 (JWT 구조 예시) 

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "CLIENT_ID",
  "exp": 1672531200, // 토큰 만료 시간 (Unix Timestamp)
  "iat": 1672527600, // 토큰 발행 시간 (Unix Timestamp)
  "email": "user@gmail.com",
  "name": "홍길동"
}

8. SSO 도입 시 고려사항 체크리스트

성공적인 SSO 도입을 위해 설계 단계에서 검토해야 할 항목들이다.

  • [ ] 지원 프로토콜 확인: 연동하려는 서비스(SP)들이 SAML, OIDC 등 표준 프로토콜을 지원하는가?
  • [ ] 가용성 전략: IdP 장애 시 서비스 중단을 막기 위한 이중화(HA) 및 재해 복구(DR) 계획이 수립되었는가?
  • [ ] 사용자 식별자 일치: 각 서비스 간 사용자를 식별할 수 있는 고유 키(예: 이메일, 사번)가 통일되어 있는가?
  • [ ] MFA 도입 여부: 단일 계정 탈취 위험을 방지하기 위한 2차 인증 수단이 마련되었는가?
  • [ ] 권한 매핑 설계: IdP의 그룹 정보(Role)를 SP의 권한 체계와 어떻게 매핑할 것인가?
  • [ ] 로그 및 감사: 인증 요청 및 실패 로그를 중앙에서 수집하여 이상 징후를 탐지할 수 있는가?
AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

이 AI 생성 콘텐츠가 도움이 되었나요?