ActYourValue 님의 블로그

여기까지 온 당신, 실무 바로 전 단계입니다먼 길 오셨습니다. 10편 동안 우리는 SSO가 어떻게 동작하는지, SAML이 어떻게 인증을 처리하는지, 그리고 실제 기업 환경에서는 어떤 식으로 구현되고, 어떤 보안 위협이 존재하는지까지 함께 알아봤습니다. 이제 단순한 개념 이해를 넘어서, **“트래픽을 눈으로 보고, 흐름을 해석하며, 문제를 추적할 수 있는 실무 감각”**까지 갖추게 되셨습니다.지금까지 배운 핵심 요약주제요약 포인트1편전체 흐름 개요: DNS → TCP/HTTPS → IdP 인증 → SP 로그인2편도메인 해석과 주소 찾기: DNS, 캐시, 리디렉션 흐름3편TCP 핸드셰이크와 TLS: 서버와 안전하게 연결하는 방법4편사용자의 ID/PW가 IdP로 어떻게 전달되는가5편SAML Assertion ..

강력한 SSO, 하지만 위험도 크다?SSO(Single Sign-On)는 정말 편리한 기술입니다. 하지만 이 편리함은 보안이 제대로 설정되지 않으면 오히려 **전사적 보안의 단일 실패 지점(Single Point of Failure)**이 되기도 합니다."한 번 뚫리면, 다 뚫린다." 특히 SAML 기반의 SSO는 XML 서명과 리디렉션 흐름을 기반으로 하기 때문에, 아는 사람에겐 익숙하지만, 모르는 사람에겐 취약한 구조가 되기 쉽습니다.1. SAML Assertion 위조 공격공격 시나리오:공격자가 SP로 전달되는 **SAML Assertion(XML)**을 위조해 자신이 인증된 사용자처럼 속이는 시도.admin@example.com로 바꾸는 식.XML 구조는 유지하지만, 서명을 일부만 감싸도록 조작할..

이제는 진짜 눈으로 본다 – 개발자 도구를 켜자지금까지 SSO의 개념과 흐름, SAML Assertion 구조, Azure AD·Okta 같은 실제 사례까지 알아봤습니다. 이번 편에서는 진짜 브라우저 안에서 무슨 일이 벌어지는지 직접 확인해보겠습니다. 사용 도구는 바로 크롬 개발자 도구 (DevTools). 프런트엔드 개발자들만 쓰는 게 아닙니다. SSO 트래픽을 이해하고, 디버깅하고, 보안 점검하기 위해 필수입니다.실습 환경 준비실습 예제예: Google Workspace, Microsoft 365, Okta Demo, GitHub SSO 연동 계정 등(개인적으로 사용하는 Google 계정도 가능)준비 도구크롬 브라우저 (또는 Edge, Brave 등 Chromium 기반 브라우저)DevTools 열기..

기업에서 실제로 쓰는 SSO 시스템지금까지 우리는:로그인 흐름을 따라가고 (DNS, HTTPS, SAML, Assertion)인증과 세션 관리 원리를 이해했습니다이제 궁금해지죠.“실제로 회사에서는 어떤 시스템으로 이걸 구현하나요?” 대표적으로 많이 쓰이는 시스템은 다음과 같습니다:시스템유형예시사용처Azure ADMicrosoft 기반 IdPMicrosoft 365, Teams, SharePoint 등Okta클라우드 기반 IdPSlack, Zoom, GitHub 등 SaaS 연동OneLogin클라우드 기반 IdPSalesforce, AWS 등과 통합AD FS온프레미스 IdP사내 시스템 중심 환경 사례 1: Azure Active Directory + Microsoft 365상황홍길동 씨는 hong@cont..

SSO의 마법: 한 번 로그인으로 모든 서비스 접속회사에서 업무 시작할 때 한 번 로그인만 했을 뿐인데…이메일도 열리고메신저도 되고사내 포털, 클라우드 문서, ERP까지 자동 로그인?이 놀라운 경험은 Single Sign-On (SSO) 덕분입니다. 그런데 이 마법 같은 일이 어떻게 가능할까요?지난 글 복습: 로그인은 이렇게 이뤄졌죠사용자는 서비스 제공자(SP)에 접속SP는 사용자를 IdP로 리디렉션사용자는 IdP에서 로그인 (ID/PW)IdP는 SAML Assertion을 생성브라우저가 SP에 Assertion 전달SP는 Assertion을 검증하고 로그인 세션 생성그럼 이제 이 질문이 생깁니다. “왜 다른 SP에 접속해도 또 로그인하지 않아도 되지?”비밀 1: IdP 세션 쿠키핵심은 바로 IdP가 브..

