ActYourValue 님의 블로그

기업에서 실제로 쓰는 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..