Trong khi tìm kiếm một giải pháp phù hợp với ứng dụng của chúng tôi và các điều khoản bảo mật của khách hàng, chúng tôi đã tìm ra OpenID, OAuth2 và SAML.
Mục lục nội dung
Authorization & Authentication cơ bản
Dự án của chúng tôi là một single-page application. Chúng tôi muốn số lượng giới hạn quyền truy vấn cho những người dùng đã ĐK. Thêm nữa chúng tôi muốn có thưởng thức tương thích với mỗi người dùng, và lượng và kiểu tài liệu họ hoàn toàn có thể thấy, ứng với vai trò và quyền hạn truy vấn của họ .Nói cách khác, chúng tôi muốn có năng lực xác nhận ( authenticate ) và phân quyền / ủy quyền ( authorize ) cho mỗi người dùng. Xác thực có nghĩa là xác định rằng một ai đó thực sự là người mà họ nhận. Phân quyền / Ủy quyền có nghĩa là quyết định hành động những tài nguyên mà một người dùng đơn cử hoàn toàn có thể truy vấn, họ hoàn toàn có thể làm gì với những tài nguyên đó. Thông thường, một ứng dụng sẽ nhu yếu mỗi thứ một chút ít .Với những website như Facebook hoặc Google, một người dùng hoàn toàn có thể đăng nhập tới một ứng dụng với một bộ giấy ghi nhận ( credential ). Sau đó cùng một bộ giấy ghi nhận này hoàn toàn có thể sử dụng để đăng nhập tới những website hoặc ứng dụng tương quan ( giống như những website nhu yếu bạn ” Đăng ký với thông tin tài khoản Facebook hoặc Google ” ) .
Tương tự, một doanh nghiệp có thể có một cổng thông tin (portal) nội bộ cho nhân viên với các trang web liên quan như timesheets, bảo hiểm y tế, hoặc các tin tức của công ty. Thay vì yêu cầu nhân viên đăng nhập tại mỗi trang web, một giải pháp tốt hơn là nhân viên đăng nhập tại cổng thông tin, và cổng thông tin sẽ tự động xác thực người dùng với các trang web liên quan khác. Giải pháp này được gọi là single sign-on/SSO (đăng nhập một lần), cho phép một người dùng nhập username và password một lần duy nhất để truy cập tới nhiều ứng dụng.
Điều này rất hữu dụng cho người dùng. Họ chỉ cần quản trị duy nhất một usename và password cho những website tương quan. Trải nghiệm người dùng cũng tốt hơn, vì họ không cần phải đăng nhập nhiều lần. Chứng nhận của người dùng ( một bộ ) sẽ được tàng trữ trong một database, thay vì nhiều ghi nhận được tàng trữ trên nhiều database. Điều này cũng có nghĩa là những lập trình viên của những ứng dụng khác nhau không cần phải tàng trữ password. Thay vào đó, họ hoàn toàn có thể đồng ý bằng chứng nhận dạng hoặc ủy quyền từ một nguồn đáng đáng tin cậy .Có nhiều giải pháp cho việc tiến hành SSO. Ba giao thức bảo mật thông tin web phổ cập nhất ( tại thời gian viết bài ) là OpenID, OAuth và SAML. Cách tiến hành và những thư viện đã có sẵn trong nhiều ngôn từ lập trình, và một giao thức đã được chuẩn hóa sẽ tốt hơn một giải pháp tùy chỉnh .
OpenID
OpenID là một chuẩn mở cho xác nhận ( authentication ), được tiếp thị bởi tổ chức triển khai phi lợi OpenID Foundation. Kể từ tháng 3 năm năm nay, đã có hơn một tỷ thông tin tài khoản OpenID được sử dụng trên internet, và những công ty như Google, WordPress, Yahoo và Paypal sử dụng OpenID để xác nhận người dùng .Một người dùng phải có một thông tin tài khoản OpenID trải qua một nhà phân phối nhận dạng ( OpenID identity provider ) ví dụ điển hình như Google. Sau đó người dùng sử dụng thông tin tài khoản này để đăng nhập vào bất kể website ( bên nhờ vào – relying party ) gật đầu xác nhận bằng OpenID ( giống như YouTube hoặc những site khác gật đầu sử dụng một thông tin tài khoản Google để đăng nhập ). Chuẩn OpenID phân phối một khuôn khổ cho việc liên kết giữa những ( nhà cung ứng nhận dạng – identity provider ) và bên phụ thuộc vào ( relying party ) .Sự trao đổi này hoàn toàn có thể so sánh với việc đi qua biên giới. Hãy tưởng tượng, Alice là một công dân Canada, cô ấy muốn thăm Mỹ. Tại biên giới, phía Mỹ nhu yếu bằng chứng nhận dạng ( hộ chiếu của cô ấy ). Bởi vì chính phủ nước nhà Mỹ tin cậy cơ quan chính phủ Canada trong việc cung ứng nhận dạng cho công dân của họ, phía Mỹ gật đầu hộ chiếu của Alice là dẫn chứng đáng đáng tin cậy về danh tính của cô ấy, và cho nên vì thế, họ để cho cô ấy vào Mỹ. Trong ví dụ này, Alice là người dùng cuối, phía Mỹ là bên nhờ vào ( relying party ), và Canada là nhà phân phối nhận dạng ( identity provider ) .Giao dịch này được gật đầu chính bới Alice hoàn toàn có thể cung ứng bằng chứng nhận dạng cho phía Mỹ, rằng cô ấy đến từ một nơi mà Mỹ tin cậy. Tương tự như vậy, bên phụ thuộc vào ( relying party ) hay chính là website người dùng đang đăng nhập phải tin yêu vào nhà phân phối nhận dạng ( identity provider ) của OpenID về việc xác định danh tính của người dùng .Trên một website, nó sẽ như thế này :
Hãy trở lại với Alice, người muốn đăng nhập vào thông tin tài khoản MyBlogger của mình ( bên nhờ vào – relying party ). Cô ấy điều hướng đến màn hình hiển thị đăng nhập, và được phân phối tùy chọn ” Đăng nhập với Google “. Khi cô ấy click vào nó, MyBlogger khởi tạo link với Google và nhu yếu nhận một giải quyết và xử lý tương quan ( handle ). Sau đó MyBlogger chuyển Alice tới trang đăng nhập của Google. Cô ấy nhập những thông tin của mình, và Google sẽ xác định tính hợp lệ của chúng. Sau đó cô ấy sẽ được chuyển hướng trở lại MyBlogger, cùng với một token để thông tin rằng Google tin cậy cô ấy chính là người mà cô ấy công bố ( Alice ). MyBlogger tin yêu token này và tạo một phiên ( sesion ) cho cô ấy .Chú ý :
- OpenID về mặt kỹ thuật là một URL mà người dùng sở hữu (ví dụ alice2016.openid.com), vì thế một vài website cung cấp tùy chọn nhập OpenID một cách thủ công.
- Phiên bản mới nhất của OpenID là OpenID Connect, nó kết hợp xác thực của OpenID (OpenID authentication) và ủy quyền/ phân quyền của OAuth2 (OAuth2 authorization).
Facebook trước đây sử dụng OpenID nhưng hiện nay đã chuyển sang Facebook Connect.
OAuth2
OAuth2 là một chuẩn mở để ủy quyền / phân quyền ( authorization ), OAuth2 cũng là nền tảng của OpenID Connect, nó cung ứng OpenID ( xác nhận – authentication ) ở phía trên của OAuth2 ( chuyển nhượng ủy quyền – authorization ) để có một giải pháp bảo mật thông tin hoàn hảo hơn. OpenID Connect ( OIDC ) được tạo ra vào đầu năm năm trước và OAuth2 trọn vẹn độc lập, chứ không phải một phần của OIDC .OAuth2 cung ứng quyền truy vấn đã được chuyển nhượng ủy quyền bảo đảm an toàn ( secure delegated access ), điều đó có nghĩa là một ứng dụng hay một client có thể thao tác hoặc truy vấn những tài nguyên trên một server đại diện thay mặt cho một người dùng, mà không cần người sử dụng phải san sẻ thông tin thông tin tài khoản của họ với ứng dụng. OAuth2 làm điều này bằng những token được tạo ra bởi một nhà phân phối nhận dạng ( indentity provider ) cho những ứng dụng bên thứ ba, với sự đồng ý chấp thuận của người dùng .Tuy nhiên tài liệu hướng dẫn OAuth của Twitter nói rằng OAuth2 là một chuẩn xác thực ( authentication standard ). Vậy nó có nghĩa là gì ? Thực tế, chuyển nhượng ủy quyền hoàn toàn có thể được sử dụng như một hình thức xác nhận ( pseudo-authentication ) .Ủy quyền sử dụng trong trường hợp của OAuth2 hoàn toàn có thể tưởng tượng như thế này : Alice sẽ rời khỏi thị xã và cô ấy muốn Bob bạn của mình trông nhà giúp. Alice đưa cho Bob chìa khóa nhà, và giờ đây anh ấy hoàn toàn có thể vào trong ngôi nhà. Chìa khóa cho phép anh ấy vào nhà, cũng giống như được cho phép một người dùng hoàn toàn có thể truy vấn tới những tài nguyên, và cái họ hoàn toàn có thể làm với những tài nguyên đó. Trong ví dụ này, chủ nhà là người dùng, Bob là client, khóa cửa là nhà phân phối nhận dạng ( identity provider ), và ngôi nhà là máy chủ tàng trữ tài nguyên .Thực tế, một trường hợp sử dụng OAuth2 hoàn toàn có thể như thế này : Alice ĐK một thông tin tài khoản mới tại NewApp và được cung ứng tùy chọn để xem ai trong số bạn hữu của cô ấy đã sử dụng NewApp, sau đó cô ấy hoàn toàn có thể liên kết với họ. Có một nút với nhãn ” nhập danh bạ từ Facebook “. Alice bấm nút đó, và cô ấy được điều hướng tới Facebook để đăng nhập. Sau khi đăng nhập thành công xuất sắc cô ấy sẽ được hỏi có muốn san sẻ list bè bạn Facebook với NewApp không. Cô ấy chọn có, và được điều hướng trở lại NewApp với một token. NewApp giờ đã có quyền ( với token ) truy vấn tới list bè bạn của Alice mà không cần cô ấy san sẻ thông tin cá thể trực tiếp với NewApp. Điều này vô hiệu rủi ro tiềm ẩn NewApp đăng nhập vào Facebook với thông tin thông tin tài khoản của Alice và làm một số ít thứ cô ấy không mong ước ( đăng status, biến hóa mật khẩu, … ) .
SAML
SAML là chuẩn truyền kiếp nhất, được tăng trưởng từ năm 2001, và lần update gần đây nhất vào năm 2005. SAML là viết tắt của Security Assertion Markup Language. Nó là một chuẩn mở phân phối cả xác nhận ( authentication ) và phân quyền / ủy quyền ( authorization ) .Về mặt kỹ thuật nó tương tự như với hai chuẩn còn lại, SAML định nghĩa một principal, là người dùng cuối đang nỗ lực truy vấn tới một tài nguyên. Có một nhà sản xuất dịch vụ ( service provider ), chính là sever web mà principal đang cố truy vấn. Và có một nhà phân phối nhận dạng ( identity provider ), sẽ tàng trữ nhận dạng và thông tin của principal .Ví dụ về Mỹ và Canada hoàn toàn có thể sử dụng để minh họa. Alice muốn vào Mỹ từ Canada. Mỹ muốn xác định danh tính hoặc những thông tin khác về cô ấy ( nếu cô ấy có một giấy phép lái xe hợp lệ, nó sẽ được cho phép cô ấy được lái xe ở Mỹ ) – họ tạo một nhu yếu tới Canada để xác nhận và / hoặc ủy quyền thông tin về Alice. Canada vấn đáp bằng cách gửi thông tin được nhu yếu cho phía Mỹ, cùng với một vài dẫn chứng rằng Canada thực sự là người gửi tin nhắn. Bằng chứng này hoàn toàn có thể là một hộ chiếu như trước đây, hoặc những sách vở được cấp bởi cơ quan chính phủ hoặc thị thực ( visa ). Và như trước đây, mạng lưới hệ thống này dựa vào sự tin cậy của Mỹ với Canada về việc cấp giấy phép lái xe, thị thực, …Trong ví dụ của tất cả chúng ta, Alice là principal, Mỹ là nhà sản xuất dịch vụ ( service provider ), và Canada lại một lần nữa là nhà cung ứng nhận dạng. Yêu cầu gửi tới Canada bởi Mỹ tựa như một thông điệp XML nêu rõ thông tin gì được nhu yếu, ai đang nhu yếu, và người nhận câu vấn đáp. Trả lời của Canada sẽ được gọi là một assertion, trong thuật ngữ của SAML ( tương tự như token của OpenID hoặc OAuth2 ). Assertion này hoàn toàn có thể chứa những thông tin về xác nhận, chuyển nhượng ủy quyền và / hoặc những thuộc tính ( những thông tin đơn cử về người dùng, ví dụ điển hình như email hoặc số điện thoại cảm ứng ) .SAML 2.0 định nghĩa những assertion, những protocol, cái gì là những nhu yếu và vấn đáp assertion, những binding, hoặc cách những nhu yếu và vấn đáp xảy ra giữa những nhà sản xuất dịch vụ ( service provider ) và nhà phân phối nhận dạng ( identity provider ), sử dụng những phương pháp liên kết chuẩn ( ví dụ HTTP POST ) ; và profiles, cái phối hợp của những assertion, protocol và binding để sử dụng cho trường hợp khác nhau, ví dụ điển hình như SSO .Một trường hợp SSO giống như thế này : Alice là quản trị tại Acme Corp. Cô ấy truy vấn cổng thông tin của Acme Corp, nơi cô ấy đăng nhập với thông tin cá thể của mình. Sau khi đăng nhập, cô ấy hoàn toàn có thể bấm vào 1 số ít link mà cô ấy thích ( lương thưởng, tin tức của công ty, Saleforce, … ). Cô ấy bấm vào link Salesforce, nó chứa một SAML assertion về Alice. Cô ấy sẽ được chuyển tới Salesfoce, nó nhận được SAML assertion. Salesforce tin yêu Acme Corp, và cho nên vì thế tin yêu assertion. Sử dụng thông tin trong assertion, Alice tự động hóa đăng nhập, và những tài liệu thích hợp được hiển thị dựa trên những thuộc tính trong assertion .
Tổng kết
Cả ba giải pháp được tổng hợp lại trong bảng bên dưới. Ứng dụng của chúng tôi tiến hành IdentityServer, một. NET framework tiến hành cả OAuth2 và OpenID Connect .
OAuth2
OpenId
SAML
Token (or assertion) format
JSON or SAML2
JSON
XML
Authorization?
YesNoYes
Authentication?
Pseudo-authenticationYesYes
Year created
200520062001
Current version
OAuth2OpenID ConnectSAML 2.0
Transport
HTTPHTTP GET and HTTP POSTHTTP Redirect ( GET ) binding, SAML SOAP binding, HTTP POST binding, and others
Security Risks
PhishingOAuth 2.0 does not tư vấn signature, encryption, channel binding, or client verification. Instead, it relies completely on TLS for confidentiality .PhishingIdentity providers have a log of OpenID logins, making a compromised account a bigger privacy breachXML Signature Wrapping to impersonate any user
Best suited for
API authorizationSingle sign-on for consumer apps
Single sign-on for enterprise
Note : not well suited for mobile
Tham khảo thêm
Source: https://mindovermetal.org
Category: Wiki là gì
