기업 IT 환경에서 싱글사인온(SSO)을 이야기할 때 SAML을 빼놓기는 어렵다. 2002년 OASIS 산하 보안 서비스 기술위원회(SSTC)가 만든 이 XML 기반 인증 프로토콜은 SaaS가 폭발적으로 늘어나던 2000년대 후반, 사용자가 수많은 웹 서비스에 한 번의 로그인으로 접근하게 해주는 표준으로 자리 잡았다. 예일대의 CAS, Internet2의 Shibboleth, 마이크로소프트의 ADFS, 노르웨이 Uninett의 simpleSAMLphp 등 학계와 공공 영역이 초기 실험장 역할을 했고, 이후 Ping Identity, OneLogin, Okta 같은 상용 기업들이 이를 발판 삼아 수십억 달러 규모의 인증 산업을 일궈냈다. 그러나 Trail of Bits의 이번 글은 이 성공한 프로토콜이 이제 스스로의 복잡성에 짓눌려 무너지고 있으며, 은퇴시키고 OpenID Connect(OIDC)로 옮겨갈 때가 됐다고 주장한다.
모래 위에 지은 집, XML
필자가 SAML을 '나쁜 설계의 프랙탈'이라 부르는 근본 이유는 그것이 XML 위에 세워졌다는 데 있다. XML은 태그, 요소, 속성, 주석, 네임스페이스, 스키마, CDATA, DOCTYPE 등 다뤄야 할 개념이 많고, XXE, 엔티티 확장(이른바 'billion laughs'), DTD 조회를 통한 SSRF, XPath·XSLT 인젝션 같은 오래된 보안 버그 클래스를 여전히 안고 있다. SAML 라이브러리는 정작 인증 로직에 도달하기도 전에 이 모든 함정을 처리해야 한다. 반면 JSON은 키, 값, 객체, 리스트 정도로 구성 요소가 단순하다. 인용된 보안 연구자 토머스 프테이섹의 표현처럼, SAML은 XML 서명 검증이 신뢰할 수 있다고 '가정하면' 잘 작동하지만, 실제 그 검증은 대부분 아무도 읽지 않는 C 코드베이스 libxmlsec을 감싸는 방식으로 이뤄진다는 점이 문제다.
이 위태로움이 구체적으로 드러나는 지점이 XML 서명 래핑(XSW) 공격이다. 필자는 2012년 논문 'On Breaking SAML: Be Whoever You Want to Be'를 이 분야의 원류로 꼽는다. 이 연구는 이론을 실제 구현과 대조하고 XSW 취약점을 자동으로 점검하는 방법을 제시했으며, 당시 XSW 개념이 거의 알려지지 않았음에도 simpleSAMLphp가 이에 견고했다는 점이 필자가 Duo의 온프레미스 게이트웨이 제품(DAG)을 이 라이브러리 위에 구축한 이유였다고 한다. 주목할 대목은 버그 클래스가 이미 오래전부터 알려졌음에도 XSW가 오늘날까지 살아남았다는 사실이다.
정규화와 봉인된 서명이라는 함정
SAML의 취약성은 '정규화(C14N)'와 '봉인된 서명(enveloped signature)'이라는 두 설계 선택에서 반복적으로 새어 나온다. 정규화란 자유분방한 XML을 일관된 바이트 표현으로 만들어 해시를 계산하는 작업인데, 서비스 제공자(SP)와 신원 제공자(IdP)가 같은 표현에 합의하지 못하면 서명이 어긋나 인증이 실패한다. 2018년 켈비 루드윅이 발견한 XML 주석 우회는 바로 이 정규화 버그를 파고든 것이었고, 정규화 문제는 파서 차이(parser differential)나 라운드트립 버그로 이어지며 현대 SAML 공격 대부분의 토대가 된다. 봉인된 서명은 그 사촌 격 문제다. JWT는 서명을 페이로드와 분리해 점(.)으로 구분하지만, SAML은 서명 요소를 Assertion 안에 끼워 넣는다. 서명 대상 데이터를 서명이 다시 변형하는 셈이라, 바이트 단위로 동일한 정규 표현을 얻기가 지극히 어렵다.
나머지 두 결함은 사용성과 시대 적합성의 문제다. 하나는 'YAGNI'로 요약되는 과잉 명세다. 오늘날 실제로 쓰이는 SAML 구현은 명세의 극히 일부, 비슷한 데이터 형태만을 사용하며 SOAP나 아티팩트 바인딩 같은 상당 부분은 사실상 죽은 기능인데도 남아 복잡성을 키운다. 프테이섹이 새로 SAML을 붙인다면 Okta·OneLogin·구글·Shibboleth가 생성하는 것과 형태가 다른 메시지는 아예 거부하겠다고 말한 것도 이런 맥락이다. 다른 하나는 경직화(ossification)다. SAML은 VPN과 네트워크 분할의 시대에 설계되어 IdP와 SP가 직접 통신하지 못하는 상황을 정교하게 배려했지만, 2014년 구글의 BeyondCorp가 제로 트러스트로 전제를 뒤집고 모바일·SPA·IoT가 등장했을 때 마땅한 답을 내놓지 못했다.
실무자에게 주는 함의
한국의 인증 담당자에게 이 글이 갖는 실질적 메시지는 분명하다. 새로운 서비스를 SSO 생태계에 통합할 때는 SAML을 새로 붙이기보다 OIDC를 우선 검토하라는 것이다. 필자는 SAML이 유일하게 우위를 가졌던 시나리오, 즉 SP와 IdP가 직접 통신할 수 없는 네트워크조차 OIDC의 form post를 이용한 암묵적 흐름으로 동일하게 구현할 수 있어 마이그레이션 경로가 깔끔하다고 본다. 이미 Fly.io와 Tailscale 같은 사업자가 SAML 없이 OIDC만으로 버티고 있다는 점도 근거로 제시된다. 인증 제공자(IdP) 입장이라면 하루아침에 전환하기 어렵겠지만, 신규 고객의 SAML 온보딩을 중단하고 기존 고객에게 동등한 OIDC 구성을 제공하며 종료 시점을 정해 단계적으로 폐기하는 것이 업계에서 이미 검증된 경로라고 조언한다.
다만 이 글은 어디까지나 한 보안 컨설팅 회사의 관점이자 필자의 개인적 경험에 기반한 주장이라는 점은 감안할 필요가 있다. XML과 JSON, SAML과 OIDC의 복잡성 차이를 정량적으로 측정하지는 않았다고 필자 스스로 밝히고 있으며, 전환 난도는 고객 수와 레거시 규모에 크게 좌우된다. 그럼에도 서명 래핑과 파서 차이 공격이 20년 가까이 알려져 있었음에도 끊이지 않는다는 사실은, 특정 구현의 버그가 아니라 프로토콜의 구조적 선택에서 비롯된 문제라는 진단에 무게를 실어준다. SAML은 SSO 산업을 낳고 수많은 인증을 지켜낸 25년의 공로를 인정받아야 하지만, 그 공로가 계속 새 시스템에 이 프로토콜을 붙일 이유가 되지는 않는다는 것이 이 글의 결론이다.