OIDC hay SAML: cái nào bạn thực sự cần

Mọi đội ngũ xây dựng phần mềm B2B đều gặp cùng một ngã rẽ vào lần đầu tiên một khách hàng nghiêm túc nói "chúng tôi cần SSO." Hai từ viết tắt, OIDC và SAML, cả hai đều tự nhận là câu trả lời, và một internet đầy những bảng so sánh bảo bạn rằng SAML là "doanh nghiệp" còn OIDC là "hiện đại" rồi để bạn bế tắc y hệt như trước. Đây là phiên bản thực sự giúp ích cho việc triển khai.

Chúng là gì

SAML ra đời năm 2005 và nó là XML. Một nhà cung cấp danh tính ký một assertion ("đây là alice@bigco.com, đây là các nhóm của cô ấy") rồi gửi nó tới ứng dụng của bạn, ứng dụng kiểm tra chữ ký và đăng nhập cho cô ấy. Nó được xây dựng cho trình duyệt và cho danh tính lực lượng lao động, vào một thời kỳ mà "doanh nghiệp" có nghĩa là Active Directory chạy tại chỗ và một ngăn xếp SOAP. Nó dài dòng, nó cũ kỹ, và nó hiện diện khắp mọi nơi bên trong các tổ chức lớn, đó là sự thật duy nhất về nó có ý nghĩa với bạn.

OIDC ra đời năm 2014 và nó là JSON cùng các JWT, nằm trên nền OAuth 2.0. Một nhà cung cấp danh tính phát hành một ID token để ứng dụng của bạn xác thực. Nó được xây dựng cho web hiện đại: SPA, ứng dụng di động, API, đăng nhập mạng xã hội. Nó gọn gàng hơn, được đặc tả tốt hơn cho những thứ bạn thực sự xây dựng ngày nay, và là giao thức mà hầu hết các hệ thống danh tính xây mới bây giờ đều nói.

Khi nào mỗi cái thắng thế

Câu trả lời thành thật cho "tôi nên xây cái nào" là bạn gần như không bao giờ được quyền chọn. Bạn xây cái mà bộ phận IT của khách hàng đã chọn, và họ đã chọn nó từ rất lâu trước khi nghe đến bạn.

• Một khách hàng dùng Okta, Entra ID, hay Google Workspace thường có thể làm được cả hai, và OIDC là con đường dễ chịu hơn.
• Một khách hàng dùng ADFS đời cũ, một IdP cũ kỹ chạy tại chỗ, hay một danh sách kiểm tra mua sắm viết từ năm 2016 sẽ đưa cho bạn một mớ metadata SAML và một lời mời họp, và đó là hồi kết của cuộc thảo luận.
• Các ứng dụng của riêng bạn, bảng điều khiển và ứng dụng di động của bạn, thì muốn OIDC, chấm hết. Bạn sẽ chẳng bao giờ với tới SAML để đăng nhập một người dùng vào ứng dụng React của chính mình.

Vậy là bức tranh chia ra rõ ràng: OIDC cho cái hiện đại và cái của chính mình, SAML cho "vì doanh nghiệp bảo thế." Bán cho đủ nhiều doanh nghiệp và bạn sẽ được yêu cầu cả hai. Không phải rồi sẽ tới một lúc nào đó. Mà là lặp đi lặp lại.

Những cái bẫy, và đây là chỗ tự xây trở nên đắt đỏ

Vấn đề của SAML là nó là một giao thức XML có chữ ký, và XML có chữ ký là một trong những thứ nguy hiểm một cách đáng tin cậy nhất trong mật mã ứng dụng. Có nhiều cách nổi tiếng để làm sai việc xác minh chữ ký SAML:

• Bọc chữ ký (XSW): kẻ tấn công di chuyển phần tử đã được ký và lén đặt một assertion giả mạo, không có chữ ký, vào đúng chỗ mà bộ phân tích cú pháp của bạn thực sự đọc. Nếu bạn kiểm tra chữ ký và đọc assertion thành hai bước riêng biệt, thì bạn nhiều khả năng dính lỗ hổng, và gần như mọi triển khai đầu tiên đều làm đúng như thế.
• Chuẩn hóa và chèn chú thích: lớp lỗi năm 2018 trong đó user@company.com<!---->.evil.com được chuẩn hóa theo một kiểu cho việc kiểm tra chữ ký và theo một kiểu khác cho chuỗi mà mã của bạn đọc, thế là bạn vui vẻ xác thực nhầm người. Những CVE có thật, trên nhiều thư viện lớn.
• Những cái âm thầm hơn: ký phản hồi nhưng không ký assertion, chấp nhận các assertion không có chữ ký, tin tưởng issuer do IdP cung cấp mà không ghim nó lại, đặt sai khung thời gian hiệu lực của assertion. Mỗi cái là một cái bẫy riêng, và mỗi cái đều đã được đẩy lên môi trường production bởi những người vốn biết rõ mình đang làm gì.

OIDC tỉnh táo hơn một cách rõ rệt, nhưng nó không phải không có những cạnh sắc. Bạn vẫn phải xác thực đúng các claim (iss, aud, exp, và nonce), dùng PKCE, từ chối luồng implicit đã chết từ lâu, và xoay vòng cùng lưu cache JWKS mà không từ chối một token được ký bằng một khóa mà bạn chưa kịp tải về. Khác biệt là những cái bẫy của OIDC đều được ghi chép tài liệu, có hình hài JSON, và được xử lý đúng theo mặc định trong hầu hết thư viện. Những cái bẫy của SAML có hình hài XML và đã nuốt chửng những đội bảo mật được trang bị tốt hơn đội của bạn nhiều.

Câu trả lời thực sự

"OIDC hay SAML" là câu hỏi sai, bởi vì câu trả lời đúng cho một sản phẩm B2B là "cả hai." Các khách hàng hiện đại và các ứng dụng của chính bạn muốn OIDC. Các khách hàng doanh nghiệp của bạn sẽ bắt buộc dùng SAML theo một lịch trình bạn không kiểm soát được. Xây cho một cái, và cuộc gọi bán hàng thứ ba sẽ làm nó vỡ vụn.

Thứ bạn thực sự cần là một cách để chấp nhận bất kỳ giao thức nào mà mỗi khách hàng mang tới, mà không phải dựng lên hai ngăn xếp, hai bộ đường ống metadata, và hai cơ hội độc lập để làm sai việc xác minh chữ ký. Việc triển khai mới là cái giá phải trả. Việc lựa chọn chưa bao giờ là phần khó.

Đó là phần Authagonal gánh giúp bạn. Mỗi tenant đều có SAML 2.0 với nhập metadata chỉ bằng một cú nhấp và liên hợp OIDC với những nhà cung cấp mà khách hàng của bạn vốn đã dùng, trên cùng một trang đăng nhập, không tính phí theo từng kết nối cho cả hai. Bạn không phải tự cài đặt việc xác minh chữ ký XML, bạn không phải trông nom một bộ cache JWKS, và bạn không phải xây lại bất cứ thứ gì trong số đó khi khách hàng tiếp theo xuất hiện và nói giao thức kia. Xem những gì được bao gồm.