SAML 프로토콜의 이해

1. SSO(Single Sign-On)

1.1 개요

• 한 번의 로그인(인증)으로 여러 시스템(서비스)에 재 인증 절차 없이 접근할 수 있는 통합 로그인 솔루션
• 다른 사이트(또는 앱)에서 로그인 및 인증 부분만 따로 사용하는 것 (API, 모듈 등)
• (보통) 기업에서 일반적으로 사용되며, 사용자가 인증 정보를 한 번만 제공하면 여러 개의 애플리케이션에 대해 로그인할 수 있도록 합니다
• (보통) 기업에서 사용자 인증 및 보안을 강화하기 위한 목적으로 사용되며, 보안성 측면에서 이점이 있습니다

2. SAML(Security Assertion Markup Language)

2.1 SAML 개요

SAML은 SSO(Single Sign-On) 를 구현하기 위한 XML 기반의 인증/인가 표준 프로토콜이다.

IDP와 SP 간의 authenticate 및 authorization 데이터를 교환하기 위한 XML 기반 표준 데이터 포맷으로, 인증 정보를 XML 포맷으로 생성하고 이를 암호화함으로써, 제3자에게 내용을 노출시키지 않고 최종 수신자까지 전달할 수 있다. 이때 생성한 XML을 Assertion이라고 한다.

핵심 구성요소

2.2 SAML 인증 플로우 (SP-initiated)

사용자가 SP에 먼저 접근하면 IdP로 리다이렉트되어 인증하고, 다시 SP로 돌아오는 가장 일반적인 플로우.

① User → SP          서비스 접근 요청
② SP → User          302 Redirect + AuthnRequest
③ User → IdP         IdP로 리다이렉트 (AuthnRequest 포함)
④ IdP → User         로그인 폼 응답
⑤ User → IdP         크리덴셜 제출 (ID/PW)
                      [IdP 내부] 인증 처리
⑥ IdP → User         SAML Response (Assertion) + POST to SP ACS URL
⑦ User → SP          SAML Response 전달 (POST)
                      [SP 내부] 서명 검증
⑧ SP → User          세션 생성 + 서비스 접근 허용

핵심 포인트: ⑥번 단계에서 IdP가 브라우저를 통해 SP의 ACS URL로 SAML Response를 POST한다. 브라우저가 중간 전달자 역할을 하므로 SP와 IdP는 직접 통신하지 않는다.

IdP initiate? SP initiate?

위에 플로우 이미지를 보시면 두가지 시작점이 존재합니다.

• SP-initiated: 서비스에서 로그인을 진행하여 인증 플로우가 시작되는 경우 (위 플로우)
• IdP-initiated: IdP 대시보드에서 인증 플로우가 시작되는 경우

2.3 SP ↔ IdP 사전 설정 (Trust 수립)

Trust란?

"SP가 IdP로부터 받은 Assertion을 믿어도 되는가?" 에 대한 답을 기술적으로 가능하게 하는 것.

메타데이터 교환 = 인증서(공개키) 전달 수단
인증서 사전 등록 = Trust의 실체

Trust는 양방향 등록이 모두 완료된 시점에 성립한다.

• SP 설정에 IdP의 Entity ID + 인증서가 저장됨 → SP가 IdP를 신뢰
• IdP 콘솔에 SP의 Entity ID + ACS URL이 등록됨 → IdP가 SP를 신뢰

SP → IdP에 등록해야 하는 정보

IdP → SP에 등록해야 하는 정보

메타데이터 교환 방법

주의: 인증서 갱신 시 URL 자동 페칭 방식은 자동으로 갱신되지만, 파일/수동 방식은 직접 업데이트해야 한다. 놓치면 인증이 갑자기 깨진다.

Trust가 깨지는 경우

다른 프로토콜과의 비교

SAML의 Trust는 최초 1회 설정, 인증서 만료 전까지 유지되는 정적인 관계다.

2.4 서명(Signing) vs 암호화(Encryption)

SAML에서 이 둘은 목적이 다르고 필수 여부도 다르다.

실제 플로우에서 적용

전송 기밀성      → HTTPS(TLS)가 담당
Assertion 무결성 → IdP 개인키 서명 + SP가 IdP 공개키로 검증 (필수)
Assertion 기밀성 → SP 공개키로 암호화 (선택, 민감 데이터 포함 시)

AuthnRequest 방향 (SP → IdP)

• SP 개인키로 서명 첨부 (선택)
• IdP가 SP 공개키로 서명 검증 (선택)

SAML Response 방향 (IdP → SP)

• IdP 개인키로 Assertion에 서명 (필수)
• SP가 IdP 공개키로 서명 검증 (필수)
• 추가로 SP 공개키로 Assertion 암호화 가능 (선택)

2.5 SAML Assertion

정의

IdP가 만들고, 브라우저가 SP에 전달하고, SP가 소비한 뒤 버리는 일회용 인증 확인서

