security
회사에서 Slack, Jira, Notion, Confluence, 사내 ERP 등 여러 시스템을 함께 사용할 때, 로그인을 매번 반복하면 불편합니다. 그래서 회사들은 보통 SSO(Single Sign-On) 을 도입합니다. 그리고 이 SSO를 만들 때 많이 사용되는 방식 중 하나가 SAML입니다. 그런데 요즘은 OAuth, OIDC도 많이 이야기하고 있어서 "요즘 시대에 SAML은 이제 구식 기술 아닌가?"라고 생각할 수 있습니다. 하지만 결론부터 말하면, SAML은 지금도 기업 환경에서는 매우 많이 쓰는 표준입니다.
SAML(Security Assertion Markup Language)은 IdP(Identity Provider)와 SP(Service Provider)가 서로 “이 사용자가 인증되었음”을 안전하게 확인할 수 있도록 해주는 방식입니다.
SAML이 하는 일은 딱 하나입니다. 로그인을 IdP에서 했다는 사실을 SP에게 안전하게 전달합니다.
우리가 로그인할 때, SAML은 SAML Assertion 이라는 서명된 XML 문서를 사용합니다. 이 안에는 다음 정보가 담깁니다.
이걸 SP가 받아서 검증하고 로그인 처리를 합니다.
실제 기업 환경에서는 IdP(예: Google Workspace, Okta)와 SP(예: MongoDB, Jira, Slack)를 연결할 때 서로가 신뢰할 수 있도록 몇 가지 필수 정보를 교환해야 합니다. 아래는 Google Workspace에서 MongoDB와 SAML 연동을 설정할 때 볼 수 있는 항목들입니다.
| 항목 | 설명 |
|---|---|
| ACS URL (Assertion Consumer Service URL) | SP가 SAML 응답을 받을 엔드포인트입니다. IdP는 사용자가 로그인에 성공하면 이 URL로 SAML Assertion(XML)을 전송합니다. |
| 엔티티 ID(Entity ID) | IdP가 누구에게 토큰을 보낼지 식별하기 위한 고유 식별자입니다. 보통 SP의 메타데이터에 정의되어 있습니다. |
| 인증서(Certificate) | IdP가 서명한 SAML Assertion의 무결성을 검증하기 위해 사용됩니다. SP는 이 인증서를 통해 서명을 검증하여 위조 여부를 판단합니다. |
| 이름 ID(Name ID) | 로그인한 사용자를 식별하기 위한 값입니다. 일반적으로 이메일 주소나 사번 같은 고유 ID가 사용됩니다. |
이 값들이 IdP와 SP 양쪽 설정에 정확히 일치해야만, SAML 기반 SSO가 정상적으로 동작합니다.
| 이유 | 설명 |
|---|---|
| 오래되고 안정된 표준 | 20년 가까이 엔터프라이즈 인증 표준으로 자리 잡음 |
| 대부분의 회사 솔루션이 지원 | Jira, SAP, AD 계열, 레거시 시스템 호환 유리 |
| 웹 브라우저 중심 환경에 최적화 | 사내 포털/업무 시스템에 자연스럽게 적용 |
| 그룹/조직 정보를 함께 전달 용이 | “이 사람은 영업팀” 같은 정보 매핑 쉬움 |
기업 내부 시스템을 쓰는 환경이라면 거의 기본값이 SAML입니다.
| 항목 | SAML | OIDC |
|---|---|---|
| 형태 | XML 기반 | JSON 기반 |
| 메인 사용처 | 기업 내부 시스템, 사내 포털 | 일반 웹/모바일, 소셜 로그인 |
| 토큰 형태 | SAML Assertion | ID Token (JWT) |
| 요약 | 안정적이고 오래됨 | 가볍고 현대적임 |
보통 사내 환경에서는 SAML을 사용하고 모바일/웹 서비스에서는 OICD를 사용합니다.
| 항목 | 이유 |
|---|---|
| 사용자 ID 매칭 방식 | 이메일이 바뀌면 안 됨 → UUID 같은 고정 값 권장 |
| 그룹/역할 매핑 | 로그인 이후 권한 처리가 중요 |
| 로그아웃 방식 | 모든 서비스에서 함께 로그아웃할지 결정 필요 |
| 시간 동기화 | SAML 토큰은 유효시간이 있어 서버 시간 차이가 중요 |