웹에서 SSO(Single Sign-On)를 이용하면 한 번 로그인으로 여러 서비스에 접근할 수 있습니다. 예를 들어 회사 계정 하나만으로 메일, 협업 툴, 사내 시스템 등에 다시 로그인할 필요 없이 사용할 수 있습니다. 하지만 이런 편리함 뒤에는 DNS 조회, HTTPS 연결, IdP/SP 통신, SAML Assertion 같은 복잡한 과정이 숨어져 있습니다.
이번 글에서는 사용자가 SSO 로그인 창에서 ID/PW를 입력하는 순간부터 인증이 완료돼 다른 서비스까지 자동 로그인되는 전체 흐름을 살펴봅니다. DNS/캐시로 도메인을 찾고, HTTPS로 보안 연결을 설정한 후, IdP에서 인증한 뒤 SAML Assertion을 통해 SP가 로그인을 처리하는 과정을 살펴보겠습니다. 끝으로 이어질 연재 시리즈에서 다룰 내용을 목차 형태로 안내합니다.
네트워크 준비: DNS 조회와 캐시
로그인을 시도하면 먼저 브라우저가 도메인 이름을 DNS에 조회해 서버의 IP 주소를 찾습니다. 예를 들어 login.example.com을 방문하면 브라우저가 DNS 서버에 “이 도메인의 IP는?”을 묻습니다. 이는 전화번호부에서 회사 이름을 검색하듯 도메인을 찾는 과정과 같습니다. 한 번 조회된 결과는 DNS 캐시에 저장돼 이후 동일 주소에 더 빠르게 연결할 수 있습니다.
DNS로 IP를 찾은 뒤 브라우저는 서버와 연결합니다. SSO 로그인에 쓰는 사이트 주소와 IdP 주소 모두 같은 방식으로 조회됩니다. 회사마다 고유 도메인이 정해지면, 이를 통해 SP가 어느 IdP로 연결할지 알 수 있습니다.
안전한 연결: HTTPS 인증
IP를 확인한 후 브라우저는 HTTPS로 서버에 연결합니다. HTTPS는 데이터를 암호화해 안전하게 주고받는 프로토콜입니다. 브라우저와 서버는 TLS 핸드셰이크 과정에서 서로의 인증서를 교환하고, 사용할 암호화 방식을 결정합니다. 이 과정에서 대칭키를 생성해 암호화된 통신을 준비합니다. 덕분에 사용자의 ID/PW는 중간에 노출되지 않고 안전하게 전송됩니다.
인증 절차: IdP와 SP의 역할
SSO에는 **ID 공급자(IdP)**와 서비스 공급자(SP) 두 주체가 있습니다. IdP는 사용자의 로그인 정보를 보유하고 “이 사람이 누구인지”를 확인해 주는 시스템입니다. Google Workspace나 Okta 같은 서비스를 생각하면 됩니다. SP는 사용자가 접근하려는 웹 서비스(예: 메일, 사내 포털)입니다. SP는 사용자를 직접 인증하지 않고, IdP에 이를 위임합니다.
사용자가 SP 로그인 화면에 접속하면 SP는 사용자의 소속 IdP로 인증을 요청하기 위해 브라우저를 리디렉트합니다. 즉, SP와 IdP는 브라우저를 통해서만 통신합니다. 브라우저가 IdP 로그인 페이지에 도달하면 사용자는 아이디/비밀번호를 입력합니다. 이 정보는 암호화된 채 IdP에 전달되고 SP에는 넘어가지 않습니다. IdP는 전달받은 정보를 검사해 인증이 성공하면 SAML Assertion을 생성합니다.
SAML Assertion과 로그인 완료
SAML Assertion은 사용자가 인증되었다는 사실을 SP에 알려주는 메시지입니다. Assertion에는 인증 발행자, 발행 시간, 유효 조건 등 필요한 정보가 담겨 있습니다. 일종의 보증서처럼 “이 사용자는 인증된 구성원이다”라는 사실을 증명합니다.
IdP는 이 Assertion을 생성해 사용자 브라우저를 통해 SP로 전달합니다. SP는 Assertion의 디지털 서명을 검증한 후, Assertion에 담긴 정보로 로그인 세션을 생성합니다. 이렇게 사용자는 SP에 정상적으로 로그인됩니다. 이후 같은 IdP를 쓰는 다른 서비스에 접근하면, 비밀번호를 다시 입력하지 않고도 자동으로 로그인됩니다.
마무리: 앞으로의 시리즈 소개
이번 글에서는 SSO 로그인 과정의 전체 흐름을 살펴봤습니다. 요약하면, 도메인 조회 → HTTPS 연결 → SP→IdP 리디렉션 → IdP 인증 및 SAML Assertion 발급 → SP 로그인 과정이 일어납니다. 다음 글들에서는 이 흐름의 각 요소를 자세히 다룰 예정입니다. 주요 주제는 다음과 같습니다:
- SSO 개념과 IdP·SP 역할
- DNS/네트워크 흐름 (도메인 조회, 캐시)
- HTTPS/TLS 보안 연결
- SAML 프로토콜 (인증 요청/응답)
- SAML Assertion (발급과 검증)
- 세션 관리와 자동 로그인
그 외에도 싱글 로그아웃, OAuth/OpenID Connect와 같은 주제도 다룰 예정입니다.
참고자료: SAML 프로토콜과 SSO 개념 설명
- SSO vs SAML, 모두를 위한 설명 - https://blog.logto.io/
Logto blog · The content hub of the Logto community
Discover Logto and explore plenty of resources on authentication, authorization, identity management, open standards (OAuth, OpenID Connect, SAML), and more.
blog.logto.io
- SAML이란? | SAML 인증이 작동하는 방식 - https://www.cloudflare.com/ko-kr/learning/access-management/what-is-saml/
SAML이란? | SAML 인증이 작동하는 방식
SAML 2.0은 사용자가 인증되었음을 알리기 위해 SSO 공급자가 사용하는 기술 표준입니다. SAML 인증 방식을 알아보세요.
www.cloudflare.com
- SAML - https://developer.okta.com/docs/concepts/saml/
Understanding SAML | Okta Developer
SAML Traditionally, enterprise apps are deployed and run within the company network. For apps to obtain user information, many enterprise apps are built to integrate with corporate directories like Microsoft Active Directory. More importantly, a user's cre
developer.okta.com
'호주 IT 취업' 카테고리의 다른 글
| [SSO 로그인 흐름 3편] 서버와의 첫 만남 – 안전한 연결을 위한 ‘악수’ 과정 (TCP + HTTPS) (1) | 2025.06.17 |
|---|---|
| [SSO 로그인 흐름 2편] 로그인 버튼을 누르면 무슨 일이? – DNS와 캐시의 여정 (0) | 2025.06.16 |
| 10. 오류 / 거부 / 스팸 분류 시나리오 (1) | 2025.06.07 |
| 9. 수신자 클라이언트의 받은편지함 표시 (Outlook vs Gmail) (3) | 2025.06.07 |
| 8. 수신 메일 서버의 처리 과정 (큐잉, 저장, 바이러스 검사 등) (0) | 2025.06.06 |