Sự khác biệt giữa OpenID và SAML là gì?
Câu trả lời:
Bản gốc OpenID 2.0 vs SAML
Chúng là hai giao thức xác thực khác nhau và chúng khác nhau ở cấp độ kỹ thuật.
Từ xa, sự khác biệt bắt đầu khi người dùng bắt đầu xác thực. Với OpenID, thông tin đăng nhập của người dùng thường là địa chỉ HTTP của tài nguyên chịu trách nhiệm xác thực. Mặt khác, SAML dựa trên sự tin tưởng rõ ràng giữa trang web của bạn và nhà cung cấp nhận dạng nên việc chấp nhận thông tin đăng nhập từ một trang web không xác định là khá hiếm.
Danh tính OpenID rất dễ để có được trên mạng. Là nhà phát triển, sau đó bạn có thể chấp nhận người dùng đến từ các nhà cung cấp OpenID rất khác nhau. Mặt khác, nhà cung cấp SAML thường phải được mã hóa trước và bạn liên kết ứng dụng của mình với chỉ các nhà cung cấp nhận dạng được chọn. Có thể thu hẹp danh sách các nhà cung cấp nhận dạng OpenID được chấp nhận nhưng tôi nghĩ điều này sẽ trái với khái niệm OpenID chung.
Với OpenID, bạn chấp nhận danh tính đến từ các máy chủ tùy ý. Có người tuyên bố là http://someopenid.provider.com/john.smith. Làm thế nào bạn sẽ phù hợp với điều này với một người dùng trong cơ sở dữ liệu của bạn? Bằng cách nào đó, ví dụ bằng cách lưu trữ thông tin này với một tài khoản mới và nhận ra điều này khi người dùng truy cập lại trang web của bạn. Lưu ý rằng mọi thông tin khác về người dùng (bao gồm tên hoặc email của anh ấy) đều không thể tin cậy được!
Mặt khác, nếu có sự tin tưởng rõ ràng giữa ứng dụng của bạn và Nhà cung cấp Id SAML, bạn có thể nhận được thông tin đầy đủ về người dùng bao gồm tên và email và thông tin này có thể được tin cậy, chỉ vì mối quan hệ tin cậy. Điều đó có nghĩa là bạn có xu hướng tin rằng Nhà cung cấp Id bằng cách nào đó đã xác thực tất cả thông tin và bạn có thể tin tưởng ở cấp ứng dụng. Nếu người dùng đi kèm với mã thông báo SAML do nhà cung cấp không xác định cấp, ứng dụng của bạn sẽ từ chối xác thực.
Kết nối OpenID vs SAML
(phần thêm 07-2017, mở rộng 08-2018)
Câu trả lời này có từ năm 2011 và tại thời điểm đó OpenID là viết tắt của OpenID 2.0 . Sau đó, ở đâu đó vào năm 2012, OAuth2.0 đã được xuất bản và vào năm 2014, OpenID Connect (một dòng thời gian chi tiết hơn ở đây ).
Đối với bất kỳ ai đang đọc điều này hiện nay - OpenID Connect không giống với OpenID, câu trả lời ban đầu đề cập đến , thay vào đó là một bộ tiện ích mở rộng cho OAuth2.0.
Trong khi câu trả lời này có thể làm sáng tỏ từ quan điểm về khái niệm, một phiên bản rất ngắn gọn cho một người nào đó đến với nền OAuth2.0 là OpenID Connect là trên thực tế OAuth2.0 nhưng nó cho biết thêm một cách tiêu chuẩn của truy vấn thông tin người dùng , sau khi thẻ truy cập có sẵn
Đề cập đến câu hỏi ban đầu - điểm khác biệt chính giữa OpenID Connect (OAuth2.0) và SAML là cách xây dựng mối quan hệ tin cậy giữa ứng dụng và nhà cung cấp nhận dạng:
SAML xây dựng mối quan hệ tin cậy trên chữ ký số, mã thông báo SAML do nhà cung cấp nhận dạng được cấp là các XML đã ký, ứng dụng xác nhận chữ ký và chứng chỉ mà nó xuất trình. Thông tin người dùng được bao gồm trong mã thông báo SAML, cùng với các thông tin khác.
OAuth2 xây dựng mối quan hệ tin cậy trên một cuộc gọi HTTP trực tiếp từ ứng dụng đến danh tính. Yêu cầu chứa mã thông báo truy cập (được ứng dụng thu được trong luồng giao thức) và phản hồi chứa thông tin về người dùng.
OpenID Connect tiếp tục mở rộng điều này để có thể nhận được danh tính mà không cần thêm bước này liên quan đến cuộc gọi từ ứng dụng đến nhà cung cấp nhận dạng. Ý tưởng này dựa trên thực tế là các nhà cung cấp OpenID Connect trên thực tế phát hành hai mã thông báo,
access_tokencùng một vấn đề OAuth2.0 và một vấn đề mới,id_tokenđó là mã thông báo JWT , được ký bởi nhà cung cấp nhận dạng. Ứng dụng có thể sử dụngid_tokenđể thiết lập phiên cục bộ, dựa trên các khiếu nại có trong mã thông báo JWT nhưngid_tokenkhông thể sử dụng để truy vấn thêm các dịch vụ khác, các cuộc gọi như vậy đến dịch vụ của bên thứ ba vẫn nên sử dụngaccess_token. Bạn có thể nghĩ về OpenID Connect sau đó như là sự kết hợp giữa SAML2 (mã thông báo đã ký) và OAuth2 (mã thông báo truy cập), vì OpenID Connect chỉ liên quan đến cả hai.
OpenID và SAML2 đều dựa trên cùng một khái niệm về nhận dạng liên kết. Sau đây là một số khác biệt giữa chúng ..
- SAML2 hỗ trợ đăng xuất một lần - nhưng OpenID thì không
- Các nhà cung cấp dịch vụ SAML2 được kết hợp với Nhà cung cấp nhận dạng SAML2, nhưng các bên liên quan đến OpenID không được kết hợp với Nhà cung cấp OpenID. OpenID có một giao thức khám phá tự động phát hiện ra Nhà cung cấp OpenID tương ứng, một khi OpenID được đưa ra. SAML có giao thức khám phá dựa trên Giao thức dịch vụ khám phá nhà cung cấp nhận dạng.
- Với SAML2, người dùng được ghép nối với SAML2 IdP - số nhận dạng SAML2 của bạn chỉ hợp lệ đối với SAML2 IdP đã cấp nó. Nhưng với OpenID, bạn sở hữu số nhận dạng của mình và bạn có thể ánh xạ nó tới bất kỳ Nhà cung cấp OpenID nào bạn muốn.
- SAML2 có các ràng buộc khác nhau trong khi OpenID ràng buộc duy nhất có HTTP
- SAML2 có thể là do Nhà cung cấp dịch vụ (SP) khởi xướng hoặc Nhà cung cấp nhận dạng (IdP) được khởi xướng. Nhưng OpenID luôn bắt đầu SP.
- SAML 2 dựa trên XML trong khi OpenID thì không.
- Hầu hết các ứng dụng được phát triển trong 3 năm qua chỉ hỗ trợ OpenID Connect.
- 92% yêu cầu xác thực 8B + được Microsoft Azure AD trao vào tháng 5 năm 2018 là từ các ứng dụng hỗ trợ OpenID Connect.
Đặt các chi tiết kỹ thuật sang một bên, khá muộn cho bữa tiệc, điều tôi hiểu rằng sự khác biệt lớn nhất giữa SAML và các tiêu chuẩn xác thực khác (bao gồm OpenID) là
SAML yêu cầu Nhà cung cấp danh tính (IDP) và Nhà cung cấp dịch vụ (SP), phải biết nhau trước khi ra tay, được định cấu hình trước , xác thực tĩnh và ủy quyền. OpenId (+ Connect) không có yêu cầu như vậy.
Điều này rất quan trọng đối với IDP muốn kiểm soát hoàn toàn việc ai truy cập dữ liệu. Một phần của tiêu chuẩn là cấu hình những gì được cung cấp cho các SP cụ thể.
Ví dụ: một ngân hàng có thể không muốn người dùng của mình truy cập bất kỳ dịch vụ nào ngoại trừ một số dịch vụ được xác định trước (vì các quy định hoặc các quy tắc bảo mật nghiêm ngặt khác).
Điều này không có nghĩa là IDI OpenId, không thể thực thi một hạn chế như vậy. Người triển khai OpenID có thể kiểm soát quyền truy cập, nhưng đó không phải là mục đích của OpenID.
Khác với sự khác biệt được xác định trước, nghiêm ngặt, tĩnh, kiểm soát truy cập, về mặt khái niệm (không phải về mặt kỹ thuật), OpenID Connect và SAML là tương tự nhau.
Tóm lại, nếu bạn là SP, bạn nên hỗ trợ những gì khách hàng yêu cầu:
- Nếu khách hàng của bạn là khách hàng người dùng cuối cá nhân (ví dụ sử dụng id google của họ), hãy quên SAML. Sử dụng kết nối OpenID.
- Nếu khách hàng của bạn là ngân hàng muốn nhân viên của mình sử dụng dịch vụ của bạn và chỉ xuất danh sách dữ liệu tĩnh mà họ sẽ cung cấp cho dịch vụ của bạn, ngân hàng có thể sẽ muốn bạn hỗ trợ SAML. Ngân hàng có thể có triển khai OpenID với hạn chế của khách hàng, đó sẽ là ngày may mắn của bạn :)
Cả SAML và OpenID đều có thể đóng vai trò là nhà cung cấp nhận dạng (viết tắt IdP) tức là giao thức xác thực phi tập trung (nhận dạng đăng nhập một lần).
Các S ecurity Một ssertion M arkup L anguage ( SAML ) là một tập hợp hồ sơ để trao đổi xác thực và ủy quyền dữ liệu trên các lĩnh vực an ninh. Trong mô hình miền SAML, nhà cung cấp nhận dạng là một loại thẩm quyền xác thực đặc biệt. Cụ thể, nhà cung cấp nhận dạng SAML là một thực thể hệ thống đưa ra các xác nhận xác thực kết hợp với hồ sơ SSO của SAML. Một bên tin cậy sử dụng các xác nhận xác thực này được gọi là nhà cung cấp dịch vụ SAML. Nguồn
O pen ID C onnect ( OIDC ) là lớp xác thực trên OAuth 2.0, khung ủy quyền. Tiêu chuẩn được kiểm soát bởi OpenID Foundation. OAuth dành cho giao thức ủy quyền, thay vì giao thức xác thực và OpenID được thiết kế đặc biệt dưới dạng giao thức xác thực. OIDC sử dụng Mã thông báo Web JSON đơn giản (JWT), chúng dễ sử dụng hơn bởi JavaScript.
Sử dụng OAuth nếu người dùng của bạn có thể chỉ muốn đăng nhập bằng Facebook hoặc Twitter. Sử dụng OpenID nếu người dùng của bạn là những người yêu thích chạy các nhà cung cấp OpenID của riêng họ vì họ "không muốn ai khác sở hữu danh tính của họ".
