SSO 연동 정책 가이드: SAML vs OIDC, 우리 회사 최적의 선택은?

웹과 모바일 앱이 넘쳐나는 시대, 사용자는 서비스마다 다른 계정을 관리하는 데 피로를 느낍니다. 이를 해결하는 기술이 바로 단일 로그인(Single Sign-On, SSO)입니다. 한 번의 로그인으로 여러 서비스에 안전하게 접근하게 해주는 SSO는 이제 선택이 아닌 필수입니다.

하지만 SSO를 구현하려면 어떤 기술을 선택해야 할까요? 대표적인 프로토콜인 SAML과 OIDC 사이에서 고민하는 분들을 위해, 본 가이드는 실무 관점에서 두 프로토콜을 비교하고 상황에 맞는 최적의 정책을 설계하는 방법을 제시합니다.

결론부터 말하자면, 현대적인 웹/모바일 환경에서는 OIDC를 기본으로 채택하고, 레거시 시스템 연동이나 특별한 규제 요건이 있을 때 SAML을 선택하거나 혼용하는 것이 가장 이상적입니다.

SAML vs OIDC: 핵심 프로토콜 비교 분석

SSO 정책을 세우기 전, 두 프로토콜의 특징을 명확히 이해해야 합니다.

OIDC (OpenID Connect): 최신 기술 트렌드를 이끄는 프로토콜입니다. OAuth 2.0 기반의 인증 계층으로, JSON과 JWT(JSON Web Tokens)를 사용하여 가볍고 빠릅니다. RESTful API 통신에 최적화되어 있어 모바일 앱, 싱글 페이지 애플리케이션(SPA), API 인증에 매우 유리합니다. 더 자세한 내용은 Google의 OpenID Connect 문서에서 확인하실 수 있습니다.
SAML (Security Assertion Markup Language) 2.0: 오랫동안 엔터프라이즈 환경의 표준으로 자리 잡아온 프로토콜입니다. XML 기반으로 동작하며, 주로 웹 브라우저 기반 SSO에 사용됩니다. 기존 상용 솔루션이나 엔터프라이즈 SaaS(Software as a Service)와의 호환성이 뛰어난 장점이 있습니다.

두 프로토콜의 기술적인 차이점은 아래 표를 통해 한눈에 비교할 수 있습니다.

항목	SAML 2.0	OIDC 1.0
기반 프로토콜	SAML 2.0 (XML, 브라우저 Redirect/POST)	OAuth 2.0 (JSON, REST/API)
토큰 포맷	SAML Assertion (XML, XML 서명/암호화)	ID 토큰 / 액세스 토큰 (JWT)
주요 인증 흐름	SP-Initiated / IdP-Initiated	Authorization Code (+PKCE), Device Flow 등
권장 사용처	레거시 시스템, 엔터프라이즈 SaaS, 특정 규제 준수	모바일 앱, SPA, 신규 웹 서비스, API 인증
주요 보안 위협	XML 서명 관련 취약성, RelayState 변조	리디렉션 하이재킹, 토큰 탈취
핵심 감사 포인트	발급자(Issuer), 대상(Audience), 서명 유효성	`iss`, `aud`, `exp`, `nonce` 클레임, 토큰 회전/철회

실제로 많은 기업이 기존 SAML 기반 시스템을 유지하면서 신규 서비스에는 OIDC를 도입하고 있으며, SAML에서 OIDC로 마이그레이션하는 사례도 늘고 있습니다.

어떤 환경에서 사용하나요? 클라이언트 유형별 정책

SSO 정책은 서비스를 제공하는 클라이언트의 유형에 따라 달라져야 합니다. 클라이언트는 '보안 비밀(Client Secret)'을 안전하게 저장할 수 있는지에 따라 두 가지로 나뉩니다.

1. Confidential 클라이언트 (서버사이드 앱)

서버에서 직접 인증을 처리하여 Client Secret을 안전하게 보관할 수 있는 환경입니다. (예: Java, Python, Node.js 백엔드 웹 애플리케이션)

권장 플로우: Authorization Code

2. Public 클라이언트 (클라이언트사이드 앱)

Client Secret을 안전하게 저장할 수 없는 환경입니다. (예: 모바일 앱, 브라우저에서 실행되는 SPA, 데스크톱 애플리케이션)

권장 플로우: Authorization Code + PKCE

3. 혼합 환경 (B2E 포털 등)

기업 내부 직원(B2E)을 위한 포털처럼 다양한 클라이언트를 동시에 지원해야 하는 경우, 두 방식을 모두 지원하는 인증 브로커(Broker)를 도입하여 유연하게 운영할 수 있습니다.

가장 안전한 인증 방식: 권장 플로우(Flow)

OIDC와 SAML은 여러 인증 흐름(Flow)을 제공하지만, 보안 수준에 따라 권장되는 방식이 다릅니다.

OIDC (기본): Authorization Code Flow를 기본으로 사용해야 합니다. 특히 Public 클라이언트에서는 코드 탈취 공격을 방어하기 위해 PKCE(Proof Key for Code Exchange)를 반드시 함께 적용해야 합니다.
OIDC (특수 목적): 스마트 TV나 CLI 등 입력이 제한된 기기에서는 Device Authorization Flow를, 서버 간 통신에서는 Client Credentials Flow를 사용할 수 있습니다.
SAML: 서비스 제공자(SP)가 인증을 시작하는 SP-Initiated 방식을 우선으로 채택하고, 신원 제공자(IdP)가 시작하는 IdP-Initiated 방식은 보안 위험이 있어 꼭 필요한 경우에만 제한적으로 사용해야 합니다.
비권장: OIDC의 Implicit Flow는 토큰이 URL을 통해 노출될 수 있어 현재는 보안상 권장되지 않으며, Authorization Code + PKCE로 대체되었습니다.