사용자가 IdP에서 로그인에 성공한 순간 즉석에서 생성된다.

내부 구조 (3가지 Statement)

수명과 일회성

Replay Attack 방지

• SP가 이미 처리한 Assertion ID를 저장해두고, 동일 ID가 재전송되면 거부
• NotBefore / NotOnOrAfter 필드로 시간 범위도 검증

Assertion vs SP 세션

Assertion = 편지 (IdP → SP, "이 사람은 인증됐습니다")
SP 세션   = 입장권 (SP가 Assertion을 읽고 자체 발급)

Assertion은 딱 한 번 쓰고 버린다. 그 이후 사용자는 SP 세션으로 식별된다.

3. SAML 보안

3.1 ACS URL 변조 공격과 방어

공격 시나리오

AuthnRequest 안에 AssertionConsumerServiceURL 파라미터를 직접 실어 보낼 수 있다. AuthnRequest는 브라우저를 통해 전달되므로 중간 조작 여지가 있다.

<samlp:AuthnRequest
  AssertionConsumerServiceURL="https://attacker.com/steal">
  ...
</samlp:AuthnRequest>

방어 레이어

레이어 1 — IdP의 ACS URL 목록 대조 (주 방어선)

• IdP는 사전 등록된 ACS URL 목록과 대조
• 등록되지 않은 URL이 오면 요청 거부
• 대부분의 IdP가 기본 적용

레이어 2 — AuthnRequest 서명 (보조 방어선)

• SP가 개인키로 AuthnRequest 전체(ACS URL 포함)에 서명
• 한 글자라도 바꾸면 서명이 깨짐
• 레이어 1이 설정 실수로 빠졌을 때 최후 방어선

SP 사칭이 불가능한 이유

메타데이터 URL로 얻을 수 있는 것 → Entity ID, ACS URL, SP 공개키 (모두 공개)
절대 얻을 수 없는 것            → SP 개인키 (서버 내부에만 존재)

IdP는 Response를 사전에 등록된 ACS URL로만 전송한다. 공격자가 IdP 콘솔에 자기 서버 주소를 등록하려면 관리자 계정 인증이 필요하다.

SAML trust 모델의 보안은 "메타데이터를 누가 아느냐"가 아니라 "개인키와 IdP 콘솔 접근 권한을 누가 갖고 있느냐" 에 달려 있다.

3.2 SAML 취약점 케이스

4. SAML 장단점

4.1 장점

• 사용자 경험 개선 → 생산성 개선
• 자격증명 분실 감소
• 보안 강화
• 비용 절감
• 사용자 관리 간소화

4.2 단점

• SAMLRequest, SAMLResponse의 포맷은 XML 형식이라 브라우저를 통해서만 동작 가능 → 모바일 or Native Application에서는 부적절

5. SAML 대체 솔루션

OAuth

• Authorization을 위한 개방형 표준 프로토콜
• Third-Party App에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식 제공
• 핵심: Access Token + Refresh Token
• SAML과 다르게 XML이 아니라 JSON 기반 포맷 사용

OpenID Connect (OIDC)

• OAuth 2.0을 이용해 만들어진 인증 레이어
• OAuth에서 불가능했던 Authentication을 위해 ID Token 이라는 토큰을 추가
• Access Token(OAuth): Bearer 형식 / ID Token: JWT 형식

6. SAML vs OIDC

6.1 차이점

• SAML이 비교적 일찍 나온 프로토콜로 이미 기업에서 많이 사용중이며 신뢰성이 높고 인증 및 권한 부여 처리에 적합하다
• OIDC는 JWT를 사용한 REST API 통신 방식으로 가볍고 빠르며 확장성이 좋다
• OIDC가 모바일에서도 사용이 가능하여 사용자 경험에 좋은편이다

보안측에서도 확장성이나 취약점이 OIDC가 더 낮지만, 이미 보안 시스템이 구축된 기업들에게 OIDC로 마이그레이션이 더 큰 비용이며, 교체하지 않아도 문제없는 상황이라 유지되고 있다.

6.2 SAML 및 OIDC를 사용해야 하는 경우

• SSO 구현의 기회 제공 → 직원 생산성 높이기
• 서로가 대안이라기 보다는 함께 사용할 수 있는 기술에 더 가까움

ex) MS 환경에서는 OAuth가 authorization(권한 인증)을, SAML이 authentication(인가)을 처리한다고 합니다

6.3 결론

결국, 큰 기업들에게 SaaS로 제공하려면 SP로써 SAML을 통한 로그인 체계를 준비하는 것은 필수이다.

참고

• https://www.youtube.com/watch?v=SvppXbpv-5k&t=1s
• https://devforum.okta.com/t/how-to-integrate-okta-saml-to-vue-spa/12650
• Understanding SAML | Okta Developer
• react + express 데모
• SAML 스펙 문서