Ghi chú. bản dịch.: Bài viết tuyệt vời này của Okta giải thích cách OAuth và OIDC (OpenID Connect) hoạt động một cách đơn giản và rõ ràng. Kiến thức này sẽ hữu ích cho các nhà phát triển, quản trị viên hệ thống và thậm chí cả "người dùng thông thường" của các ứng dụng web phổ biến, những ứng dụng này rất có thể cũng trao đổi dữ liệu bí mật với các dịch vụ khác.
Trong thời kỳ đồ đá của Internet, việc chia sẻ thông tin giữa các dịch vụ rất dễ dàng. Bạn chỉ cần cung cấp thông tin đăng nhập và mật khẩu của mình từ dịch vụ này sang dịch vụ khác để anh ấy nhập tài khoản của bạn và nhận bất kỳ thông tin nào anh ấy cần.
"Đưa tài khoản ngân hàng cho tôi." “Chúng tôi hứa rằng mọi thứ sẽ ổn với mật khẩu và tiền. Đó là thành thật, thành thật!" *hi hi*
Kinh dị! Không ai nên yêu cầu người dùng chia sẻ tên người dùng và mật khẩu, thông tin đăng nhập, với một dịch vụ khác. Không có gì đảm bảo rằng tổ chức đằng sau dịch vụ này sẽ giữ an toàn cho dữ liệu và sẽ không thu thập nhiều thông tin cá nhân hơn mức cần thiết. Nghe có vẻ điên rồ, nhưng một số ứng dụng vẫn sử dụng phương pháp này!
Ngày nay, có một tiêu chuẩn duy nhất cho phép một dịch vụ sử dụng dữ liệu của dịch vụ khác một cách an toàn. Thật không may, các tiêu chuẩn như vậy sử dụng rất nhiều biệt ngữ và thuật ngữ, điều này làm phức tạp sự hiểu biết của họ. Mục đích của tài liệu này là để giải thích cách chúng hoạt động bằng cách sử dụng các hình minh họa đơn giản (Bạn có nghĩ rằng các bức vẽ của tôi giống với bức vẽ của trẻ em không? Ồ tốt!).
Nhân tiện, hướng dẫn này cũng có sẵn ở định dạng video:
Xin chào mừng quý vị và các bạn: OAuth 2.0
là một tiêu chuẩn bảo mật cho phép một ứng dụng có quyền truy cập thông tin trong một ứng dụng khác. Trình tự các bước cấp giấy phép [sự cho phép] (hoặc đồng ý [bằng lòng]) thường gọi ủy quyền [ủy quyền] hoặc thậm chí ủy quyền được ủy quyền [ủy quyền ủy quyền]. Với tiêu chuẩn này, bạn cho phép một ứng dụng thay mặt bạn đọc dữ liệu hoặc sử dụng các chức năng của ứng dụng khác mà không cần cung cấp mật khẩu cho ứng dụng đó. Lớp học!
Ví dụ: giả sử bạn khám phá một trang web có tên "Trò chơi chữ xui xẻo trong ngày" [Trò chơi chữ khủng khiếp trong ngày] và quyết định đăng ký trên đó để nhận các trò chơi chữ hàng ngày dưới dạng tin nhắn trên điện thoại. Bạn thực sự thích trang này và bạn quyết định chia sẻ nó với tất cả bạn bè của mình. Rốt cuộc, mọi người đều thích chơi chữ đáng sợ, phải không?
“Trò chơi chữ đáng tiếc trong ngày: Nghe nói về anh chàng bị mất nửa người bên trái? Bây giờ anh ấy luôn luôn đúng! (bản dịch gần đúng, vì bản gốc có cách chơi chữ riêng - bản dịch gần đúng)
Rõ ràng là viết thư cho từng người trong danh sách liên lạc không phải là một lựa chọn. Và, nếu bạn thậm chí giống tôi một chút, thì bạn sẽ cố gắng hết sức để tránh những công việc không cần thiết. May mắn thay, Terrible Pun of the Day có thể tự mời tất cả bạn bè của bạn! Để thực hiện việc này, bạn chỉ cần mở quyền truy cập vào email của các liên hệ của mình - chính trang web sẽ gửi cho họ lời mời (quy tắc OAuth)!
“Mọi người đều thích chơi chữ! - Đã đăng nhập? “Bạn có muốn cho phép trang web Terrible Pun of the Day truy cập vào danh sách liên hệ của bạn không? - Cảm ơn! Từ giờ trở đi, chúng tôi sẽ gửi lời nhắc mỗi ngày cho mọi người mà bạn biết, cho đến hết thời gian! Bạn là người bạn tốt nhất!"
- Chọn dịch vụ email của bạn.
- Nếu cần, hãy truy cập trang web thư và đăng nhập vào tài khoản của bạn.
- Cấp cho Terrible Pun of the Day quyền truy cập vào danh bạ của bạn.
- Quay trở lại trang web Terrible Pun of the Day.
Trong trường hợp bạn đổi ý, các ứng dụng sử dụng OAuth cũng cung cấp một cách để thu hồi quyền truy cập. Sau khi bạn quyết định rằng bạn không còn muốn chia sẻ danh bạ với Trò chơi chữ khủng khiếp trong ngày nữa, bạn có thể truy cập trang web thư và xóa trang chơi chữ đó khỏi danh sách các ứng dụng được phép.
Luồng OAuth
Chúng ta vừa trải qua những gì thường được gọi là chảy [chảy] OAuth. Trong ví dụ của chúng tôi, quy trình này bao gồm các bước có thể nhìn thấy cũng như một số bước không nhìn thấy được, trong đó hai dịch vụ đồng ý trao đổi thông tin an toàn. Ví dụ về cách chơi chữ khủng khiếp trong ngày trước đó sử dụng luồng OAuth 2.0 phổ biến nhất, được gọi là luồng "mã ủy quyền". [luồng "mã ủy quyền"].
Trước khi đi sâu vào chi tiết về cách thức hoạt động của OAuth, hãy nói về ý nghĩa của một số thuật ngữ:
- Chủ sở hữu tài nguyên:
Đó là bạn! Bạn sở hữu thông tin đăng nhập, dữ liệu của mình và kiểm soát tất cả các hoạt động có thể được thực hiện trên tài khoản của bạn. - Khách hàng:
Một ứng dụng (ví dụ: dịch vụ Terrible Pun of the Day) muốn truy cập hoặc thực hiện một số hành động nhất định thay mặt cho Chủ sở hữu tài nguyên'а. - Máy chủ ủy quyền:
Ứng dụng biết Chủ sở hữu tài nguyên'a và trong đó u Chủ sở hữu tài nguyên'a đã có tài khoản. - Máy chủ tài nguyên:
Giao diện lập trình ứng dụng (API) hoặc dịch vụ Khách hàng muốn sử dụng thay mặt Chủ sở hữu tài nguyên'а. - URI chuyển hướng:
Liên kết đó Máy chủ ủy quyền sẽ chuyển hướng Chủ sở hữu tài nguyên'và sau khi cấp phép Khách hàng'Tại. Nó đôi khi được gọi là "URL gọi lại". - loại phản ứng:
Loại thông tin dự kiến nhận được Khách hàng. Phổ biến nhất loại phản ứng'ohm là mã, đó là Khách hàng mong nhận được Mã ủy quyền. - Phạm vi:
Đây là mô tả chi tiết về các quyền được yêu cầu Khách hàng'y, chẳng hạn như truy cập dữ liệu hoặc thực hiện một số hành động nhất định. - Sự đồng ý:
Máy chủ ủy quyền mất Phạm viyêu cầu Khách hàng'om, và hỏi Chủ sở hữu tài nguyên'a, anh ấy đã sẵn sàng cung cấp chưa Khách hàng'có quyền thích hợp. - ID khách hàng:
ID này được sử dụng để xác định Khách hàng'một trên Máy chủ ủy quyền'e. - Bí mật khách hàng:
Đây là mật khẩu chỉ được biết Khách hàng'bạn và Máy chủ ủy quyền'Tại. Nó cho phép họ chia sẻ thông tin một cách riêng tư. - Mã ủy quyền:
Mã tạm thời có thời hạn hiệu lực ngắn, Khách hàng cung cấp Máy chủ ủy quyềnđổi lấy Truy cập thẻ. - Truy cập thẻ:
Chìa khóa mà khách hàng sẽ sử dụng để giao tiếp với Máy chủ tài nguyên'ừm. Một loại huy hiệu hoặc thẻ chìa khóa cung cấp Khách hàng'có quyền yêu cầu dữ liệu hoặc thực hiện hành động trên Máy chủ tài nguyên'e thay mặt bạn.
Ghi: Đôi khi Máy chủ Ủy quyền và Máy chủ Tài nguyên là cùng một máy chủ. Tuy nhiên, trong một số trường hợp, đây có thể là các máy chủ khác nhau, ngay cả khi chúng không thuộc cùng một tổ chức. Ví dụ: Máy chủ ủy quyền có thể là dịch vụ của bên thứ ba được Máy chủ tài nguyên tin cậy.
Bây giờ, chúng tôi đã đề cập đến các khái niệm cốt lõi của OAuth 2.0, hãy quay lại ví dụ của chúng tôi và xem xét kỹ hơn những gì xảy ra trong luồng OAuth.
- Bạn, Chủ sở hữu tài nguyên, bạn muốn cung cấp dịch vụ Trò chơi chữ khủng khiếp trong ngày (Khách hàngy) truy cập vào danh bạ của bạn để họ có thể gửi lời mời tới tất cả bạn bè của bạn.
- Khách hàng chuyển hướng trình duyệt đến trang Máy chủ ủy quyền'a và bao gồm trong truy vấn ID khách hàng, URI chuyển hướng, loại phản ứng và một hoặc nhiều Phạm vi (quyền) nó cần.
- Máy chủ ủy quyền xác minh bạn, yêu cầu tên người dùng và mật khẩu nếu cần.
- Máy chủ ủy quyền hiển thị một hình thức Sự đồng ý (xác nhận) với một danh sách tất cả Phạm viyêu cầu Khách hàng'ừm. Bạn đồng ý hay từ chối.
- Máy chủ ủy quyền chuyển hướng bạn đến trang web Khách hàng'a, sử dụng URI chuyển hướng cùng với Mã ủy quyền (mã ủy quyền).
- Khách hàng giao tiếp trực tiếp với Máy chủ ủy quyền'ohm (bỏ qua trình duyệt Chủ sở hữu tài nguyên'a) và gửi an toàn ID khách hàng, Bí mật khách hàng и Mã ủy quyền.
- Máy chủ ủy quyền kiểm tra dữ liệu và trả lời với Truy cập thẻ'om (mã thông báo truy cập).
- Bây giờ Khách hàng co thể sử dụng Truy cập thẻ gửi yêu cầu đến Máy chủ tài nguyên để có được một danh sách các địa chỉ liên lạc.
ID khách hàng và bí mật
Rất lâu trước khi bạn cho phép Terrible Pun of the Day truy cập vào danh bạ của mình, Máy khách và Máy chủ Ủy quyền đã thiết lập mối quan hệ làm việc. Máy chủ ủy quyền đã tạo ID ứng dụng khách và Bí mật ứng dụng khách (đôi khi được gọi là ID ứng dụng и Ứng dụng bí mật) và gửi chúng tới Máy khách để tương tác thêm trong OAuth.
"- Xin chào! Tôi muốn làm việc với bạn! - Chắc chắn, không thành vấn đề! Đây là Client ID và Secret của bạn!”
Tên gợi ý rằng Bí mật máy khách phải được giữ bí mật để chỉ Máy khách và Máy chủ ủy quyền biết. Rốt cuộc, với sự giúp đỡ của anh ấy, Máy chủ ủy quyền xác nhận sự thật của Máy khách.
Nhưng đó không phải là tất cả... Xin chào mừng OpenID Connect!
OAuth 2.0 chỉ được thiết kế cho ủy quyền - để cung cấp quyền truy cập vào dữ liệu và chức năng từ ứng dụng này sang ứng dụng khác. (OIDC) là một lớp mỏng bên trên OAuth 2.0, bổ sung thông tin đăng nhập và chi tiết hồ sơ của người dùng đã đăng nhập vào tài khoản. Việc tổ chức phiên đăng nhập thường được gọi là xác thực [xác thực]và thông tin về người dùng đã đăng nhập vào hệ thống (tức là về Chủ sở hữu tài nguyên'e), — dữ liệu cá nhân [danh tính]. Nếu Máy chủ ủy quyền hỗ trợ OIDC, đôi khi nó được gọi là nhà cung cấp dữ liệu cá nhân [nhà cung cấp danh tính]bởi vì nó cung cấp Khách hàng'có thông tin về Chủ sở hữu tài nguyên'e.
OpenID Connect cho phép bạn triển khai các tình huống trong đó một lần đăng nhập có thể được sử dụng trong nhiều ứng dụng - phương pháp này còn được gọi là dấu hiệu duy nhất trên (SSO). Ví dụ: một ứng dụng có thể hỗ trợ tích hợp SSO với các mạng xã hội như Facebook hoặc Twitter, cho phép người dùng sử dụng tài khoản mà họ đã có và muốn sử dụng.
Luồng (flow) OpenID Connect trông giống như trong trường hợp của OAuth. Sự khác biệt duy nhất là trong yêu cầu chính, phạm vi cụ thể được sử dụng là openid, - MỘT Khách hàng cuối cùng được như Truy cập thẻVà Mã thông báo ID.
Giống như trong luồng OAuth, Truy cập thẻ trong OpenID Connect, đây là một số giá trị không rõ ràng Khách hàng'Tại. Từ quan điểm Khách hàng'a Truy cập thẻ đại diện cho một chuỗi ký tự được chuyển cùng với mỗi yêu cầu tới Máy chủ tài nguyên'y, xác định xem mã thông báo có hợp lệ hay không. Mã thông báo ID đại diện cho một điều hoàn toàn khác.
Mã thông báo ID là JWT
Mã thông báo ID là một chuỗi ký tự được định dạng đặc biệt được gọi là JSON Web Token hoặc JWT (đôi khi mã thông báo JWT được phát âm giống như "jots"). Đối với những người quan sát bên ngoài, JWT có vẻ như là một từ vô nghĩa khó hiểu, nhưng Khách hàng có thể trích xuất nhiều thông tin khác nhau từ JWT, chẳng hạn như ID, tên người dùng, thời gian đăng nhập, ngày hết hạn Mã thông báo ID'a, sự hiện diện của các nỗ lực can thiệp vào JWT. Dữ liệu bên trong Mã thông báo ID'a được gọi là các ứng dụng [tuyên bố].
Trong trường hợp của OIDC, cũng có một cách tiêu chuẩn để Khách hàng có thể yêu cầu thêm thông tin về cá nhân [danh tính] từ Máy chủ ủy quyền'a, ví dụ, một địa chỉ email sử dụng Truy cập thẻ.
Tìm hiểu thêm về OAuth và OIDC
Vì vậy, chúng tôi đã xem xét ngắn gọn cách thức hoạt động của OAuth và OIDC. Sẵn sàng để tìm hiểu sâu hơn? Dưới đây là các tài nguyên bổ sung để giúp bạn tìm hiểu thêm về OAuth 2.0 và OpenID Connect:
Như mọi khi, hãy bình luận. Để cập nhật những tin tức mới nhất của chúng tôi, hãy đăng ký и Okta cho các nhà phát triển!
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com