보안 강화 필수 옵션: PKCE, Nonce, 그리고 토큰 관리

안전한 SSO를 위해서는 다음과 같은 보안 옵션을 필수로 적용해야 합니다.

PKCE (S256), state, nonce: 코드 탈취, CSRF, 리플레이 공격을 방지하는 핵심 보안 장치입니다. 모든 인증 요청에 반드시 포함되어야 합니다.
토큰 수명 관리:
- 액세스 토큰(Access Token): 수명을 최대한 짧게(보통 몇 분 단위) 설정하여 탈취 시 피해를 최소화합니다.
- 리프레시 토큰(Refresh Token): 긴 수명을 갖되, 사용 시마다 새로운 토큰으로 교체하는 회전(Rotation) 정책과 재사용 감지 기능을 적용하여 보안을 강화합니다.
리다이렉트 URI 검증: 사전에 등록된 URI 목록(Whitelist)과 정확히 일치하는 요청만 허용해야 합니다. 와일드카드(*) 사용은 절대 금물이며, 모바일 앱의 경우 커스텀 스킴(Custom Scheme)이나 앱 링크(App Links/Universal Links)의 유효성을 철저히 검증해야 합니다.

실수 방지를 위한 정책 설계 체크리스트

아래 체크리스트를 통해 SSO 정책 설계 시 놓치기 쉬운 부분을 점검하세요.

클라이언트 유형 불명확: Public 클라이언트로 간주하고, 반드시 Authorization Code Flow와 PKCE를 함께 적용합니다.
리다이렉트 URI: 와일드카드를 절대 사용하지 않고, 등록된 URI와 정확히 일치하는지 검증합니다. 모바일 앱 링크는 소유권 검증 절차를 거칩니다.
필수 파라미터 누락: PKCE, state, nonce 파라미터가 누락된 인증 요청은 거절하고, 감사 로그를 기록합니다.
토큰 수명 및 회전: 액세스 토큰은 분 단위로 짧게, 리프레시 토큰은 회전 정책과 기기 정보 바인딩을 적용합니다.
단일 로그아웃 (SLO): 공유 단말기 환경이나 규제 준수 등 명시적인 요구사항이 있을 경우에만 구현을 고려합니다.

안정적인 운영을 위한 검증 및 감사 로그 정책

SSO 시스템은 지속적인 모니터링과 감사가 필수입니다.

토큰 및 Assertion 검증:
- OIDC: 토큰의 발급자(iss), 대상(aud), 주체(sub), 만료 시간(exp), 발급 시간(iat), nonce 값을 모두 검증해야 합니다.
- SAML: Assertion의 XML 디지털 서명과 인증서의 유효성을 철저히 확인해야 합니다.
로깅 및 키 롤오버:
- 모든 로그인 시도, 토큰 발급/갱신, 오류 발생 내역을 상세히 기록하여 이상 징후를 추적할 수 있어야 합니다.
- OIDC의 JWKS나 SAML의 메타데이터(인증서)는 만료되기 전에 자동으로 갱신(롤오버)하는 프로세스를 구축하고, 만료 임박 시 관리자에게 알림을 보내야 합니다.

자주 묻는 질문 (FAQ)

Q. Implicit Flow는 이제 완전히 금지해야 하나요?
A. 예, 그렇습니다. 최신 보안 권고(OAuth 2.1)에서는 Implicit Flow를 폐기하고, 더 안전한 Authorization Code Flow + PKCE 사용을 표준으로 권장합니다.

Q. 모바일 앱(Public 클라이언트) SSO에서 가장 중요한 보안 포인트는 무엇인가요?
A. PKCE 적용, 앱 링크/유니버설 링크 검증을 통한 리다이렉션 보안, 그리고 기기 정보와 토큰을 바인딩하여 탈취된 토큰의 재사용을 막는 것이 핵심입니다.

Q. OIDC Discovery나 SAML 메타데이터는 얼마나 자주 갱신해야 하나요?
A. 시스템에서 자동으로 주기적인 갱신을 수행하도록 설정하는 것이 가장 좋습니다. 수동으로 관리할 경우, SAML 인증서는 최소 만료 30일 전에, OIDC의 JWKS는 키 롤오버 정책에 따라 정기적으로 갱신 알림을 설정해야 합니다.

Q. 단일 로그아웃(SLO)은 항상 필요한가요?
A. 아닙니다. SLO는 구현이 복잡하고 모든 연동 서비스의 세션을 동시에 종료시켜야 하므로 사용자 경험을 해칠 수 있습니다. PC방과 같은 공용 단말기 환경이나 높은 수준의 보안 규제가 요구되는 경우가 아니라면 필수는 아닙니다.

Q. ID 토큰과 액세스 토큰의 차이가 무엇인가요?
A. 간단히 말해, ID 토큰은 사용자가 '누구인지'를 증명하는 인증(Authentication) 정보이고, 액세스 토큰은 해당 사용자가 '무엇을 할 수 있는지'를 나타내는 권한(Authorization) 정보입니다.