SAML: Khi một giao thức xác thực trở thành 'mê cung' của những sai lầm thiết kế

SAML từng là xương sống của ngành công nghiệp xác thực doanh nghiệp. Nhưng sau hơn hai thập kỷ, giao thức này đang lộ rõ những lỗ hổng thiết kế căn bản khiến giới bảo mật phải đặt câu hỏi: liệu đã đến lúc nên khai tử nó?

Từ học thuật đến doanh nghiệp: nguồn gốc của SAML

Security Assertion Markup Language (SAML) ra đời năm 2002 dưới bàn tay của Ủy ban Kỹ thuật Dịch vụ Bảo mật (SSTC) thuộc tổ chức OASIS. Vào thời điểm đó, khi Internet chuyển mình từ Web 1.0 sang Web 2.0, các tổ chức và người dùng cần một cách thức đơn giản để xác thực với vô số dịch vụ web mới mọc lên như nấm.

Giới học thuật là động lực chính thúc đẩy làn sóng này: Central Authentication Service (CAS) của Đại học Yale năm 2002, Shibboleth IdP của Internet2 năm 2003, ADFS của Microsoft cùng năm, và simpleSAMLphp của Uninett vào khoảng năm 2007. Các trường đại học, giống như thời ARPANET, lại một lần nữa đóng vai trò tiên phong trong việc phát triển và ứng dụng công nghệ internet.

Khi nền tảng giao thức đã đủ chín muồi, ngành công nghiệp thương mại nhanh chóng nhảy vào. Ping Identity (2002), OneLogin (2009), Okta (2009), Duo Security (2010) — hầu hết đều được xây dựng trên nền tảng SAML, tạo nên một ngành công nghiệp trị giá hàng tỷ đô la.

Vết nứt đầu tiên: tấn công dịch chuyển chữ ký XML

Năm 2012, bài nghiên cứu "On Breaking SAML: Be Whoever You Want to Be" đã gây chấn động giới bảo mật. Nó chứng minh rằng tấn công XML Signature Wrapping (XSW) có thể cho phép kẻ tấn công mạo danh bất kỳ ai trong hệ thống xác thực SAML.

Điều đáng nói là dù bug class này đã được biết đến từ hơn một thập kỷ trước, nó vẫn tồn tại đến ngày nay. Câu hỏi đặt ra: nếu đã biết lỗ hổng, tại sao không thể sửa?

Câu trả lời nằm ở nền tảng mà SAML được xây dựng lên: XML.

"SAML thực ra khá dễ hiểu, nhưng nó được xây trên nền cát, bụi xương và tro tàn. Nó hoạt động... nếu bạn giả định rằng việc xác thực chữ ký XML là đáng tin cậy. Nhưng xác thực chữ ký XML thì cực kỳ rối rắm, đến mức hầu hết các triển khai SAML thực tế đều bọc quanh libxmlsec — một codebase C phức tạp mà chẳng ai buồn đọc."

— Thomas Ptacek, 2023

Năm sai lầm chí mạng của SAML

Theo phân tích từ Trail of Bits, SAML mắc phải năm khiếm khuyết thiết kế được xem là "tử huyệt" đối với một giao thức xác thực:

1. Được xây dựng trên XML

XML vốn đã phức tạp hơn hẳn JSON. Nhưng nghiêm trọng hơn, XML mang theo hàng loạt bug class nguy hiểm: XXE, entity expansion ("billion laughs"), DTD retrieval (SSRF), XPath/XQuery/XInclude/XSLT/CDATA injection. Một thư viện SAML phải xử lý được tất cả những vấn đề này trước khi bắt tay vào chức năng SAML thực sự.

2. Canonicalization (C14N)

Để so khớp chữ ký số, bên cung cấp dịch vụ (SP) và bên định danh (IdP) phải thống nhất một biểu diễn duy nhất của dữ liệu XML. Nhưng XML quá phức tạp để làm điều này một cách nhất quán — và chính các lỗi canonicalization đã mở đường cho hàng loạt cuộc tấn công trong gần một thập kỷ qua, từ Go standard library (2020) đến GitHub Enterprise (2025).

