[SSO 로그인 흐름 4편] "아이디 입력했어요!" 그 다음엔? – SAML 인증 흐름 따라가기

로그인 창이 떴다! 이제 무슨 일이 벌어질까?

이제 여러분의 브라우저는 서버와 안전하게 연결되었고, 로그인 창이 떴습니다. ID와 비밀번호를 입력하는 순간, 사용자 인증 여정의 본격적인 클라이맥스가 시작됩니다.

 

하지만 이 로그인 창, 우리가 알고 있는 일반적인 폼 로그인과는 다릅니다. SSO 환경에서는 인증을 **서비스 제공자(SP)**가 직접 하지 않고, **IdP(Identity Provider)**에게 위임합니다.

---

SP와 IdP는 어떤 역할일까?

• SP (Service Provider): 사용자가 접근하려는 실제 서비스 (예: 사내메일, 구글워크스페이스, Microsoft 365 등)
• IdP (Identity Provider): 사용자의 신원을 확인해주는 인증 기관 (예: Azure AD, Okta, OneLogin 등)

SP는 "이 사람이 누구냐"를 IdP에게 묻고, IdP가 "이 사람은 인증된 사용자야"라고 증명하는 구조입니다.
이걸 우리가 SAML 기반 SSO라고 부릅니다.

---

SP-initiated SSO: 흐름 따라가기

사용자가 mail.company.com에 접속했다고 가정해 봅시다.
메일 시스템은 SP입니다. 그런데 사용자가 로그인되지 않았네요?

1. SP는 브라우저에게 말합니다
   “이 사용자 인증 안 됐으니, 우리 회사의 IdP로 가서 로그인해줘!”
2. 브라우저는 IdP로 리디렉션
   URL에 SAMLRequest라는 쿼리 파라미터가 달려 있고, 사용자 브라우저는 IdP로 이동합니다.
   (ex: https://idp.company.com/login?SAMLRequest=abc123...)
3. 사용자는 IdP 로그인 페이지에서 ID/PW 입력
4. IdP는 인증을 수행함
   • 입력한 자격 증명이 맞는지 확인
   • MFA(다단계 인증)도 이 시점에서 수행 가능
   • 이미 세션이 있다면 로그인 생략 가능
5. 성공 시, IdP는 SAML Assertion을 생성
   이 Assertion은 XML 기반의 문서로, “이 사람은 인증됐고, 이 이메일 주소와 소속이다”라는 정보를 담고 있습니다.
6. 브라우저가 SP로 리디렉션되며 Assertion 전달
   • 일반적으로 HTML Form 방식 (POST 바디에 Assertion 포함)
   • 또는 URL에 인코딩되어 전달됨 (Redirect 방식)
7. SP는 Assertion을 검증하고 세션 생성 → 로그인 완료!

---

SAML Assertion 안에는 무엇이 들어있을까?

• NameID: 사용자의 ID (이메일 주소 등)
• Attributes: 이름, 부서, 권한 등
• Conditions: Assertion의 유효 시간, 발급 대상 등
• Signature: 디지털 서명 (공격자가 위조 못 하도록)

이 Assertion은 IdP의 비밀키로 서명되어 있기 때문에, SP는 이를 통해 신뢰 여부를 판단합니다.

---

인증된 이후, 어떻게 다른 서비스도 로그인할 수 있을까?

이게 바로 SSO의 핵심이죠!
이미 IdP에 로그인되어 있다면, 다시 로그인할 필요 없이 다른 SP들(예: 사내 인트라넷, 클라우드 스토리지 등)도 자동 로그인됩니다.

• A 서비스 → 로그인 필요 → IdP로 리디렉션 → 로그인 → SAML Assertion → 로그인 완료
• B 서비스 → SP가 보니 이미 인증됨 → IdP에서 다시 Assertion만 받아서 로그인 처리

브라우저에 IdP의 세션 쿠키가 남아 있기 때문에 이게 가능합니다.
즉, 사용자는 한 번만 로그인하고, 나머지는 백그라운드에서 자동으로 인증이 처리됩니다.

---

보안적으로 중요한 포인트

• 사용자의 ID/PW는 오직 IdP와만 주고받음. SP는 알지 못함.
• SAML Assertion은 **서명(Signature)**되어 위조 불가능.
• SP는 사전에 IdP의 공개키를 등록해 두고, Assertion의 진위를 검증함.

이 덕분에 보안성과 사용자 편의성을 모두 충족시킬 수 있습니다.

---

흐름을 정리하면

1. 사용자는 SP 접속
2. SP가 인증 요청 → 브라우저가 IdP로 리디렉션
3. 사용자 IdP 로그인
4. IdP가 SAML Assertion 생성
5. 브라우저가 SP로 전달
6. SP가 Assertion 확인 후 로그인 처리
7. 다른 SP 접근 시 자동 로그인 가능

---

다음 편 예고

다음 글에서는 SAML Assertion이 실제로 어떻게 생겼는지, XML 구조, 디지털 서명은 어떤 식으로 붙는지 등 Assertion의 내부를 깊이 있게 파헤쳐보겠습니다.

 

실제 예제와 함께, 보안적으로 중요한 요소들을 살펴볼 예정입니다.