SAML so với đăng nhập liên kết bằng OAuth
Câu trả lời:
Họ giải quyết các vấn đề khác nhau.
SAML là một tập hợp các tiêu chuẩn đã được xác định để chia sẻ thông tin về người dùng là ai, tập thuộc tính của họ là gì và cung cấp cho bạn cách cấp / từ chối quyền truy cập vào một thứ gì đó hoặc thậm chí yêu cầu xác thực.
OAuth thiên về việc ủy quyền quyền truy cập vào một thứ gì đó. Về cơ bản, bạn đang cho phép ai đó "hành động" như bạn. Nó được sử dụng phổ biến nhất để cấp quyền truy cập api có thể làm điều gì đó thay mặt bạn.
Chúng là hai thứ hoàn toàn khác nhau.
Một số ví dụ có thể giúp ích.
OAuth nghĩ về một twitter. Giả sử bạn đang sử dụng Google Buzz và Twitter và bạn muốn viết một ứng dụng để có thể đồng bộ hóa cả hai. Về cơ bản, bạn có thể thiết lập sự tin cậy giữa ứng dụng của mình và twitter. Lần đầu tiên bạn liên kết ứng dụng với twitter, bạn thực hiện lời nhắc cổ điển để đăng nhập vào twitter, sau đó hộp xác nhận bật lên và hỏi "Bạn có muốn cấp quyền truy cập vào« tên ứng dụng của bạn »không?" khi bạn nhấp vào "có", niềm tin đã được thiết lập và giờ đây ứng dụng của bạn có thể hoạt động như bạn trên Twitter. Nó có thể đọc các bài đăng của bạn, cũng như tạo các bài viết mới.
SAML - Đối với SAML, hãy nghĩ đến một số loại "thỏa thuận" giữa hai hệ thống thành viên không liên quan. Trong trường hợp của chúng tôi, chúng tôi có thể sử dụng US Airways và Hertz. Không có tập hợp thông tin xác thực được chia sẻ nào có thể đưa bạn từ trang web này đến trang web khác, nhưng hãy giả sử Hertz muốn cung cấp một "thỏa thuận" cho US Airways. (Cứ cho là tôi biết đây là một ví dụ cực đoan, nhưng hãy chịu đựng với tôi). Sau khi mua chuyến bay, họ sẽ cho thuê xe hơi miễn phí cho các thành viên Chủ tịch. US Airways và Hertz sẽ thiết lập một số hình thức tin cậy và một số cách để xác định người dùng. Trong trường hợp của chúng tôi, "id liên kết" của chúng tôi sẽ là địa chỉ email và đó sẽ là một cách tin cậy mà Hertz tin tưởng rằng nhà cung cấp danh tính US Airways sẽ cung cấp mã thông báo chính xác và an toàn. Sau khi đặt chuyến bay, nhà cung cấp danh tính US Airways sẽ tạo mã thông báo và điền cách họ đã xác thực người dùng, cũng như "thuộc tính" về người đó trong trường hợp của chúng tôi, thuộc tính quan trọng nhất sẽ là cấp trạng thái của người đó trong US Airways. Khi mã thông báo đã được điền, nó sẽ chuyển nó qua một số loại tham chiếu hoặc được mã hóa trong một url và khi chúng tôi đến Hertz, nó sẽ xem xét mã thông báo, xác thực nó và bây giờ có thể cho phép thuê xe miễn phí.
Vấn đề với ví dụ SAML này là nó chỉ có một trường hợp sử dụng chuyên biệt trong số nhiều trường hợp sử dụng. SAML là một tiêu chuẩn và hầu như có quá nhiều cách để bạn có thể thực hiện nó.
Ngoài ra, nếu bạn không quan tâm đến ủy quyền, bạn gần như có thể tranh luận rằng việc xác nhận xác thực qua SAML và OpenID .
Hãy xem phần giải thích đơn giản được tóm tắt ở đây:
Nhiều người nhầm lẫn về sự khác biệt giữa SAML, OpenID và OAuth, nhưng nó thực sự rất đơn giản. Mặc dù có một số trùng lặp, đây là một cách rất đơn giản để phân biệt giữa ba loại.
OpenID - đăng nhập một lần cho người tiêu dùng
SAML - đăng nhập một lần cho người dùng doanh nghiệp
OAuth - Ủy quyền API giữa các ứng dụng
Đối với những người cảm thấy thoải mái với các mẫu thiết kế OO, tôi nghĩ rằng có một hệ quả tốt đẹp đối với các mẫu bao bọc . Hãy nghĩ về các mẫu Mặt tiền , Trình trang trí và Proxy . Về cơ bản, tất cả đều giống nhau, chúng chỉ là những cái bao bọc ... Sự khác biệt là ý định của mỗi mẫu .
Tương tự, SAML, OAuth và OpenID đều hỗ trợ các ý định khác nhau thông qua một cơ chế cơ bản chung , đó là chuyển hướng đến nhà cung cấp dịch vụ / cơ quan nhận dạng cho một số tương tác riêng tư, sau đó là chuyển hướng đến ứng dụng của bên thứ ba ban đầu.
Nhìn xung quanh trên mạng, bạn sẽ thấy chồng chéo giữa các khả năng của giao thức. Xác thực qua OAuth là hoàn toàn hợp lý. SSO qua OAuth có thể không có nhiều ý nghĩa vì SAML và OpenID đặc biệt hướng tới danh tính được liên kết.
Đối với câu hỏi, trong bối cảnh công ty, SAML có vẻ thích hợp hơn OAuth cho SSO . Tôi cá là nếu bạn nhìn vào các ứng dụng của bên thứ ba mà bạn muốn tích hợp với danh tính công ty của mình, bạn sẽ thấy chúng đã được thiết kế để tích hợp với SAML / LDAP / Radius, v.v. IMO OAuth thích hợp hơn cho tương tác Internet giữa các ứng dụng hoặc có thể là các ứng dụng bao gồm Kiến trúc hướng dịch vụ trong môi trường doanh nghiệp lớn.
Các quy tắc ủy quyền cũng có thể được chỉ định trong môi trường công ty theo những cách khác. LDAP là một công cụ phổ biến cho việc này. Tổ chức người dùng thành các nhóm và liên kết các đặc quyền của ứng dụng chống lại tư cách thành viên nhóm là một cách tiếp cận phổ biến. LDAP cũng có thể được sử dụng để xác thực. Active Directory là một ví dụ tuyệt vời, mặc dù tôi thích OpenLDAP hơn.
Tìm thấy bài viết hay ở đây
SAML (Ngôn ngữ đánh dấu xác nhận bảo mật) được thiết lập các tiêu chuẩn để đạt được Đăng nhập một lần (SSO), Quản lý liên kết và danh tính.
Ví dụ : Người dùng (chính) xác thực với trang web đặt vé máy bay, AirFlyer (nhà cung cấp danh tính) đã định cấu hình SSO qua SAML với trang web đặt vé đưa đón, Shuttler (nhà cung cấp dịch vụ). Sau khi được xác thực với Flyer, người dùng có thể đặt xe đưa đón trên Shuttler mà không cần xác thực
OAuth (Ủy quyền mở) là một tiêu chuẩn để ủy quyền tài nguyên. Nó không đối phó với xác thực.
Ví dụ : Ứng dụng di động chia sẻ ảnh (người dùng OAuth) cho phép người dùng nhập ảnh từ tài khoản Instagram của họ (nhà cung cấp OAuth). Ứng dụng này sẽ gửi mã truy cập tạm thời hoặc khóa đến ứng dụng chia sẻ ảnh sẽ hết hạn sau vài giờ.
SAML có nhiều "hồ sơ" để lựa chọn cho phép người dùng khác "đăng nhập" vào trang web của bạn. SAML-P hoặc SAML Passive rất phổ biến và khá đơn giản để thiết lập. WS-Trust cũng tương tự và nó cũng cho phép liên kết giữa các trang web.
OAuth được thiết kế để ủy quyền. Bạn có thể đọc thêm ở đây:
SAMLlà để xác thực - chủ yếu được sử dụng trong kịch bản Đăng nhập Một lần . OAuthlà để ủy quyền đại diện tài nguyên.
Mã thông báo web JSON (JWT) là một giải pháp thay thế cho Mã thông báo XML SAML. JWT có thể được sử dụng với OAuth
Một tài liệu tham khảo tốt là SAML so với OAuth: Tôi nên sử dụng cái nào?
Các điều khoản liên kết thực sự có nghĩa là nhận dạng kết nối giữa các hệ thống. Nó liên quan đến SSO nhưng chúng không hoàn toàn giống nhau. Tôi thấy bài đăng trên blog này thực sự hữu ích về ý nghĩa thực sự của liên đoàn.