3. Chữ ký "bao bọc" (enveloped signatures)

Trong JWT, chữ ký tách biệt hoàn toàn khỏi payload và được phân tách bằng dấu chấm. Trong SAML, phần tử Signature được nhúng vào chính Assertion mà nó ký. Việc lấy được biểu diễn byte-for-byte tương đương về mặt canonical khi bạn cũng đang sửa đổi chính dữ liệu đó là cực kỳ khó khăn.

4. Thiết kế "nhồi nhét"

SAML chứa đựng bốn giao thức bảo mật XML trong một, và 99% triển khai thực tế chỉ dùng chưa đến 10% đặc tả. Thomas Ptacek từng khuyên: nếu thêm hỗ trợ SAML vào hệ thống mới, nên từ chối mọi thông điệp không có hình dạng giống hệt những gì Okta, OneLogin, Google hay Shibboleth tạo ra.

5. Hóa thạch (Ossification)

• OIDC giả định có HTTP, SAML thì không — nhưng SAML đã không bao giờ thích nghi với thực tế HTTPS đã trở thành xương sống của web
• OIDC giả định mạng kết nối trực tiếp, SAML thì không — phản ánh kỷ nguyên VPN và phân đoạn mạng đã lỗi thời
• OIDC phát triển hữu cơ theo thời gian, trong khi SAML được thiết kế "một phát ăn ngay" theo kiểu thác nước (waterfall)

Mọi con đường đều dẫn đến OIDC

Theo các chuyên gia, giải pháp duy nhất còn hợp lý là chuyển dịch sang OpenID Connect (OIDC). Điểm mạnh của OIDC nằm ở chỗ nó được xây dựng trên nền tảng JSON và JWT — đơn giản hơn, ít bug class hơn, và phù hợp với kiến trúc web hiện đại.

Đối với các nhà cung cấp dịch vụ, lời khuyên rất rõ ràng: hãy hỗ trợ OIDC, từ bỏ SAML. Theo Thomas Ptacek, cả Fly.io và Tailscale đã kiên quyết giữ vững lập trường này.

"Nếu Tailscale có thể giữ vững lập trường, với đối tượng khách hàng của họ, thì tôi nghĩ hầu hết các tổ chức đều làm được. Thực sự, hãy cố tránh làm SAML."

— Thomas Ptacek, 2024

Đối với các nhà cung cấp định danh, con đường dài hơn: xây dựng kế hoạch khai tử, thông báo cho khách hàng, ngừng tiếp nhận tích hợp SAML mới, cung cấp cấu hình OIDC tương đương, ấn định ngày kết thúc.

Góc nhìn cho thị trường Việt Nam

Tại Việt Nam, nhiều doanh nghiệp và tổ chức tài chính — ngân hàng, chứng khoán, bảo hiểm — vẫn đang vận hành hệ thống xác thực dựa trên SAML, đặc biệt trong các tích hợp với đối tác nước ngoài hoặc hệ thống cũ. Việc chuyển đổi sẽ không dễ dàng và tốn kém, nhưng đây là khoản đầu tư cần thiết khi các cuộc tấn công nhắm vào SAML ngày càng tinh vi và phổ biến.

Với các startup công nghệ Việt Nam đang xây dựng sản phẩm SaaS hoặc hệ thống định danh, lời khuyên là hãy bắt đầu với OIDC ngay từ đầu — tránh phải gánh khoản nợ kỹ thuật khổng lồ về sau.

SAML đã có một hành trình 25 năm đáng nể: nó khai sinh ngành công nghiệp SSO, bảo vệ vô số lượt xác thực, và tạo ra hàng tỷ đô la giá trị kinh tế. Nhưng đã đến lúc chúng ta cần một giao thức xác thực phù hợp với kỷ nguyên cloud, mobile và zero-trust — và đó là OIDC.