[SSO 로그인 흐름 5편] SAML Assertion, 그 안에 뭐가 들었을까?

"이 사용자는 인증됐습니다"라는 인증서, SAML Assertion

앞선 글에서 우리는 IdP가 사용자의 로그인에 성공하면, SP에게 **SAML Assertion**이라는 걸 전달한다는 걸 배웠습니다. 이 Assertion은 마치 "이 사람은 누구다"라는 사실을 증명하는 디지털 신분증 같은 역할을 하죠.

 

그럼 그 안에는 어떤 정보가 들어있고, 어떻게 위조되지 않도록 보호되는 걸까요?

---

SAML Assertion의 구성요소

SAML Assertion은 XML 기반 문서입니다. 아주 단순하게 요약하면 다음과 같은 구조로 되어 있습니다:

<Assertion>

   <Issuer>https://idp.company.com</Issuer>

   <Subject>

      <NameID>hong@company.com</NameID>

   </Subject>

   <Conditions>

      <NotBefore>2025-06-15T12:00:00Z</NotBefore>

      <NotOnOrAfter>2025-06-15T12:05:00Z</NotOnOrAfter>

   </Conditions>

   <AttributeStatement>

      <Attribute Name="department">IT</Attribute>

      <Attribute Name="role">admin</Attribute>

   </AttributeStatement>

   <Signature>...</Signature>

</Assertion>

 

이 안에는 다음과 같은 중요한 정보들이 들어 있습니다:

항목의미

Issuer	Assertion을 발급한 IdP
NameID	사용자의 고유 식별자 (보통 이메일)
Conditions	유효 시간 등 제한 조건
Attribute	사용자 속성 (부서, 직급, 권한 등)
Signature	디지털 서명 (위조 방지)

 

---

디지털 서명: 누가 이걸 보증하나요?

이 Assertion에서 가장 중요한 건 바로 **서명(Signature)**입니다. Assertion은 **IdP의 개인키(private key)**로 서명되며, SP는 **사전에 등록한 IdP의 공개키(public key)**로 검증합니다.

즉, SP는 "이 Assertion이 진짜 IdP가 발행한 것인지"를 서명을 통해 확인하는 겁니다.

 

이를 통해 아래와 같은 보안이 보장됩니다:

• 위조 방지: 누가 중간에서 내용을 바꿔도 서명 검증에 실패
• 발행자 확인: Issuer와 공개키가 매칭되는지 확인 가능
• 무결성 검증: 중간에 수정되었는지 여부 파악 가능

---

시간 조건(Conditions)으로 재사용/도난 방지

SAML Assertion에는 반드시 유효 시간 조건이 포함됩니다:

<Conditions>

   <NotBefore>2025-06-15T12:00:00Z</NotBefore>

   <NotOnOrAfter>2025-06-15T12:05:00Z</NotOnOrAfter>

</Conditions>

 

즉, 이 Assertion은 특정 시점에만 사용 가능하고, 몇 분이 지나면 무효 처리됩니다. 이는 **재사용 공격(replay attack)**을 막는 중요한 장치입니다. 예를 들어 누군가 이전 Assertion을 가로챘다고 해도, 유효 시간이 지나면 쓸 수 없습니다.

---

Assertion은 어떻게 전달될까?

Assertion은 브라우저를 통해 SP로 전달됩니다. 대표적인 방식 두 가지:

1. HTTP Redirect
   • Assertion이 URL에 base64 인코딩되어 전달됨
   • 보안 부담이 있음 (짧고 단순한 인증 흐름에 적합)
2. HTTP POST
   • 브라우저가 자동으로 POST 폼을 전송함
   • 대부분의 보안 환경에서는 이 방식을 사용

브라우저는 사용자가 보지 못할 만큼 빠르게 이 Assertion을 SP로 옮겨줍니다. SP는 이 Assertion을 받아 검증하고, 로그인 세션을 생성합니다.

---

Assertion이 위조되면 어떤 일이?

Assertion이 만약 공격자에 의해 위조되었다면?

• 이름(NameID)을 admin으로 바꿨다거나,
• 유효 시간을 길게 늘렸다거나,
• 권한 속성(Attribute)을 조작했다면?

그러면 SP는 이를 검증할 때 서명이 맞지 않아서 거부합니다.

 

SP는 반드시 Assertion 전체 구조를 검증 절차를 통해 확인합니다:

• XML 구조의 유효성 검사
• 서명 검증 (공개키로)
• 시간 조건 검사
• 발급자 정보 일치 확인

---

지금까지 흐름 정리

지금까지 우리는 다음 단계를 모두 살펴봤습니다:

1. 사용자가 로그인
2. IdP가 인증 성공
3. IdP가 SAML Assertion 생성
4. 브라우저가 SP로 전달
5. SP가 Assertion을 검증
6. 로그인 성공!

---

다음 편 예고: 자동 로그인과 세션의 비밀

다음 6편에서는 이렇게 인증된 사용자가 다른 서비스로 이동해도 자동 로그인되는 구조를 따라가 봅니다. 또한 세션 쿠키, 토큰 유지, 싱글 로그아웃(SLO) 같은 개념도 다루게 될 거예요.