Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến
Tài liệu về Apigee X. thông tin
Màn hình chính của OAuth: Xem trang chủ OAuth để xem thông tin cấp cao nhất về hướng dẫn về OAuth mà chúng tôi cung cấp.
Chủ đề này cung cấp thông tin tổng quan cơ bản về OAuth 2.0 trên Apigee Edge.
OAuth 2.0 là gì?
Có rất nhiều sách, blog và trang web dành cho OAuth 2.0. Bạn nên hãy bắt đầu bằng cách xem lại IETF OAuth 2.0 . Đây là định nghĩa về OAuth 2.0 trong thông số kỹ thuật OAuth 2.0 IETF chính nó:
"Khung uỷ quyền OAuth 2.0 cho phép bên thứ ba để có được quyền truy cập giới hạn vào một dịch vụ HTTP, thay mặt cho chủ sở hữu tài nguyên thông qua sắp xếp một tương tác phê duyệt giữa chủ sở hữu tài nguyên và dịch vụ HTTP, hoặc bằng cách cho phép ứng dụng của bên thứ ba tự lấy quyền truy cập".
Điều quan trọng bạn cần biết là OAuth 2.0 cung cấp một cách để các ứng dụng có được quyền truy cập hạn chế vào tài nguyên được bảo vệ của người dùng (hãy nghĩ đến tài khoản ngân hàng hoặc bất kỳ tài khoản nào khác thông tin nhạy cảm mà người dùng có thể muốn truy cập từ một ứng dụng) mà không cần người dùng phải tiết lộ thông tin đăng nhập của họ cho ứng dụng.
Quy trình OAuth 2.0
Dưới đây là quy trình chung cho khung bảo mật OAuth 2.0. Chúng ta sẽ thảo luận kỹ hơn về quy trình này về chủ đề này, bắt đầu bằng một sơ đồ minh hoạ nhiều về cách hoạt động của OAuth 2.0. Nếu bạn không quen thuộc với các thuật ngữ được sử dụng trong sơ đồ này, hãy đọc phần này để tìm hiểu nhanh phần giới thiệu.
Các thuật ngữ bạn nên biết
- Ứng dụng: Còn được gọi là "ứng dụng". Đó có thể là một ứng dụng chạy trên thiết bị di động hoặc ứng dụng web truyền thống. Ứng dụng gửi yêu cầu đến máy chủ tài nguyên cho các mục được bảo vệ thay mặt cho chủ sở hữu tài nguyên. Chủ sở hữu tài nguyên phải cấp cho ứng dụng quyền truy cập vào các tài nguyên được bảo vệ.
- Chủ sở hữu tài nguyên: Còn được gọi là "người dùng cuối". Đây thường là người (hoặc tổ chức khác) có thể cấp quyền truy cập vào tài nguyên được bảo vệ. Cho ví dụ: nếu một ứng dụng cần sử dụng dữ liệu từ một trong các trang web mạng xã hội của bạn, thì bạn là chủ sở hữu tài nguyên – người duy nhất có thể cấp cho ứng dụng quyền truy cập vào dữ liệu của bạn.
- Máy chủ tài nguyên: Hãy coi máy chủ tài nguyên là một dịch vụ giống như Facebook, Google hoặc Twitter; hoặc một dịch vụ nhân sự trên mạng nội bộ của bạn; hoặc dịch vụ của đối tác trên Mạng mở rộng B2B. Apigee Edge là một máy chủ tài nguyên bất cứ khi nào cần xác thực mã thông báo OAuth để xử lý các yêu cầu API. Máy chủ tài nguyên cần một loại cấp phép nào đó trước khi phân phát giải phóng tài nguyên được bảo vệ vào ứng dụng.
- Máy chủ uỷ quyền: Máy chủ uỷ quyền đã được triển khai tuân thủ quy cách OAuth 2.0 và chịu trách nhiệm về xác thực cấp quyền truy cập và cấp quyền truy cập mã thông báo cấp cho ứng dụng quyền truy cập vào dữ liệu của người dùng trên máy chủ tài nguyên. Bạn có thể định cấu hình "điểm cuối của mã thông báo" trên Apigee Edge. Trong trường hợp đó, Edge sẽ đảm nhận vai trò máy chủ uỷ quyền.
- Cấp quyền: Cấp cho ứng dụng quyền truy xuất quyền truy cập mã thông báo thay mặt cho người dùng cuối. OAuth 2.0 xác định 4 "loại cấp phép" cụ thể. Xem bài viết "Các loại cấp quyền sử dụng OAuth 2.0" bên dưới.
- Mã truy cập: Một chuỗi dài gồm các ký tự đóng vai trò là thông tin đăng nhập dùng để truy cập tài nguyên được bảo vệ. Hãy xem thêm bài viết "Quyền truy cập là gì mã thông báo không?" bên dưới.
- Tài nguyên được bảo vệ: Dữ liệu do chủ sở hữu tài nguyên sở hữu. Ví dụ: danh bạ, thông tin tài khoản hoặc các dữ liệu nhạy cảm khác của người dùng.
Vị trí phù hợp của Apigee Edge
Bạn có thể bảo vệ mọi API được proxy qua Apigee Edge bằng OAuth 2.0. Edge bao gồm việc triển khai máy chủ uỷ quyền, v.v. có thể tạo và xác thực mã thông báo truy cập. Nhà phát triển bắt đầu bằng cách đăng ký ứng dụng của họ thông qua Apigee Edge. Ứng dụng đã đăng ký có thể yêu cầu mã truy cập thông qua bất kỳ quyền nào trong 4 bước cấp loại tương tác.
Apigee cung cấp chính sách OAuthV2 đa diện để triển khai thông tin chi tiết về từng loại quyền cấp, giúp việc thiết lập OAuth trên Apigee Edge trở nên tương đối dễ dàng. Cho ví dụ: bạn có thể định cấu hình chính sách nhận yêu cầu về mã truy cập, đánh giá tất cả thông tin xác thực bắt buộc và trả về mã truy cập nếu thông tin xác thực hợp lệ.
Xin lưu ý rằng mọi máy chủ tài nguyên mà lệnh gọi proxy API bảo mật của bạn phải được bảo vệ sau tường lửa (nghĩa là tài nguyên không được truy cập được qua bất kỳ phương tiện nào ngoài proxy API hoặc một phương tiện khác API được bảo mật tốt).
OAuth 2.0 là gì loại tài trợ?
Hãy coi các loại tài trợ là các lộ trình hoặc hoạt động tương tác khác nhau mà một ứng dụng có thể thực hiện để có được quyền truy cập mã thông báo. Mỗi loại quyền cấp cho một hoặc nhiều trường hợp sử dụng và bạn cần chọn trạng thái cấp để sử dụng dựa trên nhu cầu của riêng bạn. Nhìn chung, mỗi loại tài trợ đều có ưu điểm và nhược điểm và bạn sẽ cần cân nhắc đánh đổi dựa trên các trường hợp sử dụng kinh doanh của mình. Một yếu tố quan trọng cần cân nhắc là "độ tin cậy" trong số các ứng dụng sẽ truy cập vào dữ liệu của bạn. Nhìn chung, các ứng dụng bên thứ ba không đáng tin cậy bằng những ứng dụng được phát triển và sử dụng trong doanh nghiệp.
Apigee Edge hỗ trợ 4 loại quyền sử dụng OAuth 2.0 chính:
- mã ủy quyền -- Được coi là loại cấp quyền an toàn nhất. Trước máy chủ uỷ quyền cấp một mã truy cập, trước tiên, ứng dụng phải nhận được một mã uỷ quyền từ máy chủ tài nguyên. Bạn đã thấy quy trình này mỗi khi ứng dụng của bạn mở trình duyệt lên trang đăng nhập của máy chủ tài nguyên và mời bạn đăng nhập vào tài khoản thực của mình (ví dụ: Facebook hoặc Twitter).
Nếu bạn đăng nhập thành công, ứng dụng này sẽ nhận được yêu cầu uỷ quyền mà công cụ này có thể dùng để thương lượng mã truy cập với máy chủ uỷ quyền. Thông thường, loại cấp quyền được dùng khi ứng dụng nằm trên máy chủ chứ không phải trên ứng dụng. Loại quyền này là được coi là có tính bảo mật cao vì ứng dụng khách không bao giờ xử lý hoặc nhìn thấy tên người dùng của người dùng hoặc cho máy chủ tài nguyên (ví dụ: ứng dụng không bao giờ thấy hoặc xử lý thông tin đăng nhập Twitter). Quy trình loại cấp quyền này còn được gọi là "ba bên" OAuth.
- ngầm ẩn -- Được coi là phiên bản đơn giản của mã ủy quyền. Thông thường, loại cấp quyền này được dùng khi ứng dụng nằm trên ứng dụng. Ví dụ: mã được triển khai trong trình duyệt bằng JavaScript hoặc ngôn ngữ tập lệnh khác (thay vì lưu trú và chạy trên một máy chủ web riêng biệt). Trong quy trình loại cấp quyền này, lệnh uỷ quyền máy chủ trực tiếp trả về mã truy cập khi người dùng được xác thực, thay vì cấp mã uỷ quyền đầu tiên. Các lệnh cấp ngầm ẩn có thể cải thiện khả năng phản hồi của ứng dụng trong một số trường hợp, nhưng lợi thế này cần được xem xét với các tác động có thể xảy ra về bảo mật như được mô tả trong Thông số kỹ thuật của IETF.
- Thông tin xác thực mật khẩu của chủ sở hữu tài nguyên -- Trong quy trình này, khách hàng được cấp mã truy cập khi tên người dùng/mật khẩu của người dùng được máy chủ uỷ quyền xác thực. Bạn nên áp dụng quy trình này cho các ứng dụng có độ tin cậy cao. Một lợi thế của quy trình này, chẳng hạn như xác thực cơ bản, đó là người dùng chỉ xuất trình tên người dùng/mật khẩu của mình một lần. Từ thời điểm đó thì mã truy cập sẽ được sử dụng.
- thông tin đăng nhập của khách hàng -- Cân nhắc sử dụng cho trường hợp mà khách hàng ứng dụng đang hành động thay mặt cho chính mình. Tức là khách hàng cũng là chủ sở hữu tài nguyên. Lần cấp quyền này loại thường được dùng khi ứng dụng cần truy cập vào dịch vụ lưu trữ dữ liệu phụ trợ, cho ví dụ: Ứng dụng cần dùng dịch vụ này để thực hiện công việc của mình và dịch vụ này không rõ ràng cho người dùng cuối. Với loại cấp quyền này, ứng dụng có thể nhận được mã truy cập bằng cách thể hiện rằng mã ứng dụng khách và khoá bí mật của ứng dụng khách đến máy chủ uỷ quyền. Bạn không cần làm gì thêm. Edge cung cấp ngay giải pháp cung cấp sẵn thông tin xác thực ứng dụng khách và dễ dàng triển khai cho mọi Proxy API.
Quyền truy cập là gì mã thông báo?
Mã truy cập là một chuỗi ký tự dài đóng vai trò là thông tin đăng nhập được dùng để truy cập tài nguyên được bảo vệ. Mã thông báo tài nguyên (còn gọi là mã thông báo mang) được chuyển vào phần Uỷ quyền như sau:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Máy chủ tài nguyên hiểu rằng mã truy cập "có hiệu lực" để biết thông tin đăng nhập như tên người dùng và mật khẩu. Ngoài ra, mã truy cập có thể được cấp kèm theo các quy định hạn chế để ví dụ: ứng dụng có thể đọc nhưng không thể ghi hoặc xoá dữ liệu trên máy chủ tài nguyên. Xin lưu ý rằng mã truy cập có thể bị thu hồi trong trường hợp ứng dụng bị xâm phạm chẳng hạn. Trong trường hợp này, bạn cần nhận mã truy cập mới để tiếp tục dùng ứng dụng; tuy nhiên, bạn sẽ không phải thay đổi tên người dùng hoặc mật khẩu trên máy chủ tài nguyên được bảo vệ (ví dụ: Facebook hoặc Twitter).
Mã truy cập thường có thời hạn (vì lý do bảo mật). Một số loại tài trợ cho phép máy chủ uỷ quyền sẽ cấp mã làm mới. Mã này cho phép ứng dụng tìm nạp mã truy cập mới khi mã cũ hết hạn. Để biết thêm thông tin về quyền truy cập và mã làm mới, hãy tham khảo OAuth của IETF Quy cách 2.0.
Truy cập bị giới hạn thông qua các phạm vi
Thông qua cơ chế phạm vi, OAuth 2.0 có thể cấp cho ứng dụng quyền truy cập hạn chế vào dữ liệu được bảo vệ của chúng tôi. Ví dụ: một ứng dụng có thể chỉ truy cập được vào một số tài nguyên cụ thể, có khả năng cập nhật hoặc chỉ có thể được cấp quyền truy cập chỉ đọc. Dưới cái gọi là "ba chân" Quy trình OAuth, người dùng thường chỉ định cấp truy cập thông qua trang yêu cầu đồng ý (ví dụ: trang web trong đó người dùng chọn phạm vi bằng hộp đánh dấu của cơ chế khác).
Đăng ký ứng dụng
Tất cả ứng dụng (ứng dụng) đều phải đăng ký với máy chủ uỷ quyền OAuth 2.0 mà họ dùng muốn yêu cầu mã truy cập. Khi đăng ký một ứng dụng, bạn sẽ nhận lại một bộ khoá. Một là một khoá công khai có tên là mã nhận dạng ứng dụng khách và khoá còn lại là khoá bí mật có tên ứng dụng khách bí mật. Nếu không có các khoá này, ứng dụng sẽ không thể yêu cầu mã uỷ quyền hoặc mã truy cập đến máy chủ uỷ quyền. Lưu ý rằng mặc dù thông số kỹ thuật OAuth của IETF gọi các ứng dụng khoá này Mã nhận dạng và mật khẩu ứng dụng khách, giao diện người dùng Apigee Edge gọi các mã này là Mã nhận dạng người tiêu dùng và Bí mật người tiêu dùng. Đó là tương đương.
Tóm tắt các trường hợp sử dụng OAuth 2.0
Quy trình loại cấp quyền OAuth 2.0 mà bạn chọn triển khai phụ thuộc vào trường hợp sử dụng cụ thể của bạn, như một số loại tài trợ an toàn hơn các loại tài trợ khác. Lựa chọn của bạn về loại tài trợ phụ thuộc vào độ tin cậy của ứng dụng khách hàng và đòi hỏi bạn phải xem xét rất cẩn thận, như được mô tả trong bảng sau:
| Trường hợp sử dụng | Độ tin cậy | Các loại cấp quyền OAuth 2.0 được đề xuất | Mô tả |
|---|---|---|---|
| B2B (extranet), mạng nội bộ, khác |
Ứng dụng có độ tin cậy cao, được viết bởi nhà phát triển nội bộ hoặc các nhà phát triển có mối quan hệ kinh doanh với nhà cung cấp API. Những ứng dụng cần truy cập vào tài nguyên thay mặt cho ứng dụng của mình. |
|
|
| Trang web nội bộ, cổng |
Ứng dụng đáng tin cậy do nhà phát triển nội bộ hoặc bên thứ ba đáng tin cậy viết. Một ví dụ điển hình là đăng nhập vào trang web nhân sự của công ty bạn để chọn bảo hiểm, gửi bài đánh giá hoặc thay đổi thông tin cá nhân. |
|
|
| Ứng dụng phát hành công khai | Ứng dụng không đáng tin cậy được viết bởi nhà phát triển bên thứ ba, những người này không có doanh nghiệp đáng tin cậy với nhà cung cấp API. Ví dụ: những nhà phát triển đăng ký API công khai các chương trình thường không đáng tin cậy. |
|
|
| B2C | Có một người dùng cuối cá nhân (người dùng thiết bị di động) liên quan và thông tin đăng nhập của người dùng được lưu trữ trên thiết bị di động. |
|
|
OAuth 2.0 so với khoá API nguồn tài trợ
Để xác thực khoá API, ứng dụng cần gửi khoá cho Edge. Khoá phải là một khoá người dùng hợp lệ từ một ứng dụng dành cho nhà phát triển Apigee Edge được liên kết với proxy API. Nếu vì lý do nào đó mà bạn cần thu hồi quyền cho phép ứng dụng khách gọi điện đến proxy, bạn phải thu hồi quyền đó khoá người tiêu dùng. Mọi ứng dụng khách dùng khoá đó cũng sẽ không thể truy cập vào proxy API. Trên mặt khác, mã thông báo OAuth có thể bị thu hồi bất cứ lúc nào mà không cần thu hồi các khoá của ứng dụng. Ứng dụng chỉ cần yêu cầu mã thông báo mới thay mặt cho người dùng và nếu đã cấp mã, ứng dụng có thể hãy tiếp tục sử dụng proxy API.
Một điểm khác biệt khác giữa khoá API và mã thông báo là mã thông báo có thể chứa siêu dữ liệu mà bạn có thể truy xuất và sử dụng sau này. Ví dụ: bạn có thể lưu trữ mã nhận dạng của người dùng thực hiện lệnh gọi API và sử dụng lệnh gọi đó để tuỳ chỉnh lệnh gọi đến dịch vụ đích phụ trợ.
Để biết thông tin chi tiết về việc xác thực khoá API, vui lòng xem API khoá. Để biết thông tin về cách sử dụng các thuộc tính tuỳ chỉnh bằng mã thông báo OAuth, hãy xem bài viết Tuỳ chỉnh mã thông báo và Mã uỷ quyền.
Đề xuất tài nguyên
Đọc sách
Hãy xem bài viết Tìm hiểu về OAuth 2.0.