"이 사용자는 인증됐습니다"라는 인증서, SAML Assertion앞선 글에서 우리는 IdP가 사용자의 로그인에 성공하면, SP에게 **SAML Assertion**이라는 걸 전달한다는 걸 배웠습니다. 이 Assertion은 마치 "이 사람은 누구다"라는 사실을 증명하는 디지털 신분증 같은 역할을 하죠. 그럼 그 안에는 어떤 정보가 들어있고, 어떻게 위조되지 않도록 보호되는 걸까요?SAML Assertion의 구성요소SAML Assertion은 XML 기반 문서입니다. 아주 단순하게 요약하면 다음과 같은 구조로 되어 있습니다:Assertion> Issuer>https://idp.company.comIssuer> Subject> NameID>hong@company.comNameID> S..

로그인 창이 떴다! 이제 무슨 일이 벌어질까?이제 여러분의 브라우저는 서버와 안전하게 연결되었고, 로그인 창이 떴습니다. ID와 비밀번호를 입력하는 순간, 사용자 인증 여정의 본격적인 클라이맥스가 시작됩니다. 하지만 이 로그인 창, 우리가 알고 있는 일반적인 폼 로그인과는 다릅니다. SSO 환경에서는 인증을 **서비스 제공자(SP)**가 직접 하지 않고, **IdP(Identity Provider)**에게 위임합니다.SP와 IdP는 어떤 역할일까?SP (Service Provider): 사용자가 접근하려는 실제 서비스 (예: 사내메일, 구글워크스페이스, Microsoft 365 등)IdP (Identity Provider): 사용자의 신원을 확인해주는 인증 기관 (예: Azure AD, Okta, One..

연결을 시작합니다: IP를 알았으니 인사부터앞서 2편에서, 브라우저가 login.company.com의 IP 주소를 DNS를 통해 찾는 과정을 따라가 봤습니다. 이제 우리는 주소를 얻었으니, 다음은 "이 주소에 말을 걸어보는 일"입니다. 이게 바로 서버와의 연결입니다. 하지만 인터넷 세상에선 아무나 대뜸 말을 걸 수 없습니다. 정중하게, 규칙에 따라 “통신해도 되나요?”라는 악수 절차를 밟아야 하죠. 이 과정은 크게 두 가지 단계로 나뉩니다:TCP 3-way 핸드셰이크HTTPS 연결 (TLS Handshake)TCP 3-Way Handshake – “만나도 될까요?”비유: 통화를 시작하는 전화기이 과정을 전화 통화로 비유해보면 이렇게 됩니다:내가 친구에게 전화 건다 (SYN)친구가 “여보세요? 누구세요?..

로그인 여정의 시작: 도메인부터 찾아야 한다지난 글에서 우리는 SSO(Single Sign-On)의 전체적인 흐름을 간단히 살펴봤습니다. 이번 글부터는 그 여정 하나하나를 따라가 볼 텐데요, 첫 번째 주제는 바로 **"주소 찾기"**입니다. 생각해보세요. 여러분이 회사 웹메일 사이트에서 로그인 버튼을 누르자 브라우저에 SSO 로그인 창이 떴습니다. 그런데 이 로그인 창이 뜨려면 먼저 **“어디에 접속할지”**를 알아야 합니다. 사람은 login.company.com처럼 주소를 기억하지만, 컴퓨터는 숫자(IP 주소)로만 통신합니다. 이 주소를 숫자로 바꾸는 게 바로 DNS의 역할입니다. 그런데, 무조건 물어보는 게 아니라 우선 "예전에 가봤던 기억"부터 떠올립니다. 즉, 캐시를 먼저 뒤지는 거죠.1단계: ..

웹에서 SSO(Single Sign-On)를 이용하면 한 번 로그인으로 여러 서비스에 접근할 수 있습니다. 예를 들어 회사 계정 하나만으로 메일, 협업 툴, 사내 시스템 등에 다시 로그인할 필요 없이 사용할 수 있습니다. 하지만 이런 편리함 뒤에는 DNS 조회, HTTPS 연결, IdP/SP 통신, SAML Assertion 같은 복잡한 과정이 숨어져 있습니다. 이번 글에서는 사용자가 SSO 로그인 창에서 ID/PW를 입력하는 순간부터 인증이 완료돼 다른 서비스까지 자동 로그인되는 전체 흐름을 살펴봅니다. DNS/캐시로 도메인을 찾고, HTTPS로 보안 연결을 설정한 후, IdP에서 인증한 뒤 SAML Assertion을 통해 SP가 로그인을 처리하는 과정을 살펴보겠습니다. 끝으로 이어질 연재 시리즈